Franimation Overrider GNU terms

Can someone clarify for me the terms of the GPL regarding the Franimation Overrider?

My understanding was that the script itself had to be given full permissions, but that the containing object didn't (since just including an AO doesn't make it derivative of that AO - same reason that Linux CDs can be copyrighted because the CD layout isn't considered derivative)

Or am I wrong about those?

Yeah, I'm not sure if it's just derivates, or objects that use/contain a GPL script that are affected too. I based my HUD AO on the Franimation script, and I took the lazy way out (instead of doing teh research to try and find out how this worked) and made all of my stuff open source and freely copiable, including the object and the additional scripts I wrote. But I might be working on something else soon that has a component that's a mini AO, and I'd like to use the Franimation script again (why re-invent a wheel that's already been done very well IMO), but I'm not sure how exactly the packaging/licensing should work. I'm pretty sure I can package the AO as a separate object and keep the other object proprietary and I would be within the terms of the GPL. But if I want to include the code into the same object... that puts me in the same situation as your question. So, basically, I'd like to know the answer to this too

I believe many people sell their animation bundles with this AO script, and the animations themselves aren't freely copyable. Of course, that doesn't mean that doing this is within the GPL.

Hi

Basically what I've been doing as this:
- If you make script changes, you should release those changes open-source.
- You are welcome to add animations that are nocopy/notransfer and resell the whole thing.
- You are welcome to make a new model that nocopy/notransfer and resell the whole thing.
- The script should remain mod/copy/transfer.

However, I ask that if you derive revenue from selling the animation overrider that you contact me so that I can add you to the list of people willing to do tech support.

It seems like a fair trade to me


PS. For anyone who uses the Franimation Overrider, you should give Ziggy's HUD AO a spin

So that would include my case, where the AO is just one part of a bigger product. And it's only the AO script that would need to be open source, not every other script. Thanks, that takes care of my dilemma.



Sounds fair to me. If I do make any money off of this project, I'll be in touch



Here's the 5 bucks I promised you for saying ... oops, did I say that out loud?

(nod)

Also, does anyone know what the latest version is? Reverie's have 1.5 but I've heard a 1.7 mentioned..

I based mine off of 1.7. (After having written it off of 1.5, and that merge/port accounted for most of the bugs that I introduced ). I should still have a copy of Francis' original code that she gave me, I'll drop you a copy when I log on tonight.

Other scripts in the same object do not have to be GPLed, according to the "mere aggregation" clause in the GPL.

One question that really needs to be settled is... can the object containing the script be no-mod or not. My understanding from my reading of the GPL is that, if you take the GPL at face value, it can't be. And there's products using the AO that aren't.

Anyway...

One of the terms of the GPL is that the GPLed software has to be released in a way that the recipient can modify the software and use the modified software in the original product. That means, if you use GPLed software in an embedded application (like, say, a router) you may need to provide enough tools to allow the recipient to burn a new PROM for the product, including a linkable version of the embedded OS it uses... if that's what it takes to update the GPL-ed component in the product.

In the case of an LSL script, doesn't this mean that the actual object the script is in has to be mod, since you can't edit or replace the script in a no-mod object even if the script is mod. Or am I misunderstanding the limitations on LSL?

Francis: I realise that you are the only person who can enforce this clause, so if you say "no, you don't have to do that" then it's more or less moot, but then you might want to use a GPL-style but not GPL license that doesn't have that clause in that case.

What if you provided a copy of the script as a separate deliverable? Is an owner of a no-mod object allowed to delete a script in inventory and add a new script?

yes I believe that's how the GNU reads and how it applies to SL. However this makes a very big problem with SL permissions visible .

If your object is using GNU scripts, then the object to conform to the GNU must allow the script to be modified and placed back into the object to be used with the original object. Currently there is one way of doing this:

You make the object modifiable. This essentially makes your object open source. the GNU says your object can be non modifiable, and not part of the GNU, but sl does not allow permissions to be set in that fine grained a manner. If you want to use a GNU script and have your object be non modifiable, you are out of luck.

It's been pointed out to the linden's that this needs to be fixed in order to allow specific and reasonably limited licensing. We have been told it's planned. We have no time frame or any idea what form the permission modifications will take.



No, delete it they can, but if the object is not modifiable, they can not add a script.

And is that just true for scripts, or any inventory? If I have a prtoduct that requires the owner to drop in their own textures or sounds or landmarks or whatever, does that product have to be modifiable? Maybe it only applies to scripts because you can use llGetPrimitiveParams (the mirror script or equivalent) to exactly recreate the object.

I don't know if you can apply GNU to not code things o.O. lol it never occured to me but if you can I think it would be exactly the same, with one small difference.

In lsl there is a function called llAllowInventoryDrop. This will let ANYONE drop things into the contents of an object NO MATTER what permissions they have. This requires that the object be scripted to delete things dropped into it that shouldn't be allowed in it's contents. This does however let you put something from an objects contents that is GPU back into the object after modifying the GPU resource. If the GNU applies to other content the same way it does to script, then this allows the GPU to be adhered to without open sourcing the object itself.

llAllowInventoryDrop does not work with scripts. It does not allow you to drop scripts into the content of an object that you don't have modify permissions for.

So no, your object doesn't have to be modify to allow someone else to drop things into it as long as they don't need to drop scripts into it.

My reading of llAllowInventoryDrop was that it was to allow non-owners to drop stuff in, like "Leave a notecard with your comments" type of objects. I thought the owner was always able to drop inventory into a no-mod object. Is that incorrect? I understand that now I'm only talking about non-script inventory.

as far as I know you can't drop things into an object you don't have permission to modify. I'll check later as I can't site a specific test I've done.

Heh. Thanks. I can check tonight too, once I'm home

AFAIK, you can always drop anything - scripts included - into the inventory of anything you own, no matter about permissions. And, as long as you drop it from the UI, the scripts do run.

Yes, you can snoop link messages. Yes, you can steal texture IDs from scripts that set textures. No, you can't steal textures from objects that are textured directly because as of recent versions llGetTexture() checks the permissions on the prim. Yes, you can steal the model via llGetPrimParams(), but not the texture.

I'm wondering about the possibility of using this semi-legitimately for a system whereby a competitor's version of an object can be upgraded with a script, via:
- Give them an object (which is then owned by them)
- They rez it, when it detects the competitor's object, it giveInventory()s the competitor's object a script
- It then asks the user to use the tools menu to "set scripts to running" on the competitor's object
- The uploaded script is then running on the competitor's object, it deletes the competitor's old scripts from inventory, sets a new script update PIN, and signals the original object they were given to start uploading the new scripts via remote update

I'm not sure if you can change the script update PIN on a no-modify object - on the one hand, it's a no-modify object; on the other hand, scripts inside the object could do so when they've owned by you and SL permissions don't seem to care about creator ID.

Possible, impossible? Ethical, unethical? What do folks think?

o.O, no way. I was sure at the very least dropped scripts wouldn't run. If that really is the case I'm seriously disturbed o.O.

GPL, not GNU. the GNU is reponsible for creating the GPL. It can be called the GNU GPL, or GPL, but not GNU :/

and that's not how it works. as long as you offer to provide the source code, you are complying with the GPL

http://www.gnu.org/copyleft/gpl.html

notice the phrase "one of the following" and part b



you must do one of these you distribute any version of the program, even an unchanged one. The idea is that the creator of the original script gives certain freedoms over it, then no-one after that can change the amount of freedom in subsequent versions. As long as everyone is required to somehow furnish the source code of the version they made, this prevents anyone from ever 'closing' the source

and no, the GPL and LGPL do not apply to something that is not code, because the language doesn't cover them

the important that seems to be often overlooked on SL is that the whole liscense has to be distributed with the program. mentioning or linking to the liscense is not sufficient

I stand corrected twice , but I said GNU because it seems to me that a GPL is a general term where GNU is a specific type of GPL. I dunno, I only read it for the purpose of this thread , and I missed the one of the following part, so guess I didnt' read well enough .

Well, you can set the object mod but not copy or transfer. That particular script would remain modifiable, but other scripts in it could be no-mod, and the object as a whole wouldn't be open-source.

For franimation overrider, usually the object is a complete avatar (mecha, tinies, etc) which comes in multiple parts. So you just have to make the part containing the script modifiable, not the whole avatar.

I would recommend putting the overrider in a heads-up display that's full mod... that means the externally visible parts of the avatar could remain no-mod, AND it gives you a nice controller for animated parts of the av.

Not just the source code, the source code and any components required to USE the source code.

The motivation for this section includes the all-too-frequent situation where a programmer is unable to apply fixes to software they have the source to, because there's no way to install the modified software back in the original product. If you can't modify the object, you're not really complying with this part of the GPL.
But everything in SL is software, including objects.

I'm almost positive this is not the case, since I ran into problems when I released a copy of my button bar where the prims were "no mod". Users could not drop animations into it and neither could I when I tested it with an alt. You can take things out of a no mod object however.

Here is my question to Ziggy then since I'm such a fan of your HUD AO. Can others use your script the same way Fran says they can use his? Can I include your script (with a few alterations) into an object that does something else as well, have the other scripts be no mod and sell it as long as your script is mod/copy/trans?

I believe the answer to all of that is 'Yes'. It's the same license, so whatever applies to the original Franimation script, also applies to mine.

So long as the object it's in is MOD as well, and so long as there's no direct interaction between the AO and the other scripts, there shouldn't be a problem. Unrelated scripts that just happen to be in the same object should be considered "mere aggregation" under the GPL.

I wish there was someone from the FSF here, though, because I've occasionally been surprised by their definition of "mere aggregation". It seems a lot more restricted than appears intuitive to me.

Also, people might want to consider one change in the use of the GPL. The FSF recommends this wording in the copyright notice:
The problem is that there is some indication that the next version (version 3) of the GPL will be significantly more restrictive, for example they are considering restrictions on how services using GPL software can be licensed. It might be worthwhile to use wording more like this:

This is a great thread, and a good sequel to a conversation Argent started with me over using the Franimation kit in avs I provide. Looks like I need to add myself to the list of people providing support for it.