Frequently asked questions

Thank you for your interest in FlightGear! This FAQ lists some of the most commonly asked questions. Please create a topic at our forum if you cannot find the answer on your problem(s).

Distribution

Where can I get FlightGear?

The official download page is https://flightgear.org/download/. Precompiled binaries and disk images are available for Windows and MacOS, and most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be fgfs or flightgear.)

How do I install FlightGear on Linux?

Many distributions include FlightGear in their repositories. In addition, in the Download Center you will also find AppImage, which will run on almost any modern distribution. If you can't find a packaged version for you, consider downloading and compiling from sources.

Where can I find the latest development source code?

The latest development code is available for everyone through our Git repository.

Where do I get the scenery? What is available?

While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. Currently TerraSync is the best option: it downloads the latest scenery while flying. See its page for usage information.

However the latest scenery could be too demanding if you have a low end computer or not much RAM, so consider instead to manually install the old scenery from the "graphical interface" available at the scenery download page.

Where can I get additional planes?

The latest official aircraft can be downloaded and installed with a single click through the aircraft tab in the built-in launcher (see FlightGear Qt launcher).

Official FlightGear aircraft can be found at Download Center. Other aircraft in development can be found in the official FGAddon aircraft repository, and some other aircraft can be found in 3rd party FlightGear hangars (see Howto:Install_aircraft).

Why are the aircraft at FlightGear.org out of date?

The official aircraft downloads are only updated at the time of a new release of FlightGear. This is done because aircraft that are currently in development are usually developed on development/unreleased versions of FlightGear. Those development versions have lots of features that are not supported by the (older) stable release. Would we update the aircraft downloads more often, most aircraft wouldn't work on the stable release of FlightGear.

How current is the data in FlightGear compared to the real world?

We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the $FG ROOT/Navaids/ and $FG ROOT/Airports/ directories.

Why don't you charge money for this?

FlightGear can be downloaded for free from many locations including the FlightGear website, but can also be bought on a CD. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.

Occasionally you may see FlightGear for sale on auction sites or commercial websites under some other name. This can be done quite legitimately as long as the terms of the license are upheld and might be worth the cost if some value-added features such as additional scenery, aircraft or after-sale support are included. Unfortunately, most cases seen to date appear to be just someone trying to make money selling something that is free and providing no real added value.

How can I get started with FlightGear?

There's no better place than the page New to FlightGear!

Compiling

How do I compile FlightGear from source?

See Building FlightGear. There are explanations to compile in Windows, Linux and even scripts to automatically download and compile the whole thing.

Why won't FlightGear compile?

Well, that depends. First make sure you are using the appropriate versions of FlightGear, SimGear, plib, zlib. If any of the packages are out of sync with the others, compilation may fail. See also Building FlightGear

TheFlightGear Downloads page should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.

Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly.

If your problems persist, ask in the FlightGear forum , on IRC or subscribe to our FlightGear-Users mailing list and let us know what problem you're having.

What is SimGear, and why do I need it?

SimGear is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For more information see http://www.simgear.org/. Note: When compiling FlightGear it is very important to have the matching version of SimGear.

Configuring and running

How do I start FlightGear?

The easiest way is using Qt Launcher. Otherwise, you can run it from the command line, with the proper options.

How do I install new scenery?

If you really don't want to/can't use TerraSync, the scenery archive files (ie. w100n30.tar.gz) should be decompressed into the Scenery/Terrain directory in your $FG_ROOT. More at Howto: Install scenery.

How do I setup my joystick(s)?

FlightGear supports wonderfully many joysticks/yokes out of the box. However if you're having problems see Input device.

What is fgfsrc? What format should my personal .fgfsrc file be in?

.fgfsrc is a file that can contain a list of Command line options with one option per line. The file is not an XML file. Note that also Windows installations have this file.

How do I get to see options, help etc?

You probably can not see the main menu. To make it show press F10.

Flying

Why won't my engine(s) start?

Aircraft vary in their starting procedure. Some may have an auto-start sequence menu entry or instructions in the aircraft help menu (press ? key) and/or at the aircraft's wiki. Please consider reading the FlightGear Manual, or see this quick small guide.

Where is the moving map?

In game, you can go into the menu "Equipment > Map", but there won't be any aeronautical chart. A popular moving map display is available under a separate project called Atlas. Also, MPmap is an online map for multiplayer.

If you like an alternative to Atlas with updated graphics and mapping provided by the OpenStreetMap project, then check out FlightGear Mapping Phi or JMapView.

Where can I learn about instrument flying and navigation?

There is a nice article, Understanding navigation, and a lot is very well explained into the FlightGear Manual. Other resources are:

• http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation.
• See How It Flies a very nice book by John S. Denker, freely accessible online

What is the difference between Aileron and Rudder?

There is a bit of info on aileron vs. rudder in the very same book...

Is there support for multi-player flying?

Yes, sure we have it! See Howto: Multiplayer. Both the Windows and *nix versions of FlightGear are capable of multi-player flying on FlightGear servers. Also voice communication is supported, with FGCom.

A map showing players aircraft online in real time is available as MPmap.

Where are the best places to fly in FlightGear?

FlightGear scenery covers the whole world, but thanks to the FlightGear user community, certain airports and areas are more detailed than others. As a general idea:

• There are a lot of high-quality scenery models around Paris, France.
• EHAM Amsterdam Schiphol, EGKK London Gatwick and LFPG Paris Charles de Gaulle are some of the highest quality airports.
• LOWI Innsbruck is both developed in scenery and airport.
• TNCM St. Maarten is a popular destination, and the surrounding islands (Anguilla, St. Eustatius, Saba, St. Barthélemy, St. Kitts, and Nevis) are all well-modeled.

Furthermore, see Suggested Flights, Suggested Airports and Suggested custom scenery.

Where can I find airport info and aeronautical charts online?

See Getting aeronautical charts.

Is there support for any military scenarios like dog fighting or bomb dropping?

Yes. Check out the Bombable add on and the Bombable topic on the forum . There are also third-party bombing scenarios for the A-10 and other aircraft with armament, like the North American OV-10A Bronco, General Dynamics F-16 and F-117 Nighthawk.

Flying issues

Why are my controls returning to a particular position?

There are several possibilities that can lead to this:

• If your aircraft's autopilot is enabled, it will take over (some of) your controls. Switch the autopilot off to regain control.
• Some laptops have an onboard gravity sensor that might be detected as a joystick. See how to solve that at Troubleshooting input devices.

Why does my cockpit disappear when looking around?

Probably you're using a 2D-panel version of an aircraft. Be sure to pick the one with a 3D cockpit. Most of the aircraft now have it!

There are lots of other aircraft flying around

FlightGear has a so-called AI Traffic system. This system generates other, computer-controlled aircraft based on real flight plans to make the FlightGear world look more alive. To disable artificial traffic, go to menu "AI" > "Traffic and Scenario Settings" and uncheck the "Enable AI traffic" option.

If on the contrary you can't see any aircraft other than yours, consider contributing to add traffic to your favourite place!

I can't make this plane fly straight, it keeps turning left!

Yes, FlightGear is a real flight simulator and simulates that too. Exactly, that's how real propeller aircraft behave. See Understanding Propeller Torque and P-Factor.

Also, doublecheck your weight distribution. Try adding a 180lbs copilot and see if the turn goes away.

Contributing

For anyone who's willing to contribute, we have dedicated to you the Developer portal and a Volunteer page that explains all the nice things you can do.

What language is FlightGear written in?

Mostly C++ with some supporting C code that's primarily contained within SimGear. For more details on the used languages:

• FlightGear programm
• SimGear
• FlightGear data (aircraft, sounds etc.)

As you seem to be interested in core development, you should really check out Howto:Start core development.

How do I design a flight dynamics model for a new aircraft?

FlightGear supports various flight dynamics models (FDMs), but just two of them are commonly used:

• JSBSim: see http://jsbsim.sf.net/.
• YASim: if you want a simpler FDM to work with, try your hand at YASim. For a guide on creating YASim aircraft, look in the FlightGear base package for $FG_ROOT/Docs/README.yasim.

See the Aircraft development portal.

How do I design or modify a 2D panel?

See the $FG_ROOT/Docs/README.xmlpanel file on your computer.

How do I place objects, like buildings, into FlightGear?

The most up to date solution is using the UFO. See Howto:Place 3D objects with the UFO. The UFO will give you the interface to choose one of the available objects and place it to some grade of precision into FG world, and then export that data to be uploaded to the official scenery, or for personal use. For more, see the Scenery development portal.

Where can I learn 3D programming and how do I get involved?

If you'd like to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is desperately needed. Try to go easy on the triangles, so that your work will be enjoyed by as many people as possible. The most commonly used tools here are Blender, AC3D, Gimp.

If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good OpenGL book eventually. However, FlightGear uses OSG, a high performance 3D graphics toolkit. To get started with 3D C++ coding, you can take a look at the OSG documentation and learn only as much OpenGL as you need, when you need it.

How do I add an airport?

This process includes creating the airport layout in WorldEditor, testing it (you might want to generate part of the scenery, but this is not mandatory) and then, if your data sources are GPL compatible, use WorldEditor to upload it to the gateway. The airport will be available in the next full rebuild of the scenery, unless you want to generate your own scenery. More at Howto:Make an airport.

Can I generate my own scenery?

Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, TerraGear. The good news, though, is that once you have set everything up it's quite easy (although might be time consuming), and above all that you can easily share it.

Problems

X doesn't work / is broken / is wrong / won't run

FlightGear is a very complex program. If you need help in general usage of the game you'll find it at the User portal and on the FlightGear forum .

If your problem is instead software crashes, you're getting errors, etc..., please consider following the indications in Troubleshooting problems.

Some of the most common issues are however listed below. If you can't solve the problem on your own and need the help of someone, please remember that we're all here for fun, developers included, and that any help is an act of generosity. So try to be nice, even if the problem is frustrating you.

Unable to execute file: bin/Win32/fgrun.exe during installation

This section contains out-of-date information Please help improve this article by updating it. There may be additional information on the talk page.

Your system is missing the MSVC runtime libraries required by FlightGear. Download and install the following vcredist_x86.exe:

• MSVC9 for FG2.4.0 (and earlier): http://www.microsoft.com/download/en/details.aspx?id=26368
• MSVC10 for FG2.6.0 (and later): http://www.microsoft.com/download/en/details.aspx?id=5555

What happened to the panel, keyboard, etc?

The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in XML files contained in the base package.

Why is FlightGear so slow?

If it seems just slow, see if you can fiddle with graphics settings here: Howto: Improve Framerates.

If things are pathologically slow (i.e. ~1 frame per second), maybe 3D hardware acceleration is not activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card. Also, be ready because some cards are not well supported.

How do I see the Frame Rate?

On the in-sim menu select "View" > "View Options", then check the box that says "Show frame rate".

How do I toggle 2D cockpit settings?

To show/hide the 2D panel, use the key combination ⇧ Shift+P. To show/hide the HUD, press ⇧ Shift+H. You can also enable the alternative HUD by pressing ⇧ Shift+I (press I to return to the default one). Use the ⇧ Shift+H key to adjust the brightness of the HUD.

Stuck upside down after "crash"?

In his infinite wisdom the FlightGear Grand Master decided that planes were too valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)

The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground. The quick answer is to reset the sim, via the File > Reset menu. This will place your aircraft back at its starting location.

For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!

Why won't the latest versions of some aircraft work in my (older) version of FlightGear?

Often new aircraft development keeps pace with the latest FlightGear code development. New or newly modified aircraft may rely on files (such as new instrument files) or features, only available with newer versions of FlightGear. If you are stuck with an older version of FlightGear, you can try downloading an earlier version of the aircraft from the corresponding official FlightGear aircraft hangar.

When I start FlightGear I see an error mentioning "SQLite". What do I do?

Since FlightGear v2.10 (released in February 2013), the navdata cache was introduced to improve the FlightGear start times. This cache is a SQLite database that is a little fragile at times. If the database is corrupted FlightGear will refuse to start.

To fix this you simply need to delete the $FG_HOME/navdata.cache file. The first time FlightGear starts after deletion of the file the navdata cache will be rebuild. As this process is time consuming, FlightGear will take more time to start.

Some will resort to delete the entire $FG_HOME directory or even reinstall FlightGear. However neither is needed and may cause you to lose any custom preferences you have set up.

A further SQLite related problem indicator is the error message

  Sqlite error:attempt to write a readonly database (8) while running:
     INSERT OR REPLACE INTO stat_cache (path, stamp) VALUES (?,?)

In this case a previously started FlightGear instance might still be running and locking the navdata.cache file. Check for a running fgfs process and terminate it.

My aircraft has grey windows?

The problem of opaque grey/gray windows that cannot be seen through is most often due to a version mismatch between the FlightGear program and the aircraft. Or it could be due to a window effect that is not compatible with the Rembrandt or ALS rendering systems. The technical cause is that the renderer and declared effect for the window are incompatible. Some solutions include:

• If you are using a stable FlightGear release, please download the aircraft from the official FlightGear hangars matching your FlightGear version.
• If you are using a cutting-edge nightly build or a version controlled copy of FlightGear, or you wish to use a cutting-edge aircraft, please see FGAddon#Obtaining aircraft.
• If you are using an aircraft from one of the 3rd party hangars, it is best to contact the original aircraft author or the person in charge of the 3rd party hangar.
• If you are using Rembrandt, try turning this rendering system off. Aircraft that use model-default.eff for the windows (at the simple expense of doing nothing) rather than model-transparent.eff, model-combined-transparent.eff or glass.eff (which instruct Rembrandt to not use deferred rendering for the glass) will have grey windows when using Rembrandt.

My screen becomes completely red right after starting FlightGear

The red screen is the visualization of the "Redout" effect. If it occurs right after starting FlightGear, it might be caused by a problem with scenery loading. FlightGear loads scenery on the fly and if scenery cannot be loaded, eg. due to network problems, there might be no ground for the aircraft to be located on. As a result, the aircraft falls through the non existing ground starting to tumble. This in turn causes the readout effect. For verifying the problem you should start your flight in KSFO, whose scenery is already included in the base package.

The FAQ

Who do I contact if I have comments about this FAQ?

Add your comment to this FAQ's discussion page.

How old is this document?

Check its history.

What other important documentation should I read?

• FlightGear manual
• New to FlightGear
• Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.

Contributing

Content Protection

See also FlightGear Plugins.

DRM

This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

Every once in a while, the question comes up if it is legal to provide closed source plug-in to FlightGear (more exact OSG file reader plug-in). The only need to keep code close is the prevention of reverse engineering.

FlightGear in its current form is a product of numerous people working voluntarily on a joint effort to create an open and extensible flight simulator platform. Your very idea of introducing DRM, is against all principles of open source in general.

You're free to create a non-GPL plane for FG - that's data from the perspective of the sim and doesn't trigger the license. You can sell that without ever allowing to re-distribute the source code. You're required to stay clear of a few things (you can't use Generic instruments, Nasal libs,...) but that should be doable. You can charge license fees for such a plane, and nobody may legally re-distribute it.

the data is parsed from the XML into dynamic look up tables (IE. STL). The only resources used beyond that needed to make the FDM function is the overhead of pulling the data out of the XML into memory. That would have to happen no matter what form the data was in. Although there may be better ways to store the data than XML if you are unconcerned about human interaction with the data. I think that making the data human readable/editable is the main point of using XML. It may be overly verbose but it works and there are standard libraries for reading/parsing XML files so this makes using it for data input fairly simple. This benefits both FlightGear and JSBSim in terms of limiting the complexity of handling configuration data. In addition there are a limited number of standardied formats for this type of thing such as JSON and all of those that are human readable/editable have many of the same issues as XML. Full function FDMs are complex and understanding the XML used to configure a complex FDM is a very minor issue and anyone who actually understands a full function FDM will have very few issues with the XML part of this.

FG itself is OpenSource, so whatever protection scheme we may code in, anyone is free to remove (and that's quite legal). It'd be a no-brainer to generate a no-copyright-protection version of FG and distribute it on which your content just runs without the key (or whatever). Given that people usually succeed in cracking DRM schemes in the absence of an open source code, trying to do this with the source code open for anyone seems just a waste of time. Second, whatever format OSG reads, before it arrives at the renderer, it's bound to be an array of vertices. The renderer needs this, there's no decryption at the GLSL stage. So chances are that since we run on *Open*GL, again anyone who really wants can write out an unencrypted format.

as FlightGear is open source, it is incredibly simple to add some code to access the 3D scene graph and extract the full aircraft model (scripts excluded, though they could be reverse engineered). The information is just sitting there, fully visible, and ready to be picked off the OSG branch like a big juicy peach. I could probably write this code in half a day, but converting into AC3D format, PNG textures, etc. to recreate a new copy of the aircraft would take a little longer. If FlightGear was closed source, it would be much harder to write OSG extractor code, but nevertheless still doable.

We have support for catalogs and external hangars for precisely this reason. We obviously want to encourage GPL aircraft, but not every aircraft developer wishes, or is able to, release their work under the GPL. FlightGear both respects and supports that option.

You could certainly run the FDM model externally and use one of the many Network I/O options in FlightGear to pass data back and forth. Quite a few research projects have done this in the past to use FlightGear as a visualiation tool. By extension you could do the same for scripting - have the scripting run externally and interact with FlightGear via one of these protocols.

if you actually try to charge 100$ for a FG plane, you won't find too many customers... because FG is mainly popular in the OpenSource community. If you make it too cumbersome with DRM schemes, maybe someone will try to circumvent it just as a matter of principle (people do this for sport...) - but across multiple platforms, it's actually not easy to make this not an annoyance for the user.

The thing to keep in mind is that no matter what your source format is (dll, encrypted+signed, binary, etc.), ultimately your model mesh and textures and logical structure are read into internal OSG class structures. Once that has process has completed so the model can be rendered on screen, a person could call the appropriate write*File() function to save out your model's subtree into any of the supported formats. The only thing that is needed is access to the FlightGear source code to insert the function call in a strategic location. Ultimately, you can't completely protect your content work if you don't also completely control the situation at the application source code level. And this is a classic copy protection hacking strategy, insert the magic in the code after the distribution format has been authenticated/loaded/decoded and then write it out in a 'decrypted' format. People do it all the time, even with proprietary code. The value of the target usually determines how hard they are willing to work to steal it.

Adding support for DRM to FlightGear is not going to happen - Nasal scripts are provided in plain text format by default (similar to JavaScript), while obfuscation is of course possible - it doesn't make any sense in the context of FlightGear as an open source project.

Also, scripts can be easily shared and run by users just by exchanging or copying them.

Even if you were to dump intermediate Nasal bytecode to an object file and execute this using the Nasal VM, there would be no way of enforcing DRM.

Of course, FlightGear being open source, you could also just add support for DSOs/plugins to a fork of FlightGear and base all your work on this fork - on the other hand, your modifications would still need to be made available.

there's is a way to make legal closed-source add-ons: You can write all your "secret" c++ as an external application, and let that communicate with FlightGear via sockets. This should work reasonably well. But I don't expect that you'll get many customers. First of all, at least on Linux, nobody is keen to run binary blobs, which could easily wipe out your home directory while you are toying around in FlightGear. And then, there's so much Free aircraft development going on, with a lot of momentum, that you'll probably always be behind. And those developers have close ties to the (or are) FlightGear coders, so they have the advantage that they can change the FlightGear code to their liking, at any time. They can change the interface at will, and you have to catch up ... and deal with customer complaints, who suddenly sit on a broken binary blob that doesn't work with the last FlightGear release. And finally, this socket approach works only via property system, and that's open for inspection to anyone (apart from the recently added semi-secret vector property garbage).

FlightGear has no provision to load aircraft from shared libraries. You can distribute your aircraft under a proprietary license, like Vitos does, but not as a shared library. It would take a lot of work to change FlightGear so it can load aircraft from shared libraries. Who would do that work and why would anyone do that when their time could be spent improving free software? And why would the core developers of FlightGear accept such a "contribution"?

Realistically, if you want to sell a commercial aircraft, your customer base is going to be Flight Sim X, X-Plane, Prepar3D. You're simply not going to get any traction in the FlightGear ecosystem. It's not built for it.

Besides, OSG's scripting language support (lua) cannot access all the internals Nasal does, simply because there was no glue code implemented in FlightGear. So no properties for you and no access to internal function call which does Nasal provide.

You own copyright of your work even if you license it GPL, and you may develop your work further and release a more complete version under a commercial license if you like (that's a variant of dual licensing). The only way to not retain copyright of what you do is to transfer it to someone else or to relinquish it by releasing your work into public domain. If you create a 3d model for a FG aircraft and license it GPL, nobody prevents you from adapting and selling it for X-plane. In fact, you can sell it also for FG (but others may re-distribute it as they like once they buy it since it is GPL, so it may not be a too viable business model)

Do other sims offer content encryption or content protection? For instance, I've been able to locate and test a blender plugin that can open up many MSFS aircraft models. How about xplane? It's been a *long* *long* time since I fiddled with their package, but at the time I was paying attention, all their 3d formats were open and well defined. Often the commercial sims will store things in their own binary formats, but in most cases these aren't encrypted and the end users figure these out pretty quickly -- so they can either edit the content or create new content with the same format. I wouldn't consider a binary format much of a content protection scheme ... especially in an open source project where the source to load and store the binary format is readily available. I understand the desire for content creators to not get "ripped off". But also understand that one of the main reasons that FlightGear can be successful is because we make all the source code and content open. If we didn't make everything open, then we wouldn't get nearly the same amount of volunteer contributions and high quality volunteer contributions is the critical reason why FlightGear has been so successful. If we were a closed off commercial outfit, who would want to pitch in and help someone else make money? But with everything open, you know that your contributions can be enjoyed equally by everyone else, just as much as you are enjoying everyone else's contributions. There are some low-lifes out there that try to make a profit on other people's work, and will gladly lie and misrepresent things to swindle as much money as possible from unsuspecting end users. But the truth is that these people have always existed, and will always exist. They are remarkably good and persistent at copying things ... going so far as to break copy protection schemes, reverse engineer hardware designs, copy the exact look of products (even including the logo.) This isn't a problem that is unique to the FlightGear project -- and it's something we would still face no matter how hard we worked to create copy protection schemes. If you designed a binary content format, someone will reverse engineer it. If you design an encryption scheme, someone will just modify the sim code to dump out the decrypted version after it's been loaded into memory by the proprietary decrypting plugin. (If not outright break the encryption scheme or steal your encryption keys.) In all these case, the content can still be easily copied, replicated, sold, etc. The best scheme I've seen is something that has a node-lock key that will only run on a single PC (key'd to mac address, or processor id.) But this implies a more complicated 2 step install where the user must come back to you after installing the product, report their unique id, get a key, and then install that key before they are able to run. And the problem with all of this is that in an open source project, someone could simply compile a new version of the simulator that skips the key check or accepts a trivial key, or any key. I'm just thinking down various avenues here, but hopefully you can see that what seems like a simple request at first is actually quite complex and creates all kinds of down stream issues (both technically and with user support.) And at the end of the day, the bad guys can usually find work arounds anyway and aren't slowed down too much. When farmers grow crops, they have to put up with weeds. We can try reasonable things to minimie the weeds, but if you are too aggressive at killing the weeds and don't tolerate a single one, then you most likely end up killing much of your crop too. So it's my view that this is something we just have to put up with. We can try to take reasonable steps to minimize the problem, but we can't eliminate all the bad guys without harming all the good things about our project.

Once you have distributed source code under the GPL you explicitely declared that it's everyones right to redistribute and modify it - as long as he/she doesn't distribute it under a different license But you, as the copyright holder, can change the license for new versions you haven't yet distributed under the GPL - as long as those modifications weren't made by others, i.e., as long as you are still the sole copyright holder (or you'd have to come to an agreement with the other contributors, but you can only ask nicely). You, as the sole copyright holder, also can distribute it under several licenses at once, e.g. the GPL and some propiratory li- cense (making it worth the money people may pay for it by faster bug fixes, only distributed to the paying customers etc.).

Another thing to consider is that distributing your aircraft as a .dll or .so doesn't hide or obfuscate your code and textures after they have been loaded into the simulator structures for rendering. The rest of FlightGear is open-source so it wouldn't take much effort to insert an OSG function call to save out the aircraft (models and textures) in some other common 3d format. There would be some loss in terms of the organiation of the source files, but even so, it would give someone who's intention is to copy or modify the work a place to start. All the xml config should be there for free in the property tree. The licensing of nasal (I believe) is written in a way that makes it difficult to distribute proprietary nasal code. So there would be some really significant challenges to making a FlightGear aircraft that is secure from modification, not to mention copying.

The key for an open source project is not if you can win a legal argument or not. Rather, it is to avoid any legal argument in the first place, and at all costs. Meaning to stay out of court. To use something like this safely in an open source project, I would suggest something along the following lines:

• Making your derivative product public, in full (but unlicensed, saying it is copyrighted material),
• Going to the owners of the original data product, giving them a link to your derivative product,
• Asking them to make a public statement that the derivative product can be licensed using the "GPLv2 or later version" licence,
• Make sure to ask them to identify the public derivative product as a link, and identify all its parts (to avoid them saying at a later date that you included bits of the protected material),

Any statement they make on the web can be backed up on the web archive ( http://web.archive.org/ ). To simplify the process, you could draft part of the statement detailing the derivative product in full, with all details. With this, there will no longer be any shades of grey! If they are happy to do this, then it is legally no problem to use (i.e. the grey situation has shifted to white). If they are not happy with your proposal, then they could turn around one day and sue (i.e. the grey situation has shifted to a clear black).

The open-source world depends on license terms and copyrights and cooperation and trust to protect our work. We put up with a small subset of people who willing abuse those terms and hope that larger group peer pressure will keep the bad actors in check. Sometimes there is legal recourse, sometimes it is tough to do anything about it when problems span country boundaries (or when someone just wants to break the rules for their own self serving reasons.) My feeling though is in the long term, most people are honest and do wish to do the right thing, and the small group that is truly there to cause problems or just serve themselves at the expense of others will never endure as long as the larger group of people with good intentions. In the end, you have to make your own determination of how much effort you put into a model, versus how much money you could make selling it, versus the risk of someone copying and distributing it themselves, versus the legal costs to try to stop them.

DRM workarounds

For one of my past projects I had to deal with a proprietary flight dynamics model. I initially used the ethernet interface so it could run as an external stand alone application. Then later I switched to a unix two-way pipe arrangement so I could have tighter synchroniation with the execution order, but still the external program was completely independent and stand alone. I'd love to make everything free and open-source, but this was a case where I didn't have a choice and it was something purchased from a 3rd party company with strict terms. I felt that two independent self sufficient programs (that could talk to each other and exchange information) created sufficient license separation to honor FlightGear's gpl license terms.

For what it's worth, the "ExternalPipe" fdm was setup to cover much of the areas you have touched on. It's probably not exactly what you want but here was some of my logic in how/why I setup it up the way I did.

• Using a network interface adds some indeterminism ... sometimes network packets are delayed or stack up depending on what is going on with the machine so there isn't a guaranteed lockstep relationship between the simulator the the flight dynamics.
• Usually the network interface is good, but I observed times when it had extra delays in packets getting where they needed to go.
• As an alternative, I setup a pair of "named pipes". Pipes are a unix construct, they look like a file to the program, but what you write into them is collected and held for some other application to read out. Unfortunately these are not supported in windows. Pipes are single direction, thus the need for two of them for bi-directional communication. A pipe is really simple: you open it up like any other file, and one process writes into it; the other process reads from it. In between the OS can buffer some amount of information until the reader grabs it. You can use blocking reads (carefully) to ensure FlightGear and your external FDM run in exact lockstep.
• Pipes imply both processes will run on the same machine, a network interface would allow the processes to live on separate machines.
• The ExternalPipe interface supports a flexible property interface, so the external FDM process can send any name/value pairs it wishes to send and the interface will dutifully copy them into the FlightGear property tree. The FDM side can also send a list of property names it would like to receive in reply and the interface will dutifully send them over the outgoing pipe every frame. This was a nice addition, and there is plenty of bandwidth through a named pipe to do this in clear text, even with a lot of extra property values.

History: I used this as part of a project I did with ATC flight sim. They had their own proprietary flight dynamics applications that modeled specific aircraft in the code itself. These models had all the necessary source documentation and flight test data to satisfy FAA certification testing requirements of the final simulator. In addition, this external code modelled many of the aircraft systems for one of their high end sims. This required the ability to be flexible in what values were sent back and forth and enabled me to drive some instrument gauges directly from the external code.