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 Hooray » Fri May 22, 2020 8:23 pm

Actually, you're being ambiguous here:

It is completely irrelevant whether you call a portion of Nasal code a "library" or a "module" (no matter if it's inside a dedicated file or part of some non-trivial binding), created by say Stuart or Thorsten) - under the hood it's a piece of code authored by someone that is made available via inclusion (which implicitly means resolving symbols as needed, i.e. linking).

Thus, assuming such a module is leveraged (imported and called/invoked or customized), the GPL would apply.

In fact, thanks to Nasal's nature you can treat arbitrary code as a library.

As such, even your notion of an air/spacecraft, or the "whole", is completely irrelevant too - the mere act of using such a GPL'ed module by invoking/leveraging it from another Nasal script is a form of linking. There is no longer the GPL's notion of "arms-length".

Therefore, Thorsten's argument holds true even without applying any of your conditions or heuristics - for instance, in an addon scenario, where you may not even have the luxury of defining an aircraft and having well-defined boundaries.

For instance, for many years FlightGear's adcanced weather system has been prominently highlighted and praised by many reviewers, incidentally that is indeed written largely in Nasal, and incidentally by Thorsten, too.
Equally, Stuart managed to pull off a rather impressive feat by implementing the FG1000 moving map device solely in Nasal space.

These are long-term contributors who have literally put hundreds of hours into authoring the corresponding Nasal code.
These are Nasal modules that reside in fgdata, that are considered to be GPL'ed.

Let's say, your line of reasoning is applied: in which case the corresponding Nasal modules might be considered a set of "services", so that people/projects (or companies) leveraging these "services" by importing/customizing these routines as needed would not be subject to the GPL, according to your view ?

And since you emphasize how the FSF FAQ covers static vs. dynamic libs, this is even more evidence that the scripting scenario isn't adequately covered by the GPL at all, where a code module ("portion of code") may not be linked to be serialized to disk at all. Instead, the process is done just-in-time, without anything making it to the disk.

Again, we have other remarkable contributions largely implemented in scripting space - but the underlying issue remains the same, even when dealing with effects or GLSL shaders (which, incidentally, might be another grey area of interest to key contributors like Thorsten, who probably has the largest stake in GLSL contributions currently)

Thus, the discussion is indeed legit and should be thought provoking, even if some of our long-timers have a tendency to react with a knee jerk reaction to weasel out of such debates - the number of key contributors who obviously hold differing positions, should be a strong indicator that the issue needs to be addressed sooner or later. And yes, that also applies to the AGPL / GPL loophole mentioned previously in the context of any further HLA/RTI or DIS work.

PS: In the meantime, I would definitely suggest that contributors add a corresponding license header to their scripts/shaders to be always on the safe side :wink:
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: 11791
Joined: Tue Mar 25, 2008 8:40 am

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

Postby bugman » Fri May 22, 2020 8:47 pm

It is not ambiguous. It's very simple. Did the author of a non-GPL-compatible craft or addon create an unauthorised derivative work? It's all about copyright law.

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

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

Postby Hooray » Fri May 22, 2020 9:03 pm

I think Thorsten mentioned this previously when he explicitly used the term "importing and calling ... ", and that's in line with the previously shared StackExchange link where a FSF response is used to discuss heuristics for fair use vs. derivative work - and yes, the example did use JavaScript, as mentioned previously (I am not getting the impression you're actually clicking any of the links I posted, are you ??).

They explicitly differentiate between just calling a provided API and the degree of calling functions across code bodies/boundaries - which is touching on the whole notion of "just" invoking a callback to trigger the equivalent of a service, vs. actually using the design and architecture of the code to do something new/unprecedented or something that would normally be done as part of the original body of code.

Thus, I think it is fair to say that it's indeed out of question that we're talking about the mere use as a service here; i.d. the very instant you are doing something with a GPL'ed body of code where you consciously leverage its architecture and design to extend/customize and use the system beyond what its original developer/s intended or provided, it's pretty obvious that you are no longer dealing with said body of code as "just a service"; indeed you're building a derivative work.

And the very instant you prefer to stay in muddy waters and leave the issue open to interpretation, "copyright law" is not the solution, but rather the problem (as you undoubtedly know) :lol:

And yes, just like Nasal, GLSL shaders are JIT-compiled too, and the distinction between static vs. dynamic linking isn't helping you a bit either. And no matter if the GPL uses the term library or not, it is indeed possible to create a library of GLSL shaders, that may nevertheless be subject to the GPL - in fact, inclusion in GLSL works analogous to the C preprocessor. So there's that, too. So, please don't make this specific to Nasal :lol:
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: 11791
Joined: Tue Mar 25, 2008 8:40 am

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

Postby Thorsten » Sat May 23, 2020 6:31 am

The GPL will only protect you to the extent that copyright law will (and no further). So what matters is if parts of FGData can be legally claimed as being part of the "whole" craft.


I think it is not controversial that as soon as I write some chunk of code (say to compute orbital targeting) or Stuart writes some chunk of code (say an FG1000), we are copyright holders of that code.

That copyright gives us the right to license our code for others - usually as we see fit, to the extent that we have used other libraries and assets we may be bound by their license - but at that point, the power of copyright legislation is over and the legalities of the license matters.

Copyright certainly has exemptions ('fair use' for instance), these may be different from country to country, but I've certainly not come across any copyright law that allows you to declare things as 'the environment' which you than can use as you see fit (for instance, there's a reason people in movies are so often seen reading the same fake newspaper - real newspapers are copyrighted and can not simply be shown by declaring then an 'environment' in which the movie happens to happen).

So there's no connection between your two assertions - it is true that GPL protects me to the extent of copyright, but it is not true that copyright legislation allows anyone to define a magical 'environment' in which licenses do not matter.


***

Thus, I think we have reasonably established that - as in the case of Java - including or calling GPL licensed code in a scripting language like Nasal triggers the GPL.

That leaves open the question of simply using the Nasal interpreter. Here I don't know for sure - it is possible that simply using the interpreter also triggers the license, if so, I at least would see that as unintended, as I see the Nasal interpreter as something that indeed provides an environment (I'm not arguing that there is no such thing as an environment, I'm just arguing that things can't be arbitrarily declared to be 'environment' - especially not things that can easily be moved from aircraft to FGData and back) - so I'm certainly open to an FG-side statement that using the Nasal interpreter to run non-GPL licensed aircraft-side Nasal is okay.
Thorsten
 
Posts: 11620
Joined: Mon Nov 02, 2009 8:33 am

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

Postby Hooray » Sat May 23, 2020 7:05 am

No, using the interpreter does not trigger its license (which by the way is not GPL but LGPL).

And bugman has a point too, i.e. you could conceivably make a "call" into a GPL'ed body of code, from a differently-licensed body of code without triggering the GPL, the question is whether a) said call (code invocation) happens at "arms-length" (loose coupling, aggregation/fair use) or b) if there's an actual integration/tight coupling taking place.

The former would be the equivalent of calling AW routines to affect changes to the settings/configurations of the weather system, e.g. APIs that were designed to interact with the system in an interfacing fashion between a front-end and a back-end.

Whereas the latter would be the equivalent of adding new weather tiles, a new/improved tiling schemes, multiplayer integration or a server-based system.
Neither of which were intended/designed by you, and neither of which can be done merely by invoking the external interface of the Nasal code in question that you developed to interact with the system. In other words, you don't care if a new GUI dialog (say in Phi or Qt) is GPL'ed, as longs as it's using said interface, right ? :wink:

The same analogy could be transferred to the FG1000: triggering bindings (hot spots) can be said to be trivial (and indeed providing/fulfilling a "service"), these are indeed wrapped in the form of Emesary/fgcommands and they're the intended means to interact with the module in question, whereas creating new MFD pages or functionality, or building a completely new device using the existing body of code, goes far beyond that.

Using the Nasal interpreter, and indeed fgfs as whole, to run a non-GPL aircraft has always been acceptable, this was never the question.

The only question is if/how and why the inclusion of, and linking to (invocation/leverage of), GPL'ed resources (complex FDMs, systems, property rules or Nasal code) to do so should be exempted or not, because of the implications of running in an interpreted/scripted environment where parsing, lexing, compilation and linking are not separate steps that actually create a binary (just in time compilation)

And again, the issue can also be mapped to effects or GLSL shaders, or OpenCL kernels.
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: 11791
Joined: Tue Mar 25, 2008 8:40 am

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

Postby erik » Sat May 23, 2020 8:17 am

Thorsten wrote in Sat May 23, 2020 6:31 am:That leaves open the question of simply using the Nasal interpreter. Here I don't know for sure - it is possible that simply using the interpreter also triggers the license, if so, I at least would see that as unintended, as I see the Nasal interpreter as something that indeed provides an environment (I'm not arguing that there is no such thing as an environment, I'm just arguing that things can't be arbitrarily declared to be 'environment' - especially not things that can easily be moved from aircraft to FGData and back) - so I'm certainly open to an FG-side statement that using the Nasal interpreter to run non-GPL licensed aircraft-side Nasal is okay.

I'm not completely sure either but to me it sounds unlikely this will trigger the GPL otherwise all images creates with The Gimp would also be GPL. The tool (Nasal interpreter in this case) is clearly designed to allow one to write scripts and thise scripts are not part of the interpreter itself and hence would not touch it's license.

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

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

Postby Hooray » Sat May 23, 2020 8:29 am

The situation is absolutely clear, just using Nasal to run scripts (which, again, is not GPL but LGPL) does not trigger its license at all, as per Curt's original Perl analogy:

Autonomous F-14b demo
curt wrote:[...]
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.


It is indeed very important to have this discussion, and actually it's long overdue, since so many senior contributors have very a differing understanding of licensing certain parts of FlightGear under the GPL, and the resulting ramifications of doing so. Hopefully, this can be resolved once and for all.

Unfortunately, in its original form (i.e. without an explicit exemption), the GPL isn't necessarily a perfect fit to provide the degree of security and freedom that many contributors have in mind when it comes to dealing with an interpreted language and a scripting environment. No matter if this is about Nasal, Perl, Python or JavaScript. The situation remains the same.
Last edited by Hooray on Sat May 23, 2020 8:32 am, edited 1 time in total.
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: 11791
Joined: Tue Mar 25, 2008 8:40 am

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

Postby erik » Sat May 23, 2020 8:30 am

I agree with Curt.

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

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

Postby erik » Sat May 23, 2020 8:33 am

Hooray wrote in Sat May 23, 2020 8:29 am:It is indeed very important to have this discussion, and actually it's long overdue, since so many senior contributors have very a differing understanding of licensing certain parts of FlightGear under the GPL, and the resulting ramifications of doing so. Hopefully, this can be resolved once and for all.

I'm not exactly sure how others feel about it but I don't think keeping the Nasal code in FGData pure GPL gains us anything. In fact it probably drives developers away. Developers who dislike the GPL almost never switch positions so I think it would be good to have them stay around with the little exception to the license that allows them to use the Nasal code in FGData.

If there is a particular piece of Nasal code which someone feel strong about keeping it GPL without the exception then maybe it should be moved from FGData to the aircraft that use it (which then need to be GPL).

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

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

Postby Hooray » Sat May 23, 2020 8:36 am

erik wrote:If there is a particular piece of Nasal code which someone feel strong about keeping it GPL then maybe it should be moved from FGData to the aircraft that use it (which then need to be GPL).


There is some Nasal work that could not easily be moved to an aircraft scope, e.g. stuff like the Advanced Weather system or the Bombable addon - these would then have to become separate entities in the form of explicit add-ons, that are covered separately that way.
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: 11791
Joined: Tue Mar 25, 2008 8:40 am

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

Postby erik » Sat May 23, 2020 8:39 am

If the aircraft does not call any Nasal function of the Advanced Weather system directly then the GPL would not get triggered. And I think Bombable already is an add-on?

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

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

Postby bugman » Sat May 23, 2020 8:47 am

@Thorsten:. You can shift code so that it is or isn't influenced by the copyright licence of another piece of code. There is no "magical transformation" required.

Say for your orbital targeting code. If I auto-translate it to C and compile it into my C program, I am bound by the GPL. But if you take your code, auto-translate it into C, and compile a standalone binary that one communicates to using some system (say STDIN and STDOUT), then if I use your code via that binary I am not bound by the GPL.

It is all about the definition of the "whole" in GPL terms, or if I have created an unauthorized derivative work in copyright terms.

Regards,
Edward

Edit: Note that a third party can take your code and create a standalone binary too. If they use this binary produce solutions that are used in another unrelated binary X (via say STDIN and STDOUT), only the changes they made to your code must be released. The code from X is not bound by the GPL. This is not "circumventing" the GPL.
bugman
Moderator
 
Posts: 1777
Joined: Thu Mar 19, 2015 9:01 am
Version: next

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

Postby Thorsten » Sat May 23, 2020 9:42 am

I agree with Curt.


Yes, me too.

I'm not exactly sure how others feel about it but I don't think keeping the Nasal code in FGData pure GPL gains us anything. In fact it probably drives developers away. Developers who dislike the GPL almost never switch positions so I think it would be good to have them stay around with the little exception to the license that allows them to use the Nasal code in FGData.


I don't think that 'we' can decide that - in effect, that'd be a change in the license terms to dual license (you can use it under normal GPL if you want to develop it further, or you can use it - without changing it in any way - from an aircraft) - and that change would have to be signed off by the copyright holders of the code, aka the people who wrote it.

So the situation could get quite muddy quickly.
Thorsten
 
Posts: 11620
Joined: Mon Nov 02, 2009 8:33 am

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

Postby Hooray » Sat May 23, 2020 9:47 am

That is why FSF projects usually require a signed copyright notice by contributors, i.e. when contributing to gcc: https://www.gnu.org/prep/maintain/html_ ... apers.html

If you maintain an FSF-copyrighted package, certain legal procedures are required when incorporating legally significant changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the standing to defend its GPL-covered status in court if necessary.

GNU packages need not be FSF-copyrighted; this is up to the author(s), generally at the time the package is dubbed GNU. When copyright is assigned to the FSF, the FSF can act to stop GPL violations about the package. Otherwise, legal actions are up to the author(s). The rest of this section is about the case when a package is FSF-copyrighted.
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: 11791
Joined: Tue Mar 25, 2008 8:40 am

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

Postby bugman » Sat May 23, 2020 10:07 am

@Hooray: How the FSF requires all contributors to official GNU projects to transfer their copyright to the FSF is not relevant to the FlightGear project. Most developers consider this to be overbearing, and hardly any other free software projects follow this model.

Practically the licensing of FGData cannot be changed (except to maybe GPLv3 or higher in the future).

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

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: gigavoltflash, Majestic-12 [Bot], wrg and 3 guests