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.

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

Postby Thorsten » Wed May 20, 2020 6:34 pm

I think your argument is unclear because you have not precisely defined where the line is for a "whole". What about say a call to parsexml(), which is just a wrapper for the Expat XML C++ code. Does calling that function mean that Expat is part of your aircraft "whole"? What about the Nasal core library functions verses the FGData extension functions? Where is the line? And why do you make a distinction between Nasal and C++, when functionality X could be implemented in either and exposed by one extension function?


This sounds like an evasion rather than a counter-argument to me - you're dodging the question - is there a magical transformation of 'GPL licensed library' to 'component of operating environment' or not?

Once we agree that there is no magical tranformation, we can discuss where the line is.

My position on that is rather simple - if it looks like a library, is structured like a library, is optional like a library and is used like a library - then it very likely IS a library and should be treated as such,

I can't rule out that there's a clever lawyer who can convince a judge that what you say is okay - but as far as I am concerned, I don't see how any amount of twisting and turning can make it okay to use a GPL library in non GPL code, sorry.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby Hooray » Wed May 20, 2020 7:26 pm

In a scripting environment (Perl, JavaScript, Pyhthon, Ruby, Nasal) - the mere act of importing/including or requiring another module (library) is a form of linking. The GPL does not differentiate between such linking in scripting space or linking dynamically in the form of DSOs/DLLs

If linking happens in a non-optional fashion or if removing the importing statement entails a significant loss of functionality, the imported module is obviously essential and its license would impact the importing application/script.

PS: As mentioned previously, the Canvas API/library is not necessarily a suitable example, and even the Canvas system as a whole can be used without triggering the GPL/LGPL. Overall, the Affero GPL would seem like a much better fit for most fgdata needs, especially for anything going through IPC-enabled systems like the property tree (+ sockets). In the same vein, FlightGear's GPL'ed Nasal code could be trivially mapped to a networking mechanism to circumvent the GPL altogether.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

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

Postby portreekid » Wed May 20, 2020 8:11 pm

As a Java architect I come across this question regularly. Any import aka usage of a GPL class will trigger copyleft. I'd be really astonished if the situation of Nasal in fgdata would be different. More reading https://opensource.stackexchange.com/questions/412/do-i-have-to-release-my-code-as-gpl-when-a-java-library-is-gpl
portreekid
 
Posts: 651
Joined: Tue Jan 14, 2014 4:36 pm
Location: Leipzig
Callsign: PORTREE
Version: 2020.2.1
OS: Windows 10

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

Postby Hooray » Thu May 21, 2020 1:30 pm

Agreed, any posting/referencing of FSF links (no matter if done by "FSF members" or not) without also acknowledging that "Nasal" isn't any different from Python, JavaScript or here, is deluding ourselves.

Besides, using FSF terminology, there is the notion of "tight coupling"(effectively a single derivative work/program) vs. "loose coupling", i.e. "integration at arms-length" (freely/independently, as a separate optional entity which is to be set up/configured explicitly - aka "integrat-able" vs. "actually integrated").

https://www.gnu.org/licenses/gpl-faq.ht ... leasedMods
[...] a situation where the web site contains or links to separate GPLed programs that are distributed to the user when they visit the web site (often written in JavaScript, but other languages are used as well). In this situation the source code for the programs being distributed must be released to the user under the terms of the GPL.


And in fact, the FSF recognizing that the GPL may often not be what people/developers want when GPL'ing their scripted libraries, explicitly cover this case in their FAQs and encourage adding a custom exception, because otherwise the GPL would apply - as per: https://www.gnu.org/licenses/gpl-faq.html#WMS

https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins
When is a program and its plug-ins considered a single combined program? (#GPLPlugins)

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.


For that very reason, there is the GPL linking exception: https://en.wikipedia.org/wiki/GPL_linking_exception

https://en.wikipedia.org/wiki/GPL_linki ... _exception
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version.


In other words, the use of the GPL for fgdata contents was/is a rather controversial choice, and one that may need to be reconsidered/refined some day, as can be seen by other projects affected by the effects of the GPL on their scripted APIs/libraries, often causing unintended consequences.

If in doubt, feel free to reach out to the FSF to ask for clarification directly (especially if you are a "FSF member") -or just run a forum search: bundling GPL'ed contents with non-GPL materials



https://lmgtfy.com/?q=python+import+gpl+module
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

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

Postby bugman » Thu May 21, 2020 1:48 pm

The magical transformation is how copyright law, which is country specific, defines the "entire work" or "whole". There is nothing more to the question. These terms are from the GPL, but I guess this is simply defines copying or not.

The abstract term of software "library" and the FSF FAQ talking about static or dynamically linking libraries cannot automatically be connected via the word "library" to say that they will be treated the same under copyright law.

Java is obviously different to the situation described in the FAQ. I do not know why Sun Microsystems decided that the classpath execption to the GPL is necessary. At what point is there a potential copyright violation? On disk, in memory, elsewhere? Where and what is the "whole"?

In the case of FlightGear, where is the "whole" created? Is the Nasal code really being loaded into the same shared memory as the rest of the craft? Or are both bits of code parallely serially executed in the same Nasal interpreter instance but from different memory locations, communicating via the property tree API? These are the types of question that need to be asked so that we can put into writing what the "whole" craft consists of.

Regards,
Edward

Edit: I meant serial rather than parallel.
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

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

Postby Hooray » Thu May 21, 2020 2:02 pm

Speaking in general, there is no "parallel execution" when it comes to Nasal and specifically Nasal in FlightGear, except for the use of the threading library (which is rarely done by any code/aircraft, except maybe for the shuttle's trajectory calculation helpers). Otherwise, all instances of a Nasal interpreter share a single global data structure, Nasal code is parsed and compiled and turned into byte code, and interpreted by a virtual machine (VM).

As such, there is no notion of separation or even an "execution boundary": once you have a piece of Nasal code, it is always parsed and compiled - as such, there is no difference between a piece of code executed via the Nasal console or a library of code written by a number of contributors written over the course of many months/years: under the hood, the bytecode will end up in the same address space, and since there is no TLS being used, even all threads will share the same address space provided by the fgfs process.

Let's suppose the Canvas APIs are indeed a controversial examples, so let's say this is about the shuttle and its library of code (modules): Someone wanting to use some portion of said code, could either use copy/paste coding to get that functionality, or they could import the shuttle's version, or add a copy of the relevant code to the new aircraft in question and load it via the -set.xml file or some other "dynamic" mechanism: what is happening behind the scenes is that the shuttle's Nasal module(s) in question will indeed be parsed and compiled and then the internal situation is no longer different from copy/paste, because Nasal's internal data structures will indeed keep a copy of the shuttle's code in memory, and it will not look, or behave, any different from other ways of leveraging that code.

Just because there is no binary created (executable or DSO/DLL) doesn't automatically invalidate the GPL here - the "whole" is a set of functionality that would not be available without including/importing the corresponding code routines, otherwise there would be no point in requiring those - but the very instant such modules are indeed required, this becomes a derivative work, because the new work seizes to function properly without the corresponding import/include/require statement.

As has been said previously, the key question remains one of distribution obviously.

But like you also mentioned, spreading out the execution of key functionality over different processes/machines is a sure way to circumvent the GPL, which is why the Affero GPL would have been a much better choice for functionality that may sooner or later end up being invoked via IPC/RPC means.

As a project, FlightGear is not particularly good at getting its act together to self-organize and act properly and address such challenges, especially when legal matters are involved - but the question does remain relevant, not just for fgdata/fgaddon contributions in the future, but especially due to the fairly new "addon" system, which implements a plugin mechanism on top of these very Nasal mechanism. And the GPL is a particularly unsuitable choice here due to its nature.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

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

Postby Thorsten » Thu May 21, 2020 3:57 pm

The magical transformation is how copyright law, which is country specific, defines the "entire work" or "whole". There is nothing more to the question. These terms are from the GPL, but I guess this is simply defines copying or not.


Thinking this to its logical end the only possible conclusion is that aircraft and FG are 'a whole' and that you basically can't have any non-GPL aircraft - since it is always possible to legally move stuff from aircraft to FGData and back (and some aircraft even reside on FGData and historically the whole collection has been there), there is no real difference introduced by the fact that FG happens to maintain two repositories.

(Note - that's not my position, that's just inescapable when following your assertion).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby stuart » Thu May 21, 2020 4:13 pm

Hooray wrote in Thu May 21, 2020 1:30 pm:In other words, the use of the GPL for fgdata contents was/is a rather controversial choice, and one that may need to be reconsidered/refined some day, as can be seen by other projects affected by the effects of the GPL on their scripted APIs/libraries, often causing unintended consequences.


Got any evidence to back that up? The use of GPL for fgdata was not nor is in any way "a controversial choice". Fundamentally FlightGear has been from the very start an open source GPL project, and fgdata is a part of that.

If some aircraft or scenery developers choose to develop aircraft/scenery under some other license, that's their choice and their responsibility to ensure that what they do complies with the GPL.

I don't see any reason to revisit that decision just because some 3rd party addon would prefer for it be NC CC, or whatever other license they choose.

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

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

Postby Hooray » Thu May 21, 2020 5:32 pm

I don't disagree with the underlying sentiment - but the point still is valid, as is exemplified by numerous discussions like this one, where contributors were surprised to learn that their work should be subject to the terms of the GPL due to their use of /some/ Nasal modules originating from fgdata or some GPL'ed aircraft.

In other words, actual contributions that were not in line with the requirements of the GPL, including work contributed by some of the most senior contributors of the project, and that had to be subsequently "pulled" because such contributions would have opened a whole can of worms (legally speaking).

In fact, to some extent, this is also exemplified by very different positions communicated by senior contributors in this very topic.

Again, I don't disagree with the fact that the GPL has served the project rather well, but we have countless topics where people were surprised that their use of some Nasal framework/library should make their work a derivative work, as is exemplified by bugman's postings here (which is also communicated in various other threads).

So I am not challenging the choice of the GPL, I am just saying that it's obviously not what most fgdata/fgaddon contributors (or content developers in general) expect it to be - i.e. there still is the widespread assumption that using some fgdata/fgaddon based Nasal code may not necessarily make a piece of code GPL, too - which was the whole point of my comment.

And yes, there is postings to be found in the archives (forum and devel list) where senior contributors acknowledged that, too - including postings made by Curt himself, who was basically the project coordinator at the time and still ran into this issue repeatedly - i.e. using Nasal modules from fgdata and not complying with the GPL (if you're looking for something "authoritative" that is - I can obviously post quotes/links).

Finally, this is not my position, it's just a simple observation - I could not care less about the license of fgdata or Nasal modules residing there, but I do agree that the GPL has served the project rather well, even though there is an actual issue surrounding scripting languages and their use of GPLed code (as per bugman's comments in this topic)

PS: We can also turn this around and pose an open question: You have done remarkable work as part of your FG1000 effort - assuming that your Nasal code is licensed under the GPL, where/how and why do you draw the line when it comes to using your work or building derivative work ? Let's play devil's advocate: Someone is offering a modified version of the FG1000 as proprietary payware, would that be acceptable to you ? If so, why (under which circumstances), and if not, why not ? (Let's assume I'm simply loading your code at runtime and then take it from there, and I am going to follow up with all requests to the source code by sharing an obfuscated version)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

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

Postby Thorsten » Thu May 21, 2020 6:23 pm

but the point still is valid, as is exemplified by numerous discussions like this one, where contributors were surprised to learn that their work should be subject to the terms of the GPL due to their use of /some/ Nasal modules originating from fgdata or some GPL'ed aircraft.


I'd argue that's the whole point of copyleft - that you can't opt to 'do your own thing' but have to return in kind. Whether someone is surprised by this or not depends on his willingness to find out about licensing beforehand (aka, 'surprise' isn't a relevant category here) - but the rule is very clear - you can't just take and then do your own thing.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

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

Postby stuart » Thu May 21, 2020 7:56 pm

Yes, the fact that FlightGear is GPL means that we have to ensure that contributions are GPL-compliant and means some things cannot be contributed or have to be pulled if they are found to be non-compliant. That's part of managing our compliance, and and not the same as being "controversial" as you stated above.

Re: the FG1000 - It is absolutely released under the GPL (it's in fgdata) and I have no intention of releasing it under any other license. I'm absolutely fine with someone using it commercially and/or including it in payware if they are GPL compliant. Just as with all my contributions to FlightGear. And I've never had reason to doubt that in the 10+ years I've been contributing to the simulator. If you are alluding to FPS, you may recall that I drafted the community statement on the subject.

If contributors are surprised by the implications of choosing a non-GPL license for their work, that's on them. Personally I'd much rather that they release under the GPL which makes life much simpler and means that their contributions can add to the overall FlightGear ecosystem.

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

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

Postby bugman » Thu May 21, 2020 9:39 pm

It seems like getting into the technical details of what a "whole" in FlightGear is might be made difficult by vested interest and emotion ;) Well, if my position has not been clear from my historical posts, let me say that I also think that contributing back to the project by releasing work under the GPLv2+ licence is the right thing to do. If you are given a gift, it is nice to give a gift back. The knee-jerk reaction of a number of content developers switching away from the GPLv2+ licence due to the Flight Pro Sim and FGMEMBERS controversies I think has been detrimental to the FlightGear ecosystem.


Hooray wrote in Thu May 21, 2020 2:02 pm:Speaking in general, there is no "parallel execution" when it comes to Nasal and specifically Nasal in FlightGear, except for the use of the threading library (which is rarely done by any code/aircraft, except maybe for the shuttle's trajectory calculation helpers). Otherwise, all instances of a Nasal interpreter share a single global data structure, Nasal code is parsed and compiled and turned into byte code, and interpreted by a virtual machine (VM).


Well, I meant serial execution. As for the global data structure argument, that would only be the case if data structures are shared between component X and Y via the global name space. A simple counter argument is - I just started a Python interpreter and imported both a GPL module (minfx) and a non-GPL-compatible module (ha-ffmpeg). These modules have nothing to do with each other. Am I now a copyright violator? Are the authors of minfx (in this case me), or ha-ffmpeg violating copyright? Remember a licence violator looses the licence and then is subject to copyright law. Also remember that the GPL applies to distributors of software - what I do privately with copyrighted material is not bound by copyright law.

As such, there is no notion of separation or even an "execution boundary": once you have a piece of Nasal code, it is always parsed and compiled - as such, there is no difference between a piece of code executed via the Nasal console or a library of code written by a number of contributors written over the course of many months/years: under the hood, the bytecode will end up in the same address space, and since there is no TLS being used, even all threads will share the same address space provided by the fgfs process.


Are you sure about that? Also, which TLS are you referring to?

Let's suppose the Canvas APIs are indeed a controversial examples, so let's say this is about the shuttle and its library of code (modules): Someone wanting to use some portion of said code, could either use copy/paste coding to get that functionality, or they could import the shuttle's version, or add a copy of the relevant code to the new aircraft in question and load it via the -set.xml file or some other "dynamic" mechanism: what is happening behind the scenes is that the shuttle's Nasal module(s) in question will indeed be parsed and compiled and then the internal situation is no longer different from copy/paste, because Nasal's internal data structures will indeed keep a copy of the shuttle's code in memory, and it will not look, or behave, any different from other ways of leveraging that code.


This argument relies 100% on the assumption that component X and Y share Nasal memory. Is that really a safe assumption?

Just because there is no binary created (executable or DSO/DLL) doesn't automatically invalidate the GPL here - the "whole" is a set of functionality that would not be available without including/importing the corresponding code routines, otherwise there would be no point in requiring those - but the very instant such modules are indeed required, this becomes a derivative work, because the new work seizes to function properly without the corresponding import/include/require statement.

As has been said previously, the key question remains one of distribution obviously.

But like you also mentioned, spreading out the execution of key functionality over different processes/machines is a sure way to circumvent the GPL, which is why the Affero GPL would have been a much better choice for functionality that may sooner or later end up being invoked via IPC/RPC means.


Who is the violator here? The person distributing the non-GPL-compatible craft is not, as they are not distributing the GPL component with it. The FlightGear developers most definitely are not. And the user downloading both is not, as they are not distributing anything (what they do in private is not bound by copyright law). The only possibility is an OS vendor or distributor who bundles both together.

Here is a counter example. Some disgruntled ex-FlightGear user or developer decides to partly implement a FlightGear alternative that uses a completely different and non-GPL-compatible licence X. They could pull together a game engine, build basic JSBSim compatible FDM, and pull in a few other components. This alternative flight sim could have rudimentary support for loading FlightGear craft, gracefully handling missing functionality. Now with FG being GPL and the alternative sim using licence X, would a craft distributed by itself result in a copyright violation if its licence is also X?

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

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

Postby Hooray » Thu May 21, 2020 10:25 pm

Stuart,

FlightGear scripting wasn't around when the GPL was chosen for fgdata, and even before Nasal, only an experimental JavaScript and PSL (PUI) integration were added (by Erik IIRC), i.e. all pre 2000s - Nasal (NASL at the time) got integrated ~ 2003 by Andy

When the implications of the GPL for Nasal use in FG became obvious to some contributors who thought otherwise, the choice of the GPL did indeed become a controversial issue - which included statements from senior folks at the time (to be fair, I believe that only Curt is still around today - but it's still all to be found in the archives).

I was never alluding to "FPS" or any other scams - I was posing a genuine question when I asked where you'd draw the line when it comes to building work (writing code) that leverages your code routines - and I specifically asked for how/where and why, i.e. not hoping for a generic statement in the form of "GPL compliant", but what your stance is when it comes to using your code in a library/API fashion to create a new device from scratch - i.e. by using the equivalent of an import() statement (or io.load_nasal) to load your code and build a new MFD device/variant. I asked that question for a reason, because this is something that other senior contributors, including core committers, have run into previously - i.e. the very definition that bugman has been asking for :D

stuart wrote:If contributors are surprised by the implications of choosing a non-GPL license for their work, that's on them. Personally I'd much rather that they release under the GPL which makes life much simpler and means that their contributions can add to the overall FlightGear ecosystem.


I fully agree with the latter - however, the former statement misses the fact that the real issue here is a different one: starting a project (Nasal module) from scratch by reusing libraries provided via fgdata/fgaddon respectively, that were contributed/licensed by other contributors under the GPL, and how that affects the new work -as per bugman's comments, this is indeed a valid question, and also a recurring one. My position and understanding is rather clear, so I am not asking for clarification other than playing devil's advocate here - rather, bugman is asking :lol: And that is why I posed a genuine question in the context of one of your recent Nasal based contributions.

And yes, there's a ton of evidence in the archives of the forum and the mailing list, supporting the notion that even some of our most senior contributors, including core devs, have rather differing opinions (read: controversial) on the merits of the GPL in the context of Nasal code, and if/how we're doing the project a service by enforcing the GPL in that context:

Autonomous F-14b demo
curt wrote:[...] Making a linkage based argument is interesting, but it appears that most people do draw a separation between the code that implements the script engine, and the actual scripts themselves. I have never thought otherwise, although perhaps this particular specific discussion has never come up before.

So just to summarize, I have always viewed the relationship between flightgear and the nasal interpreter versus nasal scripts in the same way that Larry Wall has viewed the relationship between the perl interpreter and people's perl scripts. The interpreter doesn't force it's license on the scripts and the script authors have the freedom to choose the license terms that work best for their situation. And again, for derivative works (i.e. modifying an existing gpl nasal script, the gpl license must be honored and maintained and not obfuscated.) But for original works, I continue to believe the author has discretion over how to license his/her own work.

Best regards,

Curt.


GPL licensing question.
Curt wrote:Here's a question for all you amateur lawyers and GPL experts out there.

Let's say that someone wants to create a proprietary aircraft within the
FlightGear system, and then distribute a larger "system" that includes
FlightGear + that aircraft.


In my view, the FlightGear GPL license covers our source code, but not
content created with or used by that code (except for things like the
base package which is explicitely licensed as GPL.) Is it possible that
someone could lay claim to any newly created proprietary "content" (3d
models, artwork, panels, etc.) by way of the GPL? Even if FlightGear is
happy to allow people to create proprietary aircraft, could someone
upstream in plib or zlib or openal land somehow file a complaint?

To me this is analogous to Microsoft demanding all documents created and
owned by a company just because they created and edited them with
Microsoft Word. I just don't see that ever happening.

But I wonder what others think about this issue from a legal point of view.



(this topic dates back to 2006, and specifically discusses Nasal and the GPL, and a number of senior contributors (at the time) make statements that some of you may find controversial :D )

Alternatively, see:

(So, Nasal vs. the GPL did get quite some coverage over the years)

PS: @bugman: I contributed to both, the Nasal GC [1] docs, as well as the Nasal internals [2] docs - therefore, yes I do know for a fact that there is no "separate address space" used when compiling a piece of Nasal code vs. loading one on demand/at run time - no matter, if the user considers said code an essential part of the simulator or an optional module/library/plugin or some 3rd party library (TLS=thread local storage).

[1] http://wiki.flightgear.org/How_the_Nasal_GC_works
[2] https://sourceforge.net/p/flightgear/fg ... format=raw
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

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

Postby stuart » Fri May 22, 2020 8:21 am

Hi Hooray,

I think we may have different bars as to what is considered controversial, and your original statement was broader than you perhaps meant?

To my reading none of the conversations you link imply any controversy over fgdata and its contents being GPL which is your assertion that I disagree with:

Hooray wrote in Thu May 21, 2020 1:30 pm:In other words, the use of the GPL for fgdata contents was/is a rather controversial choice, and one that may need to be reconsidered/refined some day, as can be seen by other projects affected by the effects of the GPL on their scripted APIs/libraries, often causing unintended consequences.


That Curt pulled some non-compliant content doesn't make it controversial, and neither does a discussion onto what extent using GPL Nasal .nas libraries in your aircraft impacts their licence, nor discussion of to what extent a FG proprietary aicraft could be distributed I don't consider differing opinions to be controversial either, in and of themselves. That's just opinions and the FG community is a broad one.

To me, what would make fgdata being GPL a "controversial choice" would be if there were a body of core contributors proposing it to be under a different license. I see no evidence of that, nor do I remember any such discussion, though I haven't searched the archives and it might be before my time?

I consider that important because your statement uses that "controversial choice" to back up the idea that fgdata's license is up for discussion. Fundamentally, I don't think it is.

(If it's OK with you, I'd like to leave that part of the discussion there. I've spent far too long wordsmithing the text above to be as clear as I can, and I think we're going down a non-productive rabbit hole and talking at cross-purposes)

Apologies for not reading you other question regarding an MFD based on the FG1000 and distributed under a non-GPL license thoroughly enough. Answering it more fully:

If they're just including it via io.load_nasal(), then I assume it depends on how you resolve this https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works, as I would consider the FG1000 Nasal code as a library. As that article notes, that's a question for copyright lawyers and there are competing points of view.

That's being very "weasely" on my part, but to be honest I think the onus is on the person who is creating the possibly-derivative MFD to understand the license and be compliant, not for me to judge. However, I would caution them that doing so would not be considered GPL-compliant by the FSF and very strongly recommend that they do not do so to minimize their risk of problems in the future. I (probably) wouldn't go after them with a big stick :).

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

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

Postby Hooray » Fri May 22, 2020 10:16 am

Thanks for clarifying. I agree, I wasn't meaning to suggest that fgdata's license is up for discussion anytime soon - I was just implying that a number of senior contributors ran into the issue of using fgdata resources (XML + Nasal) and that they were surprised that there was the notion that "including" an XML file, or loading a set of Nasal APIs should trigger the GPL. And yes, a number of people did suggest to explicitly exclude XML or Nasal (at the time), because they considered such "scripts" to be merely "boilerplate" (see for example Lee Elliot's comments)

And this indeed a recurring debate, you only need to look at bugman's position vs. the one that you and Thorsten communicate.
However, bugman's stance is indeed supported by contributions and events that took place in the past. So there's that, too.

That is exactly why I said that the GPL may not be the perfect the license to cover this particular suggestion. Which makes sense once you look at bugman's questions.
Like you said, you solved the problem by delegating it some 3rd party - whereas bugman is actually trying to get to the meat of it :D

Like I also said, the way FlightGear has evolved over the years, the GPL may not be what people want, and in fact it may not even be what long timers, like you, ultimately want - because it provides too many loopholes, i.e. isn't sufficiently restrictive to cover certain scenarios - given your own exposure to HLA/RTI, I suppose you can see how the GPL could be circumvented in its entirety by going down that path (rabbit hole) ?

Likewise, bugman and Curt have a point, too when it comes to loading GPL'ed Nasal modules, and asking if/how and why the GPL's linkage argument should hold.

And these two different positions are for real: 1) people expecting fgdata/fgaddon Nasal contributions to be GPL'ed, and all work using such contributions to be "derivative" by nature; versus 2) people expecting that they can use arbitrary GPL'ed Nasal modules without that having any impact on their own work. This is how and why I ended up using the term "controversial", because this has indeed been brought up repeatedly by long-time contributors - and even today, we have people on both sides of the spectrum.

And yes, there have been suggestions to exempt Nasal libraries from the GPL - and had that been the case, Curt would not have had to pull some of his work.

Again, I am merely playing devil's advocate here by pointing out that there is a long-standing issue that has never been adequately addressed, and that will sooner or late become a real challenge to deal with. Personally, I am not the slightest bit affected by it, and I do agree that it's a rather dangerous rabbit hole to go down. But bugman has been making valid points, too :D

So, no offense intended or taken - but the topic is indeed a recurring one, and one that has repeatedly involved senior contributors, who were on both sides of the spectrum.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 17 guests