Board index FlightGear The FlightGear project

bundling GPL'ed contents with non-GPL materials

Questions about the FlightGear organisation, website, wiki etc.

bundling GPL'ed contents with non-GPL materials

Postby Hooray » Wed Nov 18, 2015 11:03 am

Subject: Su-15
Thorsten wrote:Edward recently taught me a few interesting things about how GPL actually works in less known context - relevant here, we had an instructive discussion about what happens when you bundle something with GPL content and reviewed what the Free Software Foundation has to say on that point.

The relevant distinction is whether you introduce a dependency on GPL material, notable by the runtime exchange of information back and forth from your own material and the GPL material you're bundling with (as Hooray put it The only distinction that the GPL makes is that code has to be running the same process/address space as the GPL'ed code - which is to cover DLLs, DSOs, dynamically linked libraries.).

So you can not bundle your own code with a GPL'd dll and license the bundle under something that is not GPL.


Actually, I was referring specifically to code that is linked into the same address space - as long as you use open interfaces, that are not specifically created/used to circumvent the provisions of the license -but that are commonly used elsewhere (e.g. multiplayer protocol, property tree, http, telnet), you are free to use GPL'ed components with non-GPL'ed components, which explicitly includes shipping/bundling.

Apart from that, it does not matter whether you are turning the GPL code into a library or the proprietary code - ultimately, what does count is that the corresponding code (machine code/binary code) is loaded into the same address space, which is "tainting" the whole address space, so that it becomes subject to the GPL and its requirements.

However, that is only relevant once you release/distribute any such works, because at that point you must also grant all the privileges to the recipients of your work.

None of this would affect the screen shot/screen-grabbing use-cases that were mistakenly raised by others - equally, just running a non-GPL'ed aircraft in FG does not trigger the GPL.

In those cases, you can consider FlightGear like a word processor, whose underlying license does not affect the work you create, and taking screen shots of the word processor itself would only ever affect the contents shown in it, but never the word processor itself - which could /in theory/ be much more critical in the case of a word-processor (showing proprietary data/documents) than a screen shot of a flight simulator, whose content can never be completely shown, i.e. no matter how many screen shots you will take, you will never be able to extract/derive all of the information required to re-create the 3D model, the FDM, Nasal scripts etc.

In terms of FlightGear, it being GPL'ed, what counts is the degree of "tight coupling" vs. "lose coupling" - which primarily affects code-like components, especially those explicitly licensed to fall under the GPL, e.g. all the Nasal/Canvas modules (where were not re-created by vitos, or he would have to write directly to the property tree, instead of using api.nas)
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: 11968
Joined: Tue Mar 25, 2008 8:40 am

Re: bundling GPL'ed contents with non-GPL materials

Postby erik » Wed Nov 18, 2015 12:12 pm

Just for clarification:

You can use non-GPL material in GPL software as long as the license of the non-GPL material allows it.

You may not use a GPL-ed static or dynamic library in non-GPL compatible software.
That's why there is LGPL.

You may not use an LGPL-ed static library in non-GPL compatible software.
You may, however, use an LGPL dynamic library in non-GPL compatible software

You may always interface with GPL software using sockets and/or pipes.

Hope this clarifies it a bit.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby Thorsten » Wed Nov 18, 2015 12:40 pm

Well, I think we may agree that if I use e.g.

Code: Select all
geo.aircraft_position();


somewhere in my aircraft's Nasal code that this constitutes a relevant dependency on geo.nas - which was the original point.
Thorsten
 
Posts: 11748
Joined: Mon Nov 02, 2009 8:33 am

Re: bundling GPL'ed contents with non-GPL materials

Postby bugman » Wed Nov 18, 2015 1:02 pm

Thorsten wrote in Wed Nov 18, 2015 12:40 pm:Well, I think we may agree that if I use e.g.

Code: Select all
geo.aircraft_position();


somewhere in my aircraft's Nasal code that this constitutes a relevant dependency on geo.nas - which was the original point.


This is a grey area - it definitely not black and white. Because this could be called linking, but it could also be seen as using the FG API. The first you are not allowed to do, the second you are. Another shade of grey comes from fair use, as the code in the backend is as trivial as it gets:

Code: Select all
var aircraft_position = func {
   var lat = getprop("/position/latitude-deg");
   var lon = getprop("/position/longitude-deg");
   var alt = getprop("/position/altitude-ft") * FT2M;
   return Coord.new().set_latlon(lat, lon, alt);
}


Anyway, I think this would be more seen as using an API, with the Coord object being part of that API. Just like software using the Linux APIs, or Unix APIs, will not result in a licence violation, it is likely that the same would be found in this case. But only a court can decide such things. A clearer example would be something like the use of the following line:

Code: Select all
    <path>Aircraft/Instruments-3d/comp/comp.xml</path>


If the XML file this is found in is not GPLv2, this is direct inclusion or linking which would result in a GPL violation, as the included component is GPLv2+.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby Hooray » Wed Nov 18, 2015 1:21 pm

This is a grey area - it definitely not black and white.

http://aicoder.blogspot.com/2009/08/gpl ... uages.html
http://lukeplant.me.uk/blog/posts/python-and-copyright/
http://programmers.stackexchange.com/qu ... -languages
http://stackoverflow.com/questions/3141 ... -languages
http://www.phoronix.com/forums/forum/ph ... rification
http://blog.openviewpartners.com/linkin ... date-2011/
https://news.ycombinator.com/item?id=3836384

For some FG specific context, see: viewtopic.php?f=4&t=13615&

If you think that there's still room left for "interpretation", feel free to get in touch with the FSF and specifically ask for clarification regarding the concrete use case in FlightGear:
A dynamically-interpreted scripting language is used to load/include existing SCRIPTED GPL'ed code, which in turn leverages a mix of binary LGPL/GPL APIs code, and how that relates to the code including said GPL'ed scripting space wrappers to use these abstraction layers using aggregation/composition etc, instead of using the established/open IPC mechanism (aka the property tree via telnet) directly

(even if you don't intend to review all the links above, it may help to forward those links to the FSF to make the point that this is indeed a controversial/frequent issue, and that extending the FAQ accordingly, would make sense).

Personally, I don't need any clarification, I with Thorsten on that one - it is far from controversial. But it may be good for the FlightGear project, and other OSS projects, to clarify exactly how the viral nature of the GPL affects interpreted code by using GPL'ed modules

PS: It doesn't matter the slightest bit if the exposed GPL'ed framework/API is trivial behind the scenes (or not even subject to the GPL, e.g. public domain), as long as it is used, the GPL applies - simple as that.
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: 11968
Joined: Tue Mar 25, 2008 8:40 am

Re: bundling GPL'ed contents with non-GPL materials

Postby erik » Wed Nov 18, 2015 1:51 pm

Thorsten wrote in Wed Nov 18, 2015 12:40 pm:Well, I think we may agree that if I use e.g.

Code: Select all
geo.aircraft_position();


somewhere in my aircraft's Nasal code that this constitutes a relevant dependency on geo.nas - which was the original point.

This is not an easy one but since the code from geo.aircraft_position() does not get copied into the aircraft code, nor does it get included into a binary form, I would consider this to be dynamic linking.

So now the question is, is fgdata GPL or LGPL.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby Hooray » Wed Nov 18, 2015 2:01 pm

so far, $FG_ROOT/Nasal is GPL - so that the case is pretty clear-cut, especially involving modules written by mfranz (see the archives for his statements).

What is happening behind the scenes is that the Nasal code is parsed, compiled into bytecode to be run by the Nasal VM, where it sits next to other Nasal code, including even C APIs mapped to Nasal callbacks.

The XML example mentioned above is also very clear-cut, because the only thing that is relevant here is the degree of tight coupling, and the XML include directive really being nothing else than a property-tree read/write operation, where a XML tree is mapped into the tree to load resources from disk - the whole thing could even take place at the property/telnet or http level, so there is no tight coupling at all, which is why it is problematic to use the GPL for data (see the GNU GPL data loophole).

The property tree being the established IPC mechanism for proprietary software.

All this is going to become increasingly interesting if/once FG/SG start using HLA/RTI, because then the GPL can be circumvented entirely, which is why the AGPL is commonly used by distributed software projects
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: 11968
Joined: Tue Mar 25, 2008 8:40 am

Re: bundling GPL'ed contents with non-GPL materials

Postby bugman » Wed Nov 18, 2015 2:05 pm

@Hooray: I think I completely missed the point of your post.

Hooray wrote in Wed Nov 18, 2015 1:21 pm:to clarify exactly how the viral nature of the GPL affects interpreted code by using GPL'ed modules.


Firstly including GPL code in your own non-GPL code does not force you to GPL your code - it simply means you are violating someone else's copyright and can be whacked on the head with the full force of the law. There's nothing viral about intellectual property theft. You can avoid the copyright violation by GPLing your own code, if you so wish, but the copyright violation would have already have occurred anyway so you can still be taken to court for damages.

By the way, viral in the context of the GPL is a Microsoft invented FUD word. Ballmer's attempt at using this FUD failed, and he quickly dropped that strategy. I find it strange that you continue to propagate this Microsoft FUD.

PS: It doesn't matter the slightest bit if the exposed GPL'ed framework/API is trivial behind the scenes (or not even subject to the GPL, e.g. public domain), as long as it is used, the GPL applies - simple as that.


Well, actually it is quite important if ever taken to court. It will be how damages are calculated.

Also, I am a FSF member and I don't see a need to contact them for this. I personally don't need any legal clarifications, as it's pretty clear to me. The following is confusing:

    A dynamically-interpreted scripting language is used to load/include existing SCRIPTED GPL'ed code, which in turn leverages a mix of binary LGPL/GPL APIs code, and how that relates to the code including said GPL'ed scripting space wrappers to use these abstraction layers using aggregation/composition etc, instead of using the established/open IPC mechanism (aka the property tree via telnet) directly

It needs to be broken down to individual parts, otherwise it is obfuscating the different issues. A GPL-licensed interpreted scripting language cannot enforce a licence choice on the code it runs. A GPL-licensed API cannot enforce a licence choice either. This is pretty black and white. The quality of the API itself, if using an established/open interface or the world's worst interface is irrelevant. If you include parts of the code of the scripting language or API into your project, then that is a violation. Therefore I do not understand what the post was about.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby bugman » Wed Nov 18, 2015 2:07 pm

erik wrote in Wed Nov 18, 2015 1:51 pm:I would consider this to be dynamic linking.


Is this dynamic linking or simply providing a public API? This distinction is rather important.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby erik » Wed Nov 18, 2015 2:12 pm

The (L)GPL is about being able to replace (L)GPL code with your own improved version.
There is nothing in the aircraft files that prevents you to add your own version of the Nasal geo class by calling the function. Hence it should be considered dynamic linking.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby bugman » Wed Nov 18, 2015 2:12 pm

Here is the origin of the viral FUD with respect to the GPL:


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

Re: bundling GPL'ed contents with non-GPL materials

Postby Hooray » Wed Nov 18, 2015 2:16 pm

you also missed to parse the last paragraph correctly (I never said anything along the lines of the interpreter's license being relevant to this at all!), which is why we agree on your final conclusion. :D

If I make a GPL'ed piece of code in an interpreted language, I am not merely just providing a "public API", but an actual module that will be subject to the GPL license - the module being written in plain text, and dynamically inerpreted/compiled by a VM has no bearing on the repercussions of the GPL.

Equally, the term "viral" is well-suited to illustrate how using a GPL'ed module affects your own code.

As you can see, clarification really is needed - you being a member of the FSF or not: And here's full disclosure, I used to make a living integrating proprietary software with GPL/open-source, all within the terms of the license - all reviewed by teams of lawyers to be on the safe side, which is why I am perfectly aware what tight coupling entails and what it doesn't.

I would be very surprised if you could get the FSF to update/clarify their FAQs to match the standpoint you are communicating here with regard to 1) scripted GPL code and the repercussions of using it, 2) how loading an XML file into a publicly-accessible tree data structure is a violation of the GPL.

(no offense intended or taken, but as you can see, we fundamentally disagree here)
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: 11968
Joined: Tue Mar 25, 2008 8:40 am

Re: bundling GPL'ed contents with non-GPL materials

Postby bugman » Wed Nov 18, 2015 2:17 pm

Hooray wrote in Wed Nov 18, 2015 2:01 pm:so far, $FG_ROOT/Nasal is GPL - so that the case is pretty clear-cut, especially involving modules written by mfranz (see the archives for his statements).

What is happening behind the scenes is that the Nasal code is parsed, compiled into bytecode to be run by the Nasal VM, where it sits next to other Nasal code, including even C APIs mapped to Nasal callbacks.


Does this mean that anything run on the Nasal interpreter must be GPL? In the last sentence, 'Nasal' can be replaced by 'Python' and all of the statement still holds. However Python programs do not need to be licensed under the Python licence, so why would Nasal be in any way special?

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

Re: bundling GPL'ed contents with non-GPL materials

Postby bugman » Wed Nov 18, 2015 2:23 pm

Hooray wrote in Wed Nov 18, 2015 2:16 pm:Equally, the term "viral" is well-suited to illustrate how using a GPL'ed module affects your own code.


No, not at all. The owner of the GPL code cannot in any way force the owner of the non-GPL code to change the licence. This is complete nonsense! The GPL code owner can however take the non-GPL code owner to court for copyright violations and, as history has shown, the GPL code owner will win. Just because two parts need to both be GPL to be legally combined, this does not imply a viral nature of the licence.

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

Re: bundling GPL'ed contents with non-GPL materials

Postby Hooray » Wed Nov 18, 2015 2:24 pm

re: Nasal/Python: no it doesn't apply that way: the whole point is not the license of FG, SG or the Nasal interpreter - but merely the pre-existing libraries/modules that are located in $FG_ROOT/Nasal are explicitly GPL'ed - so there is nothing specific to Nasal here, it is just that it loads GPL'ed code and makes that available to other scripts. If Nasal wasn't a scripting language, you would have to dlopen the DSO and obtain a handle to the API or link in the corresponding modules statically.

So far, the FlightGear project does not make any difference between GPL'ed code in SG/FG and GPL'ed Nasal code in $FG_ROOT, and there also is no separate "API license" that would allow you to just consider all modules "APIs" that can simply be reused "as is".

Keep in mind that in a dynamic language, you don't need to use copy/paste to modify a program, but can accomplish the same thing at run-time.

Again, if you can get the FSF to clarify the GPL FAQ accordingly, that would be great - even if you should prove me wrong (which I find highly unlikely, but I won't be bothered by standing corrected!)

EDIT: Because you specifically mentioned Python and GPL code: Here's the same discussion about Python:
http://programmers.stackexchange.com/qu ... 3-licensed
http://blog.devork.be/2009/11/python-mo ... t-get.html
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: 11968
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest