CO: But aside from being open-source and leveraging all the great things that happen because of that, FlightGear has always been about fidelity first. Flight simulation is about combining illusions and tricks with some modelling of real world physics and geometry. FlightGear has always focused first on developing the internal engine to accurately model the physics of flight, to accurately model aircraft systems and instrumentation, and to accurately model the earth.
The accuracy of flight physics with a simulator is something that is widely debated in flight sim circles. FlightGear offers two core flight dynamics (physics) engines. The first is called JSBSim and is developed by a former NASA space shuttle simulation engineer in partnership with a Boeing engineer (and now with contributions from aerodynamics experts from around the world). It follows the classic aero engineering approach of using stability derivatives and aero coefficients to drive an accurate physics engine. If you want to talk about things like optimal numerical integration strategies, modelling fuel slosh, perfecting orbital dynamics, etc. then the JSBsim folks are the ones to link up with.
Source: FlightGear FlightGear also offers a simpler flight dynamics engine called "YASim". This is also built on top of a carefully constructed physics engine. It is conceptually similar to X-Plane's physics model with some key differences. To model an aircraft with YASim, you provide aircraft geometry and mass data (similar to X-Plane). But with YASim you then provide the cruise speed and altitude along with an approach configuration. YASim has a built in solver that creates an airfoil with the proper lift/drag ratio to achieve your performance numbers given the aircraft's weight and physical dimensions. Contrast this with X-Plane where you provide the airfoil and X-Plane decides how fast and how high the aircraft will fly. In all cases, an aircraft designer will need to spend quite a bit of time tweaking and tuning the parameters available to them in order to achieve realistic flight characteristics for any specific airplane.
The H: Tell us about the engine used by FlightGear. What dependencies, if any, are required to run the simulator?
CO: The FlightGear graphics engine is built on top of OpenGL and Open Scene Graph as its underlying 3D graphics engine. The key reason to use OpenGL and OSG is that these are portable and their licensing dovetails nicely with the FlightGear open source licence.
The H: How large would you say that the FlightGear community is? How many active developers are there currently? Supporters? How big is the core team?
CO: Because of FlightGear's open and "free" participation and contribution structure, it is very hard to determine exact numbers. We don't require anyone to register themselves. We don't require anyone to purchase the software or development kits. We don't restrict sharing the software (except as limited by the terms of our GPL licence). The result is that it is very difficult to count heads. Over the course of the project there have been many hundreds (probably thousands) of people that have contributed in significant ways.
The H: As we already know, FlightGear is open source. What else can you tell us about your licensing, such as licences for other components?
CO: I will start by saying that I am not a lawyer. I do my best to understand the licensing issues as they affect FlightGear, but beyond that I claim no expertise. From the start of our development of FlightGear has been licensed and distributed under the terms of the GPLv2 (the paint schemes applied to aircraft, called liveries, in FlightGear are also GPLv2-licensed). One way to quickly summarise the GPLv2 is that we offer the software to anyone for free, and we require anyone downstream who uses and redistributes the software (even if they make their own modifications) to also make their changes available to any one else. You could say that the cost of the software is to make your changes available to those who gave you this great software package in the first place.
Source: FlightGear In some cases, certain elements that have been integrated from other sources have other licence terms, but we make sure they are GPL-compatible terms before we integrate them and package/distribute them under the GPLv2. In other words, it's ok for us to integrate things that have less restrictive licensing than the GPL, but we can't integrate things that have additional licensing restrictions that would conflict with the GPL. By including non-GPL licensed components and distributing an entire package under the terms of the GPL, we don't add or change the original licensing of the individual components.
One example would be SimGear (which is a core set of libraries that FlightGear is built on top of). SimGear is licensed under the LGPL (which is less restrictive than the GPL). So we can include SimGear under the hood in FlightGear, we still can call FlightGear GPL, but someone could later pull out SimGear from FlightGear and use it under the original LGPL terms (just because it is inside FlightGear doesn't change its original licensing, but its original licensing allows it to be included in FlightGear).
We have done our best to be vigilant and enforce a policy that any contributions to the project in terms of code, models, artwork, sounds, data, etc. be compatible with the GPL licence, be original works, or be submitted with the original author's permission. We aggressively work to resolve any licensing issues that are brought to our attention.