FlightGear and content protection (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, e.g. proprietary aircraft. [1][2][3]
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.[4]
it is completely up to the original content author to decide how they wish to license their original work. GPL is just one option. Many people seem to prefer one of the variants of the creative commons license these days. If you are modifying someone else's original work, or incorporating portions of their work into your own work, then you must be respectful of the original author's license terms. If you wish to protect your work from being copied or modified (yet somehow still distribute it to users), FlightGear does not have the infrastructure built up to assist with that. Fgaddon is simply a resource offered to aircraft designers. It is a common area to share and collaborate for aircraft development. Historically it has also been the source of FlightGear aircraft that are included in the official distribution. Because fgaddon is closely tied to the main project, we do our best to ensure everything there is licensed with a gpl compatible license so we can safely distribute all those aircraft. We also do our best to ensure that fgaddon aircraft track upstream code changes in the flightgear program so that incompatibilities are not introduced. As others have said, the intention of FlightGear and our evolving infrastructure is to support and encourage 3rd party hangars, and we have no problem if developers want to use other resources to manage and distribute their original aircraft. It is especially important to maintain separation of content with gpl-incompatible licensing.[5]
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"?[6]
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) [7]
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. [8]
please do ask about setting up your own hangar with whatever license you like. One of the major goals is to give a better end-user experience for different sources of aircraft.[9]
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.
Feasibility
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.[10]
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.[11]
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.[12]
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.[13]
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.[14]
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.[15]
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.
Still, 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).
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. [16]
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. [17]
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.[18]
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.).[19]
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.[20]
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).[21]
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.[22]