Board index FlightGear The FlightGear project

bundling GPL'ed contents with non-GPL materials

Questions about the FlightGear organisation, website, wiki etc.

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

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

Hooray wrote in Wed Nov 18, 2015 2:24 pm: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!)


I still don't understand what needs clarifying. Let me make the following analogy:

    FG+Nasal vs. Python: I see these as equivalent. Running a Nasal script or Python script is very similar in concept. And you are free to choose the licence of your script in both cases. And who knows, maybe FG+embedded Python as a replacement for FG+Nasal might occur one day, but that won't change the licensing conditions.

    FGData vs. numpy: I also see these as equivalent. Numpy is a Python 'site-package' which is stored in a separate location (it is often in the Python directories, but it does not have to be). It provides an API for performing numerical calculations, and will often return its own numpy array-type objects. Calling numpy.eye(3) to return a numpy array object for an identity matrix does not force my code to use the numpy licence. Calling geo.aircraft_position() to return the Coord object for the coordinates likewise does not force my code to use the FGData licence.

Regards,
Edward
bugman
Moderator
 
Posts: 1805
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:46 pm

There is no need to drag the compiler (nasal) into the discussion: It is perfectly legal to compile closed source code using gcc and it's perfectly legal to compile GPL code using MSVC.

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

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

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

I'm retaining the Nasal interpreter in the argument due to historical arguments earlier pointed to:


I think this is quite important to clarify:

Hooray wrote in Mon Nov 07, 2011 9:39 pm:The thing to keep in mind here is that due to FlightGear being GPL, its the viral nature of the modules you are relying on - such as by using any of the standard Nasal modules in $FG_ROOT/Nasal. Just making use of another Nasal module, is the tightest possible form of "linking" in scripting space.


Regards,
Edward
bugman
Moderator
 
Posts: 1805
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 3:02 pm

I still disagree, the runtime modules for Nasal are the source code and therefore dynamically linked at 'run time'.

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

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

Postby Hooray » Wed Nov 18, 2015 3:05 pm

right, the compiler's license has no bearing on this at all - please consider reviewing the links that I posted, or alternatively, get in touch with the FSF.

If in doubt, review the python-gpl related links posted earlier.
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

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

Postby bugman » Wed Nov 18, 2015 3:09 pm

I still don't get what is being argued here? Would it be this statement:

All Nasal scripts must be without question GPL licensed


In a single simple sentence, what would I ask the FSF about?

Regards,
Edward
bugman
Moderator
 
Posts: 1805
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 3:15 pm

"The FlightGear project is using a dynamically-interpreted/compiled scripting language, FlightGear's data assets provide a library with a huge number of pre-created scripted modules for use by developers, these modules are GPL'ed - how does this affect code written by aircraft developers that is leveraging these GPL'ed modules via the equivalent of include/require/import statements which load/parse/compile this code into bytecode loaded into the VM?"

To make the case, you can forward pretty much all the links previously posted, i.e. the impact of using GPL'ed modules in scripted languages, which proves that the whole discussion is not specific to FG.

(PS: it isn't helpful to discuss numpy here, which is BSD-licensed, also this doesn't address the other misconception about loading XML into a public tree data structure explicitly designed for IPC, including proprietary programs)
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

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

Postby bugman » Wed Nov 18, 2015 3:42 pm

Hooray wrote in Wed Nov 18, 2015 3:15 pm:"The FlightGear project is using a dynamically-interpreted/compiled scripting language, FlightGear's data assets provide a library with a huge number of pre-created scripted modules for use by developers, these modules are GPL'ed - how does this affect code written by aircraft developers that is leveraging these GPL'ed modules via the equivalent of include/require/import statements which load/parse/compile this code into bytecode loaded into the VM?"


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. Is this not correct?

To make the case, you can forward pretty much all the links previously posted, i.e. the impact of using GPL'ed modules in scripted languages, which proves that the whole discussion is not specific to FG.


I have read those posts, and all I get is the impression that there are a lot of confused people out there. Which is not surprising, as copyright law is not written for normal people to understand. Interestingly, many mention the word 'viral' as well, which tells me that a lot of people listened to Microsoft's FUD, which probably lead to their confusion. To me, a collection of confused people posting on the internet does not make a case.

(PS: it isn't helpful to discuss numpy here, which is BSD-licensed, also this doesn't address the other misconception about loading XML into a public tree data structure explicitly designed for IPC, including proprietary programs)


Ok, then try ScientificPython. This uses a rather special licence. In any case, the issues come down to copyright law and not the copyright licence.

Regards,
Edward
bugman
Moderator
 
Posts: 1805
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 3:49 pm

I am inclined to follow Richard's suggestion not to waste our time with academical debates like these - as far as I am concerned, we can also agree to disagree - that is, until the FSF clarified the FAQs accordingly, at which point you can send me a reminder if I should be proven wrong :D
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: 11987
Joined: Tue Mar 25, 2008 8:40 am

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

Postby Thorsten » Wed Nov 18, 2015 6:30 pm

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


In what way is calling FGData-residing Nasal functions a cleanly defined interface?

They're internally treated the same as copied-over functions, there's two-way exchange of information happening, there's no restrictions on what FGData residing functions you can call, no 'hidden' internal space or encapsulation, if you know the name you can call it, there's a clear dependency (you can't remove the FGData Nasal and expect your code to still run) - the situation has all the characteristics of linking to a lib and none of a general purpose interface.
Thorsten
 
Posts: 11752
Joined: Mon Nov 02, 2009 8:33 am

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

Postby Richard » Wed Nov 18, 2015 7:02 pm

My final word on the subject follows:

A model that has copies of anything that is GPL within the distribution has to be GPL because that is the only way[1] that the distributor of the model can licence the GPL material being distributed.

It is section (5) of the GPL v2 that makes this clear.

Running (or developing) a model under FlightGear does not make that model licenced under the GPL[2]. A model does not become GPL because it has a call that could be executed by FlightGear unless that model ships a copy of FlightGear or a copy of the dependency

It is the copying of protected material that Copyright Law applies to. If you do not distribute a copy of copyrighted material then the Copyright Law does not apply as there is no protected material being copied.

Our community respects author's wishes and maintaining a positive culture under which creative works can be made is much more important than wasting precious development time[3] discussing licences.

--------------
[1] Unless the distributor licences these under a different licence, or negotiates rights with the author of anything that is distributed
[2] in the same way that a spreadsheet created in Open Office does not become GPL when you have a call to AVERAGE(A1:A2) within in.
[3] I realise I'm still doing it. I'm going to stop now and get back to doing something useful.
Richard
 
Posts: 785
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

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

Postby Johan G » Thu Nov 19, 2015 12:58 am

I can only agree with Richard and bugman.

To use the Nasal vs. Python analogy again,* consider that the built in Python operators/functions/classes are only a small subset of what is included in the Python distribution. The Python distribution also contain a large number of libraries that extends the language, akin to how $FG_ROOT/Nasal scripts extend Nasal.

Calling functions of those Python libraries from your source code (while not copying source from them) does in no way force you to use the Python license. In a similar way I can not possibly see how calling (not copying) functions from Nasal scripts would force one to to adopt the license of the source from those.

* Note that FSF list some versions of the Python license as GPL compatible, see https://www.gnu.org/licenses/license-list.html#Python.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6055
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

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

Postby Thorsten » Thu Nov 19, 2015 6:57 am

In a similar way I can not possibly see how calling (not copying) functions from Nasal scripts would force one to to adopt the license of the source from those.


GPL says you can't link to a GPL library and license the resulting product not GPL. That's not copying, that's just function-calling. You can only bundle GPL and non-GPL if they talk via a generic interface (html, ...)

The only difference between Nasal in an aircraft-side folder and Nasal in FGData is the directory it is in. There's no API defined to keep them apart. A different directory isn't an interface

However Python programs do not need to be licensed under the Python licence, so why would Nasal be in any way special?



The page linked by you explains that Python is special to specifically avoid that issue:


(1) GPL-compatible doesn't mean that we're distributing Python under
the GPL. All Python licenses, unlike the GPL, let you distribute
a modified version without making your changes open source. The
GPL-compatible licenses make it possible to combine Python with
other software that is released under the GPL; the others don't.



GPL-compatible is not the same as GPL - it just means 'can be used with GPL', not 'requires you to do the same things as GPL'.

Given that the Python license makes it very clear that it is different to GPL, I wonder why the analogy was even brought up. Different licenses evidently have different restrictions.


Running (or developing) a model under FlightGear does not make that model licenced under the GPL[2]. A model does not become GPL because it has a call that could be executed by FlightGear unless that model ships a copy of FlightGear or a copy of the dependency



That's not the issue here. You can run a non-GPL model under FG as long as it talks to FG via generic interfaces. However, specifically with Nasal, no such argument can be made (unless a directory suddenly becomes an interface).

While the origin of the GPL is rooted in copyright and FG can be licensed GPL because we're collectively copyright holder, once the GPL license is valid, it can restrict not only what you can copy of the software but also what you can do with the software (case in point - google Earth is something google has copyright for, so they can license it how they want, so they can allow only certain use cases and in particular prevent us from using it to determine the location of buildings automatically for our own purposes - we're not trying to copy their code, the information itself (location) is public and can't be copyrighted - we're just not allowd to use the product to obtain it).

Similarly the GPL license can prevent you not only from copying but also from using software in a certain way.

It's just wishful thinking that licenses only apply if you want to copy something.

Our community respects author's wishes and maintaining a positive culture under which creative works can be made is much more important than wasting precious development time[3] discussing licences.


What we do as a community is not relevant for how the license works - how the license works however needs to be relevant for what we do as a community. So please stop mixing a license discussion with positive culture in our community - if X is a copyright violation, there's no point in us being positive about it, we have to deal with it.
Thorsten
 
Posts: 11752
Joined: Mon Nov 02, 2009 8:33 am

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

Postby bugman » Thu Nov 19, 2015 8:01 am

Actually, I was probably a little confused and therefore I'll take this statement back:

bugman wrote in Wed Nov 18, 2015 3:42 pm: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.


This is also allowed. The reason why these things are allowed is because Nasal (and the whole FG environment for that matter) are interpreted and not pre-compiled. As such the aircraft developer is not compiling this into a single unit, so there is no copyright violation. This is the key to it all - has there been a copying of copyrighted material that the developer is now distributing, or not? If these arguments about license violations would in fact hold, then the whole Python, Perl, and Java software worlds with their huge arrays of differently licensed modules would simply not be possible. Or the wiki with all its differently licensed extensions. It would lead to an absurd situation.

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

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

Postby Thorsten » Thu Nov 19, 2015 8:05 am

Did you even read what I wrote? Say about Python? Why would Python see the need to license GPL compatible if things were that simple?

GPL isn't just about copying, that's a red herring.
Thorsten
 
Posts: 11752
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest