Board index FlightGear Development Aircraft

GPLv2+ vs. GPLv3+ licensing for FGAddon.

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

Re: What is the procedure for commit our work on FGAddon ?

Postby Hooray » Fri Jan 05, 2018 2:34 pm

Just be aware of the likely/potential legal repercussions of using any GPL'ed module written in Nasal, according to bugman's posting a while ago, there's roughly 28k LOC in the form of Nasal code in fgdata (the base package):

FGData SLOCCount support.
bugman wrote:I have been playing around with the SLOCCount program and have added Nasal support:


Is it legal to sell models of aircraft you created?
curt wrote:Here's a quick answer: if the model is entirely your work (3d models, textures, xml animations, flight dynamics, etc. etc. etc.) then you are free to do whatever you like with it.

If you have pulled in bits and pieces of other people's work, or if it's "just" a repaint, then you need to abide by whatever license the original work came with ... typically that is going to be GPL for the FlightGear project. If it is GPL, then you could sell a distribution of your aircraft, but you also then have to make your derivative work available for free as well.


bundling GPL'ed contents with non-GPL materials
bugman wrote:If you run in the FG virtual world, access and modify the property tree, call FGData Nasal functions, this is all a cleanly defined interface or API you are working through (even if the API is not perfect). In this case, there is clearly no licensing requirements. If you include a part of FGData into your aircraft, via a <path>, <file>, <xzy include="...">, etc tag, then there is a clear licensing requirement.


Su-15
bugman wrote:FGData is essentially a 'GPL licensed library'. It's clear that including any parts of FGData in an aircraft, linking to it via a single XML or Nasal line, an aircraft must be GPL. That is indisputable.


Back from being banned ...
bugman wrote:The official FlightGear infrastructure simply follows the legal requirements as governed by the GPL v2.0 licence and copyright law. Any legal requirements lower than that are by definition illegal.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11376
Joined: Tue Mar 25, 2008 8:40 am

Re: What is the procedure for commit our work on FGAddon ?

Postby stuart » Fri Jan 05, 2018 5:19 pm

Very minor clarification:

erik wrote in Thu Jan 04, 2018 3:38 pm: Update, according to:
http://wiki.flightgear.org/FGAddon
In August 2015, a new FlightGear policy document was written to codify the unwritten standards of the project[8]. With this document, the licensing policy for the FlightGear aircraft has been updated from being GPLv2-only to now being a GPLv2+ or GPL-compatible[9] stance. However, to combat licence proliferation complications for the integrity and good of the FlightGear project, it is strongly recommended that original content be GPLv2+ licensed.



I think that wiki article is incorrect. Reading the actual Policy Document. http://www.flightgear.org/flightgear-policy-document/, FGAddon is GPL2+, defined as " GNU General Public License V2.0 with the “or any later version” option (GPL2+)" higher up in the document.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: What is the procedure for commit our work on FGAddon ?

Postby abassign » Fri Jan 05, 2018 5:48 pm

bugman wrote in Fri Jan 05, 2018 11:12 am:@Abassign: Although you state benefits for GPLv3+, which is true, it doesn't matter. FlightGear is GPLv2+ (and compatible). You have to take it or leave it.
Regards,
Edward


erik wrote in Fri Jan 05, 2018 2:03 pm:Well there have been GPLv3 aircraft accepted for inclusion in FGAddon in the past (Pilatus PC-9 and variants) which I would hate to see revoked.
Erik


All the opinions I read are interesting, while using the GPLV3+ instead of the GPLV2+ does not seem to change anything in terms of use within a GPLV2 environment etc ... They are all compatible as written on the GNU site and for that that I knew. Of course they are not backwards compatible!

But this post:

AndersG wrote in Fri Jan 05, 2018 10:42 am:...
To this I just want to add that in my opinion using GPL v2+ for both the core FlightGear and FGAddon is a strong benefit as it allows content to move freely between the core and FGAddon as needed.


It is very interesting how much it refers to the reuse. A product released under the GPLv3 + license, even if divided into sub-parts, makes it necessary for the other product to take the same GPLv3 + license. This is one of the reasons why the GPLv3 + license is stronger than the GPLv2 +.
The difference between the GPLv2 + license and the GPLv3 +, however, limits the reuse of parts, being our aircraft full of sub-parts, all very distinct and with their own code (even if sometimes redundant), I realized it just for this purpose. At this point I have to surrender to the evidence that in order to contribute, with some parts that we are making, to other projects and vice versa for others who want to work with us, it is better to use the GPLv2 + for this project too.
abassign
 
Posts: 823
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: What is the procedure for commit our work on FGAddon ?

Postby erik » Sat Jan 06, 2018 8:23 am

stuart wrote in Fri Jan 05, 2018 5:19 pm:I think that wiki article is incorrect. Reading the actual Policy Document. http://www.flightgear.org/flightgear-policy-document/, FGAddon is GPL2+, defined as " GNU General Public License V2.0 with the “or any later version” option (GPL2+)" higher up in the document.

FGAddon is advertised as a repository of individual projects and every developer is responsible for their own project. Which implies there is no interconnection between aircraft in FGAddon.

Which makes me think there is no need to be strictly GPL2+ anyhow. The only restriction would be a GPL compatible license so they can be shipped by Linux distributions.

Erik
erik
 
Posts: 1522
Joined: Thu Nov 01, 2007 1:41 pm

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby bugman » Mon Jan 08, 2018 9:55 am

@Erik: I've updated the wiki to show all of the GPLv3 or GPLv3+ aircraft. In most cases, I cannot tell the exact licensing conditions, and some could be GPLv3-only! Some are derived from GPLv2+ sources, so forcing GPLv3-only is anyway not possible.


Note the big warning in the aircraft infoboxes about using parts of these aircraft. I can see that the vast majority of these aircraft are from Petar Jedvaj, StuartC and other members of FGUK.

Having GPLv3+ content in FGAddon can be problematic. In a way, this is like a trojan horse. If content from a GPLv3+ aircraft is copied into a GPLv2+ aircraft, then legally the GPLv2+ aircraft must be updated to GPLv3+. This is because you cannot mix GPLv2 and GPLv3 content into one 'product' - i.e. a whole aircraft. So developers might accidentally and unknowingly update their licences to GPLv3+. Therefore I think that GPLv3+ content should be minimised. And GPLv3-only content avoided.

If you are an author of one of these aircraft, I would suggest considering dual licensing so that the external repository is GPLv3+, but the content ported into FGAddon is GPLv2+. Note thought that all authors would need to agree on any licence change (unless their changes were originally GPLv2+).

Regards,
Edward

Edit: Fixed the RAH-66 link.
bugman
Moderator
 
Posts: 1719
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby erik » Mon Jan 08, 2018 1:16 pm

For one thing: The PC-9 derivatives originate from my original PC-7. Much of it is still in place and I think the GPLv3 only applies to the 3d model. But is a bit blurry without much investigation.

Erik
erik
 
Posts: 1522
Joined: Thu Nov 01, 2007 1:41 pm

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby bugman » Tue Jan 09, 2018 8:37 am

The PC-7 is GPLv2+, so if a fork is created with GPLv3+ content, then the "whole" would be automatically GPLv3+. I could fork your PC-7 and simply change the licence to GPLv3+, with no other changes, and that is perfectly legal. The point of the + part (or or later text), is to allow for a licence upgrade by a project when the legal need arises, but without having to obtain written permission from every last code/content author. I find this table to be quite useful:


This FSF quote from the above link is interesting:

When we say “copy code,” we mean just that: you're taking a section of code from one source, with or without modification, and inserting it into your own program, thus forming a work based on the first section of code. “Use a library” means that you're not copying any source directly, but instead interacting with it through linking, importing, or other typical mechanisms that bind the sources together when you compile or run the code.


For FlightGear content you would replace "program" with "aircraft" (or other craft/content/etc.), and "code" with "content". So the quote would read as:

When we say “copy [content],” we mean just that: you're taking [content] from one source, with or without modification, and inserting it into your own [aircraft], thus forming a work based on the first [content]. “Use a library” means that you're not copying any [content] directly, but instead interacting with it through linking, importing, or other typical mechanisms that bind the [content] together when you [fly the aircraft].


;)

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

Re: What is the procedure for commit our work on FGAddon ?

Postby bugman » Tue Jan 09, 2018 12:53 pm

stuart wrote in Fri Jan 05, 2018 5:19 pm:I think that wiki article is incorrect. Reading the actual Policy Document. http://www.flightgear.org/flightgear-policy-document/, FGAddon is GPL2+, defined as " GNU General Public License V2.0 with the “or any later version” option (GPL2+)" higher up in the document.


Stuart, which part is incorrect? Do you mean the following highlighted text?

In August 2015, a new FlightGear policy document was written to codify the unwritten standards of the project[8]. With this document, the licensing policy for the FlightGear aircraft has been updated from being GPLv2-only to now being a GPLv2+ or GPL-compatible[9] stance. However, to combat licence proliferation complications for the integrity and good of the FlightGear project, it is strongly recommended that original content be GPLv2+ licensed.


Or do you mean the recommendation, or simply "GPL-compatible"? In this text, I've used the FSF notation of GPLv2 (they also sometimes use the GPL2 notation).

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

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby erik » Wed Jan 10, 2018 9:18 pm

bugman wrote in Tue Jan 09, 2018 8:37 am:The PC-7 is GPLv2+, so if a fork is created with GPLv3+ content, then the "whole" would be automatically GPLv3+. I could fork your PC-7 and simply change the licence to GPLv3+, with no other changes, and that is perfectly legal. The point of the + part (or or later text), is to allow for a licence upgrade by a project when the legal need arises, but without having to obtain written permission from every last code/content author.


First of all I didn't mind the license change.
But the situation is a bit different, they did not copy my work, the started with it and added GPLv3 components. I could still remove the GPLv3 content and have a GPL2+ version again. But since I don't mind I'll rather leave it the way it is.

Erik
erik
 
Posts: 1522
Joined: Thu Nov 01, 2007 1:41 pm

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby stuart » Wed Jan 10, 2018 9:35 pm

Hi Edwards,

I meant the "GPL-compatible" phrase. The Policy document only talks about aircraft within the context of FGAddon, and states they need to be GPL2+.

That particular paragraph in the wiki is inaccurate and confusing on two accounts. 1) The Policy document doesn't make any statement about FlightGear aircraft in general - just the license requirement for FGAddon. You could create an aircraft under any license you wish, provided you obeyed the license requirements of any work you used.

2) If it's referring to aircraft in FGAddon, they need to be GPL2+, not "GPL-compatible".

I think it needs to be changed to read something like "With this document, the licensing policy for the FlightGear aircraft hosted on FGAddon has been updated from being GPLv2-only to now being a GPLv2+. To combat licence proliferation, avoid complications using work from one aircraft in another, and for the integrity and good of the FlightGear project, it is strongly recommended that all original content (whether hosted in FGAddon or elsewhere) be GPLv2+ licensed. "

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby bugman » Mon Jan 15, 2018 8:23 am

@Stuart: I've updated the FGAddon wiki text with your corrections.

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

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby bugman » Mon Jan 15, 2018 8:38 am

I have been in contact with the Free Software Foundation's licensing department to help clarify the "or later" licensing clause. I have to correct some of my previously mentioned points:

  • GPLv2+ and GPLv3+ licensed content can be used within one project (see below).
  • A second party who is not the original author can update the licence from GPLv2+ to GPLv3-only (though the FSF recommends updating to GPLv3+, keeping the "or later" option).

My way of explaining this for FG content would be:

  • Component A (software, data, etc.) is GPLv2+ licensed.
  • A second author creates component B, which is GPLv3+ licensed.
  • The second author takes A and combines it with B to produce the combination C.
  • The combination C is therefore GPLv3+ licensed.
  • But A can remain GPLv2+ licensed.
  • So someone can take A from C and incorporate it into a GPLv2-only or GPLv2+ project.
  • But anyone, including the author of C, can convert A into GPLv3+ (or the not recommended GPLv3-only condition) from the original GPLv2+, even without modification.
  • So then the original A can be incorporated into a GPLv2/GPLv2+ project, but the modified parts of an updated GPLv3+ A component cannot.

I hope this makes sense.

Regards,
Edward


Edit: This means that if you take a small amount of GPLv3+ content into your project, the whole project is automatically GPLv3+ licensed (thought the original parts are not). The same for GPLv3-only.
bugman
Moderator
 
Posts: 1719
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby abassign » Mon Jan 15, 2018 11:44 pm

bugman wrote in Mon Jan 15, 2018 8:38 am:I have been in contact with the Free Software Foundation's licensing department to help clarify the "or later" licensing clause. I have to correct some of my previously mentioned points...


Thank bugman, what you wrote is exactly what I know about mixed GPL licenses and I apply in the SW development world.
In these days I am increasingly convinced that there is no problem to release our modules under GPLv3 +, because, being separate modules, anyone can combine them with other modules with different licenses.

I thought that some modules, like the XML used in the root and the FDM JSBSim were comfortable to release them under GPLv2 + because they can be easily used for other projects (I do not know if it will happen, but it is a possible hypothesis), while those more related to project to release them under GPLv3 +. I do not know it's just an idea, so I was thinking of inserting the license for every single folder as our modules are very modular.
For example, other multimedia modules (we are sampling sounds from a real G91R), they may very well be released under GPLv2 + as they often mixed with systems sounds that are already correct for our work.

The problem that I pose now is another if we distribute our work for the individual modules (there are several tens) under license GPLv3 + is this compatible to be inserted in the main repository of FGFS?
I theoretically, I see no problem, but in practice will we have oppositions that can prevent us from giving our work to the FGFS community?
abassign
 
Posts: 823
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby bugman » Tue Jan 16, 2018 8:25 am

abassign wrote in Mon Jan 15, 2018 11:44 pm:In these days I am increasingly convinced that there is no problem to release our modules under GPLv3 +, because, being separate modules, anyone can combine them with other modules with different licenses.


This is not correct. This would only be the case if you had an API defined for the module, and you would then need to use the GNU Lesser General Public License (LGPLv3+). Then, and only then, can you do this. Note section 5c of the GPLv3:

5. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.


You will have a very hard task to argue in court that your aircraft is not a whole. Let me quote the Free Software Foundation licensing department:

What Constitutes the Entire Work?

One common way of combining programs is to "link" them so that one program can use routines from another. Developers typically talk about "static" linking, when code from various source programs are copied together into a combined executable which is then made available to users, and "dynamic" linking, when one program isn't linked to another until the two are executed together on a user's system.

With static linking, it is self-evident what code is part of the source code for that entire program. It includes, at least, the source code for all modules linked together in the binary.

Developers often find this point not quite so self-evident with dynamic linking, but the situation is equally clear: if you distribute modules meant to be linked together by the user, you have made them into a combined work, and you must release the entire combined work under the GNU GPL.

In other words: dynamic vs. static linking never makes any difference on the outcome of the analysis.8 The FSF has been advised by several US lawyers on this matter over the years, and the answer is always this one. Unsurprisingly, some lawyers have been willing to defend a different interpretation when it suits their clients, but their arguments are weak and disputed by the majority of experts.


This comes back to the API and LGPLv3+ licensing. You aircraft parts are not defining an API between themselves. FGFS via SimGear provides this API, not the aircraft components! FGFS would actually be classified as an "interpreter", and then from the FSF GPL FAQ:

If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?

When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.

However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.

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.


Note also the following: When combining GPLv3+ content with GLPv3-compatible licensed content, the whole or combination is GPLv3+ licensed. The same goes for GPLv3-only content. This is incompatible with the current state of the FlightGear project and FGAddon which is GPLv2+.

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

Re: GPLv2+ vs. GPLv3+ licensing for FGAddon.

Postby abassign » Tue Jan 16, 2018 6:17 pm

bugman wrote in Tue Jan 16, 2018 8:25 am:Note also the following: When combining GPLv3+ content with GLPv3-compatible licensed content, the whole or combination is GPLv3+ licensed. The same goes for GPLv3-only content. This is incompatible with the current state of the FlightGear project and FGAddon which is GPLv2+.


Clear agreements long friendship ("Patti chiari amicizia lunga in Italian ... ")

By virtue of your excellent work of verification and interpretation of the GPL licenses you have made, I think it is clear that:

It is not very practical to use mixed modules in the case of FGFS GPLv2 +, so the most suitable thing for the project, which wants to enter the official repository, and serve the community, is to release it entirely under GPLv2 +.
If so, as I already anticipated a few days ago, we defined that type of license for the entire project of the G91-R1B_HD that we want to release in alpha version as soon as possible.
Last edited by bugman on Tue Jan 16, 2018 10:25 pm, edited 1 time in total.
Reason: Quoting fix.
abassign
 
Posts: 823
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 3 guests