Frequently asked questions: Difference between revisions

Jump to navigation Jump to search
m (→‎The FAQ: DRM / contentt protection (this needs some TLC ... but seems like a recurring topic))
Line 227: Line 227:


=== Content Protection ===
=== Content Protection ===
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) <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35073832/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>
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.<ref>{{cite web
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.<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/27998023/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/27998023/  

Navigation menu