Board index FlightGear Development Aircraft

Aircraft CC and GPL License and non-GPL FGAddon Question

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Aircraft CC and GPL License and non-GPL FGAddon Question

Postby Octal450 » Mon May 18, 2020 2:42 pm

Hi,
Wanted to get some opinions based off a thought I had lately.

If I were to create a JSBsim and systems for an aircraft, who's 3D model was only available under CC Share Alike Non Commercial, are my systems and FDM restricted to the same license when included in the same folder? Or, may I license my files under GPL and leave the 3D and such under CC (which a notice obviously for explaining it)

Lets say assuming that the author of the 3D doesn't want to use GPL.

All in all such a plane will never end up in FGAddon, I am wondering, in addition, what if there was to be a Non-GPL FGAddon as well, that could be optionally switched on in the launcher (such as how linux distros will ask if you want to use non-free software for certain devices and such during install).

Just want to gather some opinions since there are many nice planes without GPL around.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11, A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Development Discord|Airbus Development Discord
User avatar
Octal450
 
Posts: 4629
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby Figaro » Mon May 18, 2020 3:42 pm

Omega95, for a while, licensed his A380-omega in this way, so it's been done before.

As always, as long as attribution and licensing is clear, that's what's important.

-S
User avatar
Figaro
 
Posts: 1325
Joined: Fri Feb 25, 2011 9:23 pm
Callsign: 4L-FIG
OS: ElementaryOS/Win10

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby D-ECHO » Mon May 18, 2020 4:02 pm

About mixing GPL and non-GPL, I haven't really understood it yet and I think there is quite a lot of discussion about it. In case someone's interested, here are some different articles and also an older discussion about this:
https://quoderat.megginson.com/2009/06/ ... rspective/ (blog entry)
https://forum.osdev.org/viewtopic.php?f ... 32&start=0 (from another forum)
https://softwareengineering.stackexchan ... nse-mixing (stackexchange)
And some parts of the official FAQ:
https://www.gnu.org/licenses/gpl-faq#IfLibraryIsGPL

About a nonGPL-fgaddon: I think there are two sides to this. On one hand, it would be good to have such a repository as to allow users to have a more convenient way of getting programs that are under a license e.g. not permitting commercial use. On the other hand though, every user of FG profits of the GPL. FG as a whole has profitted in the past from being e.g. open to commercial applications, thus gaining contributors and relevance (paraphrased from a comment on this issue I read some time ago which I agree to). Coming from this, FG has an interest in promoting using GPL, also because it means that parts of it can be re-used in other official FG aircraft and maybe as well in the core (think navdisplay work). When looking at it from this POV, making a nonGPL-fgaddon might lead to more people using CC NC instead of the GPL which could harm the project and thus FG would be basically harming itself by installing said repository.

I hope this makes sense ;)
User avatar
D-ECHO
 
Posts: 2053
Joined: Sat May 09, 2015 12:31 pm

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby Thorsten » Mon May 18, 2020 5:16 pm

I guess you won't convince the FG project to officially endorse anything that's not GPL - for the reasons D-ECHO has outlined. People can have their private hangars, but from the core development POV the deal is 'I have invested lots of time to create something GPL, now someone else wants to use this for his own work but not return in kind and rather license in a different way' - that's not attractive at all.

From the developer side, there's also the disappointment theme - I can use XY with FG, but I may not actually work with it. So if it's not GPL, I simply never look further, no matter how good it may or may not be - because if it is good, I still can't really work with it, adapt things from it and so on.
Thorsten
 
Posts: 11616
Joined: Mon Nov 02, 2009 8:33 am

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby Octal450 » Mon May 18, 2020 5:37 pm

Thx for the infos..

Well unless that 3D guy will reconsider or someone else will make a new 3D, I guess one project will be outside of FGAddon forever :(

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11, A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Development Discord|Airbus Development Discord
User avatar
Octal450
 
Posts: 4629
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby Thorsten » Mon May 18, 2020 5:52 pm

Yeah, it's generally unfortunate that much really excellent 3d work is not GPL compatible...
Thorsten
 
Posts: 11616
Joined: Mon Nov 02, 2009 8:33 am

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby bugman » Mon May 18, 2020 10:00 pm

I've discussed this one extensively on this forum. One relevant post might be:

bugman wrote in Mon May 30, 2016 9:27 am:Hi abassign,

As I said before, if you create your own 3rd party hangar, as has been done in the FlightGear community consistently for the last 20 years, you are free to do as you wish.

That being said, you should carefully research open source licence compatibility. The reason being that you may loose legal control over one part of your aircraft due to licence clashes and ambiguity. Let me explain. First I'll break this up into different groups of people:

  • 3D content creator - this person can licence their content as they wish. They can distribute their content under their chosen licence. But if they distribute it with the rest of the aircraft, they then fall into the aircraft distributor category.
  • Aircraft distributor - this person is bound by the licences of all parts, and has fully legal responsibility for that copyrighted content.
  • End user - they have no legal responsibility and can enjoy the aircraft.
  • 3rd party - if someone forks the repository or creates a new repository and it is online, they become an aircraft distributor.
Here I am referring to the actions of the aircraft distributor, which can importantly cause the 3D content creator's models to fall under a different licence that they never intended. Firstly you need to understand the distinction between 'mere aggregation' and 'combining two modules into one program'. This is the language of the GPLv2. From the GPLv2 FAQ:

GNU GPLv2 FAQ wrote:What is the difference between "mere aggregation" and "combining two modules into one program"?
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

For aircraft in FlightGear, you have XML which glues everything together. You could leave it to a court to decide if this is aggregation or a whole, but because of this essential 'XML glue', they will very likely decide that this is a whole. The 'XML glue' is not a communication method. What does this mean? It means ambiguity with the licensing. A 3rd party could take the aircraft and decide that due to the licence clash of this "whole", that the GPLv2+ licence applies also to the 3D model. You would then have to sue this person to protect the rights of the 3D content creator, but because the court is likely to decide that this is a whole and not a mere aggregation, you probably won't be able to get the 3D model back. The only way would be if the 3D modeller has a court decision showing that you as a distributor were wrong to bundle the differently licensed content, and then the 3rd party also has no right to distribute the 3D model as GPL.

For a list of licences compatible with the GPL, see:

Note that you can use the GPLv3+ and CC-BY-SA-4.0, as these licences are deliberately compatible with each other. If you do not believe this assessment, please email <licensing att fsf.org> with the link to my post here. You will then receive a very definitive response!


Regards,
Edward


Edit:. So if you do not distribute, you can do what you want. But if you distribute the bundle, licence incompatibility would trigger the invalidation of all open source licences involved. So you would be distributing copyrighted content without a licence.
bugman
Moderator
 
Posts: 1777
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby amue » Tue May 19, 2020 6:25 am

bugman wrote in Mon May 30, 2016 9:27 am:For aircraft in FlightGear, you have XML which glues everything together. You could leave it to a court to decide if this is aggregation or a whole, but because of this essential 'XML glue', they will very likely decide that this is a whole. The 'XML glue' is not a communication method. What does this mean? It means ambiguity with the licensing. A 3rd party could take the aircraft and decide that due to the licence clash of this "whole", that the GPLv2+ licence applies also to the 3D model. You would then have to sue this person to protect the rights of the 3D content creator, but because the court is likely to decide that this is a whole and not a mere aggregation, you probably won't be able to get the 3D model back. The only way would be if the 3D modeller has a court decision showing that you as a distributor were wrong to bundle the differently licensed content, and then the 3rd party also has no right to distribute the 3D model as GPL.

Ok, lets assume an aircraft in FlightGear (consisting of 3D model, XML configuration files, Nasal code, FDM files,...) forms a "whole" and not an "aggregation" (I too tend to the "whole" notion, but I think there are different opinions about that in the FG community).
That would mean that if I use a CC NC licensed 3D model then all other files (XML, Nasal code, FDM,...) can not be GPL if I want to distribute the aircraft to prevent the "licence clash".
But what about using Nasal in said files? I think it's allowed to use Nasal core functions (similar to writing a non-GPL program that runs in a GPL-licenced interpreter). But how about using Nasal libraries what fall under GPL (e.g. Canvas, ...). Is there a documentation/reference what Nasal functions/libraries can be used from Non-GPL code and what Nasal function are covered by GPL?
amue
 
Posts: 51
Joined: Tue Apr 03, 2018 9:13 am

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby D-ECHO » Tue May 19, 2020 6:40 am

As far as I know there is no such list, probably also because noone can say for sure what would in court be ruled as aggregation and what as a whole.
But I remember to have heard that the canvas nasal API would already be considered to only be usable from GPL code.

@bugman: Thank you very much for this explanation, I find it very clear and understandable.
User avatar
D-ECHO
 
Posts: 2053
Joined: Sat May 09, 2015 12:31 pm

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby bugman » Tue May 19, 2020 7:43 am

amue wrote in Tue May 19, 2020 6:25 am:Ok, lets assume an aircraft in FlightGear (consisting of 3D model, XML configuration files, Nasal code, FDM files,...) forms a "whole" and not an "aggregation" (I too tend to the "whole" notion, but I think there are different opinions about that in the FG community).


No, there is only one single person that has forwarded that option - Simon (a.k.a. Bomber). Note he has been permanently banned.

That would mean that if I use a CC NC licensed 3D model then all other files (XML, Nasal code, FDM,...) can not be GPL if I want to distribute the aircraft to prevent the "licence clash".
But what about using Nasal in said files? I think it's allowed to use Nasal core functions (similar to writing a non-GPL program that runs in a GPL-licenced interpreter). But how about using Nasal libraries what fall under GPL (e.g. Canvas, ...). Is there a documentation/reference what Nasal functions/libraries can be used from Non-GPL code and what Nasal function are covered by GPL?


This is simple. Is the code distributed with the aircraft? If you distribute a "whole", then all licences must be compatible for them not to be voided. If you don't distribute the code, then you are not bound by the licence.

Regards,
Edward
bugman
Moderator
 
Posts: 1777
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby D-ECHO » Tue May 19, 2020 7:48 am

I think this isn't everything there is to that @bugman. IIRC, even code that is not included in the aircraft, but used e.g. as an API (canvas nasal API for example), can influence the aircraft's license, as it might make the aircraft part of the whole instead of a seperate package. I'll try to find the relevant discussion.

[EDIT] This thread in general: viewtopic.php?f=42&t=28025 with these posts specifically: viewtopic.php?f=42&t=28025&start=30#p284893 (the "Thorsten wrote" part I mean)
User avatar
D-ECHO
 
Posts: 2053
Joined: Sat May 09, 2015 12:31 pm

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby bugman » Tue May 19, 2020 8:08 am

The key here is that it is only "distributors" that are legally liable. The end users combining content are not. The distributor of solely a CC-BY aircraft does not violate the licence if it uses a non-CC-BY API. But the FlightGear project is liable for all it distributes. So the project will only ever distribute GPL and public domain (or CC0) content. Hence no non-GPL aircraft in FGAddon, and no non-GPL Nasal in FGData.

Regards,
Edward
bugman
Moderator
 
Posts: 1777
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby D-ECHO » Tue May 19, 2020 8:12 am

Ah okay, thanks for clarifying this
User avatar
D-ECHO
 
Posts: 2053
Joined: Sat May 09, 2015 12:31 pm

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby amue » Tue May 19, 2020 9:01 am

D-ECHO wrote in Tue May 19, 2020 7:48 am:This thread in general: viewtopic.php?f=42&t=28025

Thanks for the link. In this thread Thorsten linked and quoted the relevant GPL-FAQ part:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html.en#IfInterpreterIsGPL
Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.

A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way
, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.


That clarifies it for me: If the aircraft contains code that calls/uses any Nasal code from &FG_ROOT/Nasal then the code (and the aircraft) can not be distributed under a non-GPL-compatible license.
amue
 
Posts: 51
Joined: Tue Apr 03, 2018 9:13 am

Re: Aircraft CC and GPL License and non-GPL FGAddon Question

Postby Richard » Tue May 19, 2020 10:53 am

amue wrote in Tue May 19, 2020 9:01 am:That clarifies it for me: If the aircraft contains code that calls/uses any Nasal code from &FG_ROOT/Nasal then the code (and the aircraft) can not be distributed under a non-GPL-compatible license.


The licence can only be applied if you include licenced, copyrighted materials with your distribution.

Referring to, or using licenced material that is distributed separately (e.g. fgdata) does not affect your distribution; so in this case you can refer to anything from FGData because FGData is distributed with FlightGear and not your distribution.

It is the act of distributing (copying) material that causes licences to be required.
Richard
 
Posts: 772
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Next

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 2 guests