Permissions question (no copy) (no modify) (no transfer)

I've got quite a few things in my inv I've bought that have no permissions, showing as the thread title that I can't copy, modify or transfer them. Fair enough - there are very good reasons to give no perms to the buyer of an object.

But how does one actually do this? In the "Next owner can:" section on the object parameters, if I have neither "Modify" nor Copy" checked, "Resell/Give away" is automatically checked and the field unavailable. So, if I then give the object to another avi, they have transfer perms.

I've never understood this, and it's finally time to fight my ignorance and ask what's going on here and why. Over to the experts ...

One way is if the contents of the object have contradictory permissions from the prims of the object. For example, if the prims are copy/mod but there's a transfer-only script inside, you'll effectively have no permissions on the object as a whole, and that's how it would appear in Inventory. (You could, of course, pull the script out of the object and then copy the prims, but you'd still only have the one transferable script to put back into one of the copies.)

There may be (or have been?) other ways to end up with no permissions, but that's the one I know.

Hmmm ... no, if I just create an object, a single pine cube prim with nothing in it, the same happens. I just can't set it so the next owner has no perms at all.

yeah you can mix various perm settings in an object to force the result to effectively have no permissions (the most restrictive permission in an object always win)

Qie has described it. The least permissive permissions on the cube are added to the least permissive permissions on the contents, so in inventory the object looks like no/no/no but once rezzed will prove to be otherwise.

I've not been able to find any way of doing that, but even so, what if the real reason you don't want them to have perms is to protect the contents themselves?

The particular case I'm thinking of is a gadget that only works for its owner, and essentially is just a script stuck in a prim. I don't want them to be able to modify, copy or transfer the script, since then they could either:

1. Copy it, put it in a prim and have two gadgets for the price of one, which I definitely don't want

2. Transfer it as a loan to a friend, to save them buying their own copy.

3. Modify it (ie open it) and copy/paste the code in the script. Hell, I don't even want them to *see* the code.

How could this be achieved, so they can't simply pull the script out of the prim into their inv and do stuff with it on its own?

I do all my scripts as copy or transfer only. Modify on a script = full perms. No modify they can't see the script.

nah this you can't do, and why couldn't they have more than one gadget if they can't transfer it anyway?

you can try to "weave" permissions in a multi script item so it will be a real pain to unweave it and it would probably not work but honestly it's bad business practices.

Well I've gotten into the habit of looking for copy/mod for some items... but prefer to see transfer vs copy now.

That way if I decide I don't want it I can give it away or sell it.

The way I do it is just make the script Copy/No Transfer/No Modify.

-i

Is there an issue with this? If it's an attachment, it probably won't matter. If it's something that can be rezzed in-world, then it may be, if you're talking about something like... oh, I don't know... a classy piano with animations & music in it; then I can see you not wanting it to be copyable, because a landlord could buy one then put one in each house or skybox they rent. But if this is an issue, make the item no transfer and put a check in the script so that it only works for the owner; that way, no matter how many he rezzes, only he could use them. And having lots of any one item probably isn't going to do someone that much good.

I'm not clear on why this one is an issue; if they transfer or loan it to a friend, they don't have it anymore. If they don't have it anymore, but they found it useful enough to still want to have it, they'll have to get another, right? So what's the problem?

What? All he has to do is make the script itself no-mod, and then the new owner won't be able to open or even see the script itself. All the new owner will see is that there IS a script inside the object. There are many many instances of this.

If your script checks the creator of the prim and only runs if it matches, and the script is no copy, it will be pretty much locked in if the prims are no transfer. You may need to use a "virgin" alt for building this stuff, one who has never distributed modify or transfer prims.

Right, but I think the idea was setting some scripts no-transfer and some no-copy (and all are no-mod), and making the scripts interdependent such that having copies of just the no-transfer scripts, or transferring just the no-copy scripts, produces nothing of value.

In contrast, of course, just making the script no-mod means the user can't see inside and take the code for their own use, but they can make as many copies as they want and transfer them--even inside a completely different prim created by the user. (Hence the kind of scripting Viktoria describes, to check that the prims' creator is who the script thinks it should be.)

drop a note card set to the missing permition into the prim and it's now set at all three

That only works if the container prim is NM/NC/T and the notecard C/NT.

If the container prim is mod: you can delete the notecard
If the notecard is NC/T: you can drag it from the prim's inventory, making the object NM/C/NT

A copy item in a no mod transfer container is really the only way that's "tamper-free" (until LL changes being able to delete copy inventory from a no mod prim again anyway).

(Edited to add that I personally won't buy anything that NC/NT and if I end up buying something NC/NT because it didn't say it was on the ad, it's the last time I'll buy anything in that store)

I agree. Although, if prestocked AOs had NC/NT permission because the anims inside were NC and the AO prims or script or something were NT, it wouldn't be too surprising. Anims are kinda special, and it's a rare AO that has much custom-bought content that doesn't end up with conflicting permissions among all the anims it contains.

There might be other things like this, but I'm not thinking of any off the top of my head. (Was thinking of texture organizers, but really, textures that aren't full-perm should just be discarded anyway.)

is this something you bought from someone and are trying to get it where you can pull the permissions out to give it to more than one person?

Thanks to all for your responses. The reason for asking was simply curiosity - although I am aiming to start selling a script-based product at some time, there's no reason at all to restrict transfer rights on it, so NC/NM/T is just fine. In fact, I'm coding the product to make it easily transferable.

And no, Ceka, I'm not trying to rip anyone off!

What still seems uncertain is exactly *why* the edit and properties dialogs were both coded the way they are - in other words, why someone must have twice deliberately coded the automatic checking and disabling of the "transfer" checkbox when copy perms are removed. I've always assumed there was good reason for it, but now I'm not so sure.

There is a Linden explanation.
/8/0b/6729/1.html
In short, no copy/no transfer really is something they don't want to encourage.

The reason the permission structure is the way it currently is was the practice of Fair Use. You could either have unlimited copies (c/*/nt), or be able to sell/give it away when you no longer wanted it (nc/*/t). You had to have one or the other.

A good read is this old thread: /120/86/24858/1.html

ok..i just didn't understand the question i guess..it makes sense now heheh

It's because of the "doctrine of first sale" ( http://en.wikipedia.org/wiki/Right_of_first_sale )