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
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
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 democurt 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
)
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