GPL Script Inclusion

What are the ramifications of including an LSL script released under the GPL in an object? In other words, does the inclusion of a GPL script place any restrictions on the permissions settings of other components of the object?

The script in question exposes an api to modify the prim on which it resides in response to linked messages

Is it enough to leave full mod, copy, transfer perms on the GPL script, or does its inclusion mean that the other scripts in the multi-prim object (and the object itself?) need to be GPL'd (mod, copy, transfer) as well?

If I build a car and use GPL code in the car stereo, I'm required to provide source for the GPL code in the car stereo. I'm not required to provide anyone with free stereos, or free cars.

There's no reason to believe using a GPL script in an object requires you to provide free copies of anything but the GPL script. But you will have to provide copies of the script, including any modifications or additions you've made to it, upon request.

Put the GPL'd script(s) source into a notecard within the object. Then, add a function which gives the source notecard upon request.

If the other scripts in the linked object communicate with the GPL script at all, then all of those scripts must also be released under the GPL. The GPL is explicit and clear on this.

http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingWithGPL

The scripts themselves can have any access controls you want, but if they are not user readable then you must make the source code available somewhere (in-world) either in script or notecard form, and include instructions with your object on how to find it.

False, and silly to boot. Does Internet Explorer need to be released under the GPL because it communicates with a GPL webserver? Simply communicating with a GPL script does not make the other party of the communications subject to the GPL. That's just absurd.


Uh, you've pointed us to the linking clause of the GPL, which has nothing to do with this discussion. To the best of my knowledge, there's in fact no way to link object code modules in LSL. Even if there was, that's not what we're talking about here.

Typed link messages and llSay-based API among scripts stuffed into a prim or linkset is pretty much LSL's implementation of dynamic library linking. That's exactly what's being discussed here.

No. If the closest you can get to buying a tank is buying an SUV, that doesn't make the SUV a tank. LSL doesn't have dynamic library linking, period. If chat commands are the closest thing it has, that still doesn't make them dynamic linking. "Linking" is a technical computer science term with a specific meaning in this context, and inter-script communications don't qualify, regardless of whether that's the closest thing LSL has or not.

The reason why dynamic library linking is covered by the GPL is exactly the same reason that static library linking is covered by the GPL: whether you do it on disk beforehand or in memory on the fly, you're assembling a single program with a single address space out of the various parts. It's not two programs, it's one.

An llSay-based API and even link messages are nothing like that. llSay-based API is rather like TCP/IP between programs possibly running on entirely different machines, and link messages are rather like Unix sockets running on the same machine. In all of these cases, the various programs remain completely separated from each other -- separately running programs with their own process IDs, address spaces, etc.

If two bits of code are truly linked, whether statically or dynamically, you can't shut one down while leaving the other one running, because they're the same program. The individual code files may be in different places, but it's one program running, and if any part of that program is GPL code, the entire program is subject to the terms of the GPL.

But that is a situation entirely unrelated to separate LSL scripts, each of which is its own self-contained program, capable of being started or stopped independently. It may not function correctly if whatever it talks to doesn't respond, but the fact that it can send messages while the other script isn't even there shows it is its own program, and not "dynamically linked" in any way to the other.

[Techspeak: llMessageLinked and llSay are both methods of IPC -- Inter-Process Communication. Linking, whether dynamic or static, is intra-process, and it's not a method of communications, rather it's a method of assembling a single executable process out of seperate code modules. In short, they're completely orthogonal things, despite the fact that under certain circumstances either technique might provide a path to satisfying the same goal.]

Stand-alone scripted objects- single primitives or a linked set of primitives- are distributed and manipulated as a single item. The object has behavior, can be bought and sold, and in whole is an original work. Following the straight text of the GPL, it doesn't really matter how or if the scripts communicate to effect the behavior of the object- any inclusion of a GPL script is sufficient to classify the entirety as a derivative work.

I think an argument can be made that a GPL script included in an object may not be derivative and within the spirit of the GPL if it is not integrated in any way, interacting only with the end user, not code. The argument would be stronger if scripts were truly independent processes, but they're not. They are threads owned by the object, starting when it rezzes, reaped when it de-rezzes.

No, the object is more along the lines of a virtual machine-- and it hosts multiple "processes", or scripts.

For better or worse, the GPL is based on earlier C-era terminology, specifically linking, that hasn't really kept up with scripting technology. I know of some GPL projects that take an extreme view, others more lenient. These, of course, are technical opinions that may or may not stand up in court. Conversely, I've seen responses from FSF lawyers based on questions that used the term "linking" loosely; the lawyer naturally said that of course, it's covered, without questioning whether that use of the term was valid.

So all anyone can do is offer their own opinion, until the next version of the GPL comes out. If you really want to know what's expected, your best bet would be to ask the copyright holders on the script you're using - they may take a hard line, but at least you know that if they don't, you're on pretty solid ground.

The GPL (not LGPL) doesn't actually address the issue of linking, communication or source combination at all. The only rubric is whether GPL'd code is included within a derivative work, a new whole subject to and protected by copyright law.

The question is really- is a Second Life object a work under copyright law? If so, then all component parts will be considered derivative, and one GPL script will infect the rest. The law, especially copyright law, is murky and consulting a lawyer is always a good idea to get a defensible if not definitive answer. But I'm not aware of any argument or reasoning that would suggest that a Second Life object does not fit the bill of a creative work fixed in a tangible medium.

Actually, just a day or two ago, somebody released a crypto implementation in LSL, under GPL , and I decided to ask exactly what their stance was on other scripts that might communicate with it.

Their expectation was that the code containing the crypto implementation, including modifications, should be open and available, but that other scripts communicating with it did not need to be.



This seemed reasonable to him, and to me, but I would have respected his wishes (and not used his implementation) if he expected it ALL to be GPL as well.

That's simply not true -- "following the straight text of the GPL" implies no such thing, any more than it implies that an entire Linux distribution is a derivative work if it includes any GPL'ed programs in it. I can understand why someone might want to interpret it that way, but that's not "following the straight text of the GPL", that's extending beyond the straight text quite a bit. The GPL explicitly says none of the things you keep claiming it does. It may or may not imply them, depending on who you ask, but what you're claiming is found nowhere at all in "the straight text".

And it's a pretty shaky argument. By that same argument, if a Linux-based distribution of a bootable CD launches a propriety program, they have to provide source to that program or they're violating the GPL. I'm sorry, but this isn't a murky issue that people argue about. That's just plain wrong. Everyone acknowledges that separate programs remain separate programs even if they communicate with one another and are distributed on the same CD. The GPL'ed kernel, init code and bash shell don't force the propriety program to become free.

I'm more than happy to respect the wishes of someone who doesn't want to have their programs distributed inside objects with other code that isn't free. And if they use a license that requires I do that, I'll happily obey it. But the point here is, that's not what the GPL says or requires. If they've GPL'ed it, then it can be legitimately used in that manner.


You've entirely avoid the actual question at hand. The question is, what constitutes a derivative work. It's well established that simple inclusion and use does non make something a derivative work. Red Hat Linux is not itself a derivative work of Postfix merely because it includes it, even if it starts it up automatically every time it starts and depends on it to function properly. The mere inclusion of some program in a collection of interacting programs does not make the collection a "derivate work" of that one program.

Now, if they take the Postfix code and make a new program by extending it or including any part of it in that new program, then the new program is a derivative work.

The question is not at all, "is a Second Life object a work under copyright law?" It clearly is. But the mere inclusion of one GPL script or one GPL program or indeed thousands of GPL programs, as is the case in many OS distributions, does NOT infect the rest, because mere inclusion and communcation/use does NOT constitute making something a "derivative work".

Script B does not magically become a derivative work of Script A merely because A and B are both included in the same prim. If A is GPL'ed, great, but no one is under any obligation at all to release the code to script B in this case, because it's not a derivative of script A, and doesn't magically become one the moment you drag it into the same object -- it's still the same independently written code it was before. No part of script A is included in script B -- it just ain't a derivative work no matter how you slice it. Just as Internet Explorer doesn't become a derivative of Apache even if you include them both as integral parts of the same information kiosk. It may be one object, but it's still many programs, each of which can be licensed differently and none of which infect the others with their license as long as they merely communicating with one another and are not in fact derived from one another.

I don't know why anyone even thinks this issue is at all murky. This was worked out years ago when people started making Linux, BSD, and other open source distributions. Mere inclusion and use does not constitute a derivative work, never has, never will.

The issue is not "linking" or even what constitutes "derivative work". Simply incorporating a GPL-licensed software into a proprietary system MAY IN FACT make the entire system subject to GPL. See the following link for an explanation:

http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLInProprietarySystem

-peekay

Oops, you're right, it's the LGPL that discusses these issues.


I agree with the first part, but not the second. If I take a collection of short stories and publish them as a book, the entire work is a compilation, which isn't quite the same thing as a derived work. See the GPL FAQ entry on aggregation.


Agreed

No, it's not.

In fact there's explicit changes proposed for GPLv3 to try to address this. Communicating with a GPLed program is not the same as linking with one, in the sense that the FSF uses the term.

Don't get confused by the technical use of "link" in SL. There's no relationship between the two concepts.

More on this in later comments.

This isn't "LSL's implementation of dynamic library linking". LSL does not have an implementation of dynamic library linking. There's no point in trying to argue that this is "like" linking, it's not. It's like "talking to a program". And if "talking to a program" was enough to make a product GPL, then Windows would be GPLed right now due to Microsoft's distribution of gcc with Windows Services for UNIX 3.0 and later. You can't come up with a more classic example of a GPLed program than gcc, so if shipping gcc and an entire subsystem compiled with gcc and depending on it doesn't make Windows GPLed, then sending a link message to a GPLed script certainly won't.

If that's not a good enough example, then consider Apple's XCode, which runs gcc and sends messages to it and gets responses back from it every time it runs.
Scripts are independent processes running under the Second Life server. gcc in XCode is no less 'dependant' on XCode than scripts in a prim are dependant on that prim. You can stop and start the script, and take the script out and run it in another prim, and it runs just the same. Yes, it has different variables in each case, but then so does gcc when it is run a second time.

Scripts are independent processes running under the Second Life server. gcc in XCode is no less 'dependant' on XCode than scripts in a prim are dependant on that prim. You can stop and start the script, and take the script out and run it in another prim, and it runs just the same. Yes, it has different variables in each case, but then so does gcc when it is run a second time.

"To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. [...] The difference between this and "incorporating" the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs--but you have to do it properly. The issue is simply one of form: how you describe what you are doing."

The bottom line is that is the end-user can use the two components independantly in a normal fashion.

If you use GPLed scripts:

1. The prims they are in MUST be modifiable.
2. The scripts themselves, in those prims MUST be full-perm.

Note that this means all the objects using Franimation Overrider or scripts derived from it in non-mod prims are in violation of the GPL. The thing is, it's up to the copyright holder to enforce the GPL. Unless Francis Chung chooses to enforce the GPL, the GPL on Franimation Overrider is pretty much irrelevant. So here's the third way you can use GPLed scripts alongside proprietary ones:

3. The copyright owner MUST NOT actually be interested in enforcing the GPL.



If that bothers you: take it up with Francis Chung and other people who have written widely used GPLed scripts, and convince them to enforce their copyright.

Bringing this together:Somewhere in the middle.

The GPLed script needs to be full perm, or you must provide or make available a full perm copy of that exact version of the script (and making it full perm is by far the easiest way).

The object must be modifiable, so the end user can actually treat the script and the rest of the object as separate entities.

You must also conform to any other requirements that the original copyright owner imposes, if they are using a modified version of the GPL.

Thank you Argent. Your replies have both been enlightening, and sensible. I find myself in agreement with all your analogies.

Having worked in a company that released all its software under GPL and depended on preper interpretation to thrive, let me throw in my hat:

When someone compiled our client or server into their own application directly, they were under the GPL and its restrictions.

When someone called our client through the shell, pipeing commands to STDIN and reading STDOUT, that was not considered to be restricted by the GPL as the software was not encapsulating our client but communicating with it.

When someone communicated with our software across a standard API that was also considered communicating with our software and also acceptable under the GPL.

So, if you copy code from a GPL script and paste it into your script, your script should be GPL when distributed. If you talk to a script across a llSay based API, you are just communicating with it and I would not consider GPLing your software to be needed. After all, what if the GPL script was just sitting there on the ground? What if the GPL script was running a door and you had been given the API so you could implement a key? Would you have to make the key GPL just to open the door?