Creator Resource - Permissions (Basics)

This tutorial is available at Creator Resource - Permissions (Basics).

---

It cannot be stressed enough how important is to correctly set asset permissions for next owner, to protect licensed items from being indiscriminately shared as if freebies. We have problems enough with content theft, and these problems are increased because many creators do not know, or do not care, about correctly setting permissions for next owner. When you do not care about setting permissions correctly, the message you're sending is "I do not care about content theft". But if you care, and want to proceed correctly, then keep reading.

I wrote this class as a response to my observing how many people were confused about permissions, and many students that took it realized, they were more confused about than what they thought. The class was designed to last 90 minutes, but it always extended up to at least 150 minutes, because of the many questions that arose. I have rewritten all the material, with a lot of screenshots, because from this webpage, you cannot see me rez and inspect my items, so hopefully, all the pictures will help you follow. In rewriting the material, all those questions are also covered. Finally, I've added some links to the wiki, for further reference. I hope you will find useful this resource. Thank you for your concern :-)

Because of the length of all the material covered here, below you have a table of contents for quick access to every section.

• Permissions (Basics) - Starting
• Basic Building Concepts
• The Permissions, and their implications
• How to set up permissions when working with rezzers
• Animations, sculpts... in prop-givers. Why many licenses don't allow us to include them?
• How to make mistakes setting permissions (or, what we should avoid doing)
  
  • Common mistake case one
  • Common mistake case two
• Trivia time
• Answers to the trivia questions
• Annex 1: (Edited) Conversation with a creator about sounds, textures, licenses, permissions and UUIDs in notecards.
• Annex 2: Reply to a creator about why you need special licenses for props that are meant to be used in givers (e.g., a fork, a cake piece...)

PERMISSIONS (BASICS)

Welcome everybody. I am Auryn Beorn and I'll be your instructor for this class.

Setting permissions correctly is a delicate task. It's easy to make a mistake and our creation, or a part of it, finishing like a "freebie" in the grid. Also, it's easy to create an unusable item because the permissions set prevent from certain modifications that our customers might need.

This class is devoted to have a first overview on the permissions system. We'll study which permissions are expected for rezzers and givers to correctly work, and the implications the last ones have (for many licenses may forbid using for example, sculpts or animations, in givers). We'll also study several common (misconception) cases to show what may happen if we set permissions wrong.

The basic permissions we'll study in this class are what "copy", "modify" and "resell/give away" mean, and how to correctly set them for the items we create. These permissions can be applied to any asset in our inventory. "Resell/Give away" is also known as "Transfer", being this last denomination the most used.

One of the key words that will be used in this class is asset.

When we talk about an asset, we are talking about any type of item we can create in SL:

Animations, textures, clothing layers, scripts, notecards, landmarks, objects, etc.

One of these assets is special: object. It is special because it is the only one able to contain another assets in a special area called "the contents of the object."

Yes, notecards may have embedded assets, but this is not the same case than objects. The embedded assets a notecard may have, need to be full permissions for next owner, always. The assets you can have inside objects may have any of the allowed permissions, set.

Basic Building Concepts

There are some basic building concepts that we need to clarify before diving into material.

The first one is the difference between root prim and child prims.

Here I have three unlinked boxes. If you inspect each one of them, you will see that all of them are outlined in yellow.

Now I'm going to link them together, so they form a single object, composed of three prims.

One of those boxes, the last one selected before linking, is known as the root prim. The rest are known as child prims. If you inspect now this object, you'll see one prim outlined in yellow: that's the root. The rest you see in blue, those are the child ones.

What follows is important, and I've seen so many people being confused by this, that I prefer to mention here also.

You have to know that we can drop assets within the prims: animations, scripts, another objects... and when we do this, we say that "we have added contents to an object" or that "we're adding to the content tab" or similar expressions.

When you edit an object, you see by default the contents of the root prim.

So when you're said "Edit the object, drop the script to the object", what you have to do is to drop the script into the root prim. It goes automatically to the root prim.

It is when you click "Edit linked parts" in the edit window, and then click a child prim, when you will be able to drop contents in that specific child prim.

This means that we can drop assets in each and every child prim of the object, not only in the root prim! Keep it in mind, for it will have consequences that we'll talk about later.

Next important concept is something that we have to have crystal clear from this moment.

For every asset in SL, there are two sets of permissions that concern us here:

• Permissions for us
• Permissions for next owner

If we create an asset (that is, a texture, an animation, an object...), that asset is full perms for us, but then we can restrict the permissions of this asset for next owner.

For example: If we purchase a script that is copy/no modify/transfer, we still can restrict it more for next owner and make it, say, copy/no modify/no transfer.

This means, permissions for us, and permissions for next owner, may be different, and if they are, they always become more restrictive. It doesn't work the other way: if someone sends to us a copy/no modify/transfer texture, we cannot make it copy/modify/transfer for next owner.

And this is very important: except for objects, the permissions we see in inventory, and the permissions we see when inspecting, are the same. With objects, things are a bit more complicated, because as we've said, objects may have assets inside.

Let me show an example to explain what happens.

I'm rezzing a box. The box, for me, is full permissions, but it has a default set of permissions for next owner: no copy/no modify/transfer. (This could change with other viewers. Check this always!)

This means that if now I take this box and send it to you, you, the next owner, are going to receive it as a no copy/no modify/transfer box.

We set the permissions of the box once rezzed inworld, in the edit window, under the "General" tab.

I'm going to make this box copy/modify/no transfer for next owner, and take it into my inventory. If I now send this box, the recipient will receive a copy/modify/no transfer.

When you receive the object, you see it coming in inventory.

What do you see in inventory? A copy/modify/no transfer box.

If you rez it, you have a copy/modify/no transfer box too.

But at times, and often, things are more complicated. When? When we add contents.

We will explain later how to change permissions inside objects. Right now, focus in this: Inside the copy/modify/no transfer object used for the previous example, I'm going to add a notecard, and inside the object, I'm going to make the notecard copy/no modify/no transfer for next owner.

Now I take this back into inventory. Which is:

• A copy/modify/no transfer box
• Containing a copy/no modify/no transfer notecard

If I send this... you're going to see the following permissions in inventory:

Copy/No Modify/No Transfer

Does this mean that the box is no modify?

NO.

It means that the addition of restrictions of the full set object+contents is Copy/No Modify/No Transfer.

But if you rez the box, you will see that the box is copy/modify/no transfer, so you CAN modify the box inworld.

Inside the box, you will see the copy/no modify/no transfer notecard.

This is perhaps the most important thing to understand, so I will insist to make sure: We are going to see different permissions in inventory and inworld. In inventory, the addition of all restrictions (prims + contents) is what shows. This also means that you don't know, for example, if an object is really no modify until you rez.

This teaches us a very important lesson: when working with objects, set permissions always inworld. If you set permissions in inventory, problems may happen as we will study in this class.

The Permissions, and their implications

Now, which these permissions are? Let's cover them now.

COPY

When we check this mark, we're allowing next owner to be able to make as many copies of the item as they want. If we don't want that next owner makes as many copies as they wish, then don't check this mark.

NOTE: A no copy notecard can't be open to be read. Don't set notecard's permissions for next owner to no copy if such notecard is to contain your licenses or documentation, which is meant to be read :o)

(At times, I've seen licenses in no copy notecards. Be careful, your customers won't be able to open them to read.)

NOTE: A no copy texture (for you) can be applied on a prim (and only one prim), but as soon as you do, the texture will travel from your inventory, to the contents of the prim. When you are the one setting a texture no copy for next owner, this will happen to those that receive it.

NOTE: A no copy script can't be read either.

This permission seems easy to understand... but I'll talk about what happens when we want to use rezzers like a rez faux for houses. Before complicating things more, let's move on to next :-)

MODIFY

When we check this mark, we're allowing next owner to be able to make changes to the item, as changing the name, texture it differently, relocating all the prims, unlink, relink, edit the contents in the inventory...

If we don't want that next owner is able to make any change at all (except only those that a script would allow, like resizers or texture changers), then don't check this mark.

Let's do some emphasis on "next owner can edit the contents in the inventory".

Think of a house with doors, the doors allowing several access levels, including white list, being the white list stored in a notecard. If we make the house no modify for next owner, the user that buys our house will not be able to edit the notecard, so the white list ability renders useless for next owner.

Houses... or furniture.

I've seen this happening in furniture too. "The ultimate couch, you can decide which set of animations to load" (usually, set with MLP, XPose, AVsitter...), being the object, no modify. What happens here?

If the furniture object is modify, then we can edit the furniture, and delete the notecards that we don't want, or even, edit notecards to customize presets.

But if the furniture object is no modify, the customer will not be able to do this.

Also, if the object is no modify, we will not be able of resetting any of the scripts contained in the object. Keep this always in mind!

The detail about the scripts is delicate, because there could be a weird sim crash that leaves the script "in shock" and only a reset could "revive" it. Our customer will not be able to reset such script if the furniture (say) is no modify, which may render the object... useless... and if the object is also no copy... What a bad joke!

So be careful before deciding that an object is no modify for next owner, specially if you also make it no copy. If the object is copy, the customer has at least the option of rezzing a new one.

NOTE: Applying a copy/no modify/transfer sculpt map will not change the permissions of the prim for you. This means, the prim will continue to be full perms to you, if you're the creator, and you can continue to set permissions for next owner as you consider best for your creation.

NOTE: The same can be said from a copy/no modify/transfer texture.

NOTE: A no modify script can't be open. The code remains safe from copy/paste.

Remember, from what we've said before, that if an object is modify for next owner, and we drop a no modify script, that doesn't make the object no modify. That makes the object to show as no modify in inventory, but once the object is rezzed, it is clear that prims are modify, while the script is not.

So, for example, if you work with scripts from other creators, which are no modify... worry not! Your rezzed object will have the permissions for next owner that you have set.

(I know, no modify is perhaps the most complex permission to understand, because of all the implications over different kinds of assets.)

Let's move on now onto last permission :-)

RESELL/GIVE AWAY (TRANSFER)

Finally, if we check this mark, we're allowing next owner to both resell or give the item away.

Currently, there's no way to set an asset only as resell, or only as give away, so keep this in mind when you check this mark. Let me explain what this means, with an example.

Imagine that you, in all your good will, set an item as copy/transfer, to be distributed as a freebie.

Someone can take it and sell it after, because transfer applies to both: give away AND resell. They are not separated abilities, they go together: If it can be transfered, it can be sold.

Remember also that to set an item for sale, you have to edit it, and under the general tab, you check the "For Sale" box, decide if you're selling the original, a copy or contents (last one, recommended for store products), and the price.

NOTE: You can apply a no transfer texture to an object. This makes the prim where you apply it, to have a copy of the texture in contents. If you delete the texture from contents, it's removed also from the surface of the prim. If the object was full perms, when taking it back to inventory having this texture applied, makes us see the object as no transfer in inventory. The texture is the cause.


Question: If a house controller or component of a build, like blinds, are set to copy/modify/no transfer, will the next owner be able to separate the components an re-use or sell them?

Answer: If the components are no transfer, next owner won't be able to sell them. Now, if the house is modify, yes, next owner can UNLINK it, change textures, add prims to it, or remove some. But they will not be able of transferring (resell/give away) the parts AND contents if their permissions are all are set correctly.


An asset may have one of the following permissions set for next owner:

• Full permissions (copy/modify/transfer, often written as FP)
• Copy/Modify/No Transfer (C/M/NT)
• Copy/No Modify/No Transfer (C/NM/NT)
• Copy/No Modify/Transfer (C/NM/T)
• No Copy/Modify/Transfer (NC/M/T)
• No Copy/No Modify/Transfer (NC/NM/T)

Note that an asset cannot have set at the same time "No Copy" and "No Transfer".

I know, objects (and nothing else) may show as no copy/no mod/no transfer in inventory. And that's exactly why: the addition of restrictions makes them show that way in inventory, but the object will not show as that when rezzed inworld.

That means, when you rez them:

• Some contents may be no copy
• Some, no transfer
• Some, no mod
• The object could even be full perms

But it is the addition of restrictions (prim + contents) that makes it show as no copy/no mod/no transfer in inventory.

This does not mean that, for example, an animation, could be set both to no copy and no transfer. We cannot do that: Either one (no copy), or the other (no transfer).

How to set up permissions when working with rezzers

This was asked often in this class: Which permissions are adequate for items that are rezzed from a rez-faux or similar system (any system that rezzes props fits here too!). For that reason, I've added this separate section to cover this material.

To answer that, we need to insist in the difference of how permissions are shown in inventory, how permissions are shown inworld, and know that the content tab of a prim is like a mini-inventory, with all the consequences.

I'm going to send you all an object, which will "emulate" a rezzer system. To build this object, I make the following:

First, I build inworld a "house" (a box simulating to be a house), and inworld, I set permissions for next owner of this box to no copy/modify/transfer:

Then I take this box into inventory. Now I rez another box, which will be the "rezzer system". I add in contents a script that will simply rez the object in the inventory of the "rezzer system prim". This script has as permissions for next owner, copy/no modify/no transfer. And I also add the "house" object to the contents of the "rezzer":

(Now I send this to my alt.)

Notice how what arrives into your inventory says no copy/no modify/no transfer. Addition of restrictions! The object itself cannot be no copy/no transfer at the same time.

Rez it as you receive it, and let's examine the contents. Please do not click it!

The contents are:

• A copy/no modify/no transfer script
• A no copy/modify/transfer object

That's how they show in inventory at least, yes?

Now, if we click (that we're NOT doing yet)...

This script will rez a copy of the "house" object. But since the object shows as NO COPY in the inventory of the prim... the object will be rezzed... and deleted from the "rezzer" box.

Now, click to see this happen. If you inspect again the "rezzer" box, and wait for inventory to refresh... Do you see the object inside anymore? (If you see it, suggestion: click another object, click back, and then the inventory will reload)

You see it no more because the "house" object inside was no copy, and thus to be rezzed inworld, it means the copy in the rezzer can exist no more, so it's removed from the rezzer.

So the "house" object was no copy. Actually, that's how it shows in the inventory of the container prim, the rezzer. And what have we said before about inventories? That what we see, is the addition of restrictions, prims + contents.

So this object to be rezzed, no copy, could be because the prims are no copy...

... or because there's any content (script, texture, etc) in any of the prims, that is no copy.

Now, this is important for rezzers. We all know that everybody here has deleted once in a while their house :o)

A rezzer for a house, ideally, should be able to rez as many copies as desired. So the contents of such rezzer, the object to be rezzed, that is, the pieces of the house, have to be at least copy. These pieces of the house show as content in the inventory of the rezzer, so the permissions that show are the addition of restrictions.

What does this mean?

That if we are creating a house, and this house needs a rezzer, we have to make sure that all the pieces are at least copy, in inventory.

That is:

All the prims are at least copy

and

All and every asset that every child prim may contain are also, copy (scripts, textures, notecards, animations... all!) Because, otherwise, the house will show as no copy in the inventory of the rezzer, and this that happened here with this box, will happen to your customer.

(I know! It is a pain to check the whole object when it shows as no copy in inventory.)

You should, for example, make the scripts copy/no modify/no transfer for next owner, if those scripts are part of an object that goes inside a rezzer, and the same for every other asset to be included.

So if you take an object into inventory, and see that it shows as no copy for next owner, and that object has to be in a rezzer... It's time to hunt the asset that is making it appear as no copy.

You have to cover all of the child prims for this, to make sure that all of them are clean, or find out which one is causing the issue.

It takes only one child prim containing a no copy texture, for your whole object showing as no copy in inventory.

Once again: Always, in inventory, addition of restrictions, even if one. (Except if you mess around and break them, as we'll see in the second example I have ready for later... and that I strongly discourage to do!)

Ok, now we can delete these boxes :-)

(They were just to show what happens with the rezzer, if the contents are no copy)

Needless to say, this actually applies to any kind of rezzer - whether the item to rez is a house or a dinner menu.

Animations, sculpts... in prop-givers. Why many licenses don't allow us to include them?

Following there's an edited chat happening first in a group, then in private. The purpose of my editing this chat is to preserve the privacy of the persons involved and the conversation by simply presenting the relevant questions that were done in a generic way. My answers are edited only to complete information.


Person in group chat (P): What would be the correct permissions to set to an animation when I want to do the following...? I want a cake that gives a piece of cake to avatars that click it, and I want that the avatar is animated when they wear the piece of cake.

Auryn Beorn: That case you mention, P, is actually a problem. Many animators won't allow in their licenses that you do so. You have to find a way to animate the avatar, if possible, not being the animation in the piece of cake, but in the giver object.
Auryn Beorn: Because to be able to give pieces of cake, the animations have to be included as copy/no mod/transfer, and then the avatar could open the piece of cake object and get a copy of the animations, even give them away.

Another person in group chat (P1): There's no reason why the cake has to be transferred. The cake owner transfers it, but the piece of cake receiver doesn't need mod or trans on the anim.

Auryn Beorn: The problem in what you say, P1, is this: if you set the animation as no transfer, that will make the piece of cake in the giver object appear as no transfer too in inventory, so it won't be able to deliver copies to any avatar that isn't the owner of the object.

P1: oh yeah

Yet another person in group chat (P2): Auryn, and what about the script you had us working on in class?

Auryn Beorn: Yes, I know that we've been working in a script that makes props unusable after a first use, but you have to cross fingers so they don't wear the object in a no scripts zone and don't think of inspecting it to extract contents ¬¬

P2: Auryn, is there any way for a script to delete the contents of the prim it's in?

Auryn Beorn: Yes, but for that the script needs to work.

P2: Maybe a delete animation on detach could work?

P: Would that be hard to do? I mean, what P suggested, deleting animation on detach?

Auryn Beorn: Still, you can edit it while wearing and extract the animation. Animators won't allow that you use their animations in giver-objects in their licenses for this reason.

P: Then, the only way around it is to make the animation yourself?

Auryn Beorn: Make the cake itself to contain the animation and request permissions to animate the avatar once they wear the piece of cake.
Auryn Beorn: I don't make the props have the animations, I make the giver object to be what animates you.
Auryn Beorn: Think of the cake as a "chimera" =)


After this, P sent me an IM


P: What happens is that I've seen in many places, like for example wedding places, food places... That they have their animations in the pieces of cake, the drinks that are dispensed... Is this something that perhaps they've worked out with the animation creator?

Auryn Beorn: If the animator licenses that, it's okay, but many won't.
Auryn Beorn: The problem is this...
Auryn Beorn: Imagine that you buy a drinking animation, and want it active when a glass you deliver in a giver object, is worn.
Auryn Beorn: The animation needs to be at least copy/transfer, otherwise, the giver object won't be able to deliver the glass to other than the owner of the object, because if you make the animation no transfer, the whole glass shows as no transfer in inventory.
Auryn Beorn: No script in the world can prevent that you EDIT the object meanwhile, and you make a copy of the animation in your inventory.
Auryn Beorn: Many animators are very aware of this and clearly won't allow you to do this, and warn you NOT to do this with their animations.

P: How about if we set the piece of cake object as no modify? Would that help?
P: Because no modify would mean you can't pull out the scripts or animations, right?

Auryn Beorn: It doesn't help at all.
Auryn Beorn: The object is no modify, yes
Auryn Beorn: But even if the animation was no copy (which will make unusable the giver, too), you can extract if from the object.
Auryn Beorn: You CAN pull a no copy asset from a no modify object.
Auryn Beorn: The asset is not anymore in the object and can't be inserted back.
Auryn Beorn: But by then you have now a copy of the animation that you should not have.
Auryn Beorn: And you could of course, click more for more copies of the piece of cake and get more copies.

P: Ahh... Right... I didn't think that people do that

Auryn Beorn: That's why my approach is make the givers act as chimeras :-)
Auryn Beorn: All the animations are in the cake, nobody can take them
Auryn Beorn: It's not immediate, but at least this can be done and respect that way the animators' licenses.
Auryn Beorn: I hope this has clarified ideas, permissions are tricky :-)

P: It has... and very true!


This conversation introduces also a myth about permissions. The myth saying "you cannot extract assets from a no modify object". Heck if you can! No modify doesn't prevent extraction.

How to make mistakes setting permissions (or, what we should avoid doing)

Common mistake case one

This is a frequent mistake: the permissions set to next owner for an object will not cause the permissions for the content of the box to automatically change. Yet, many creators still think that this will magically happen!

Let me prove this: I'm rezzing a box that you all can inspect. I'll leave the box with the default permissions for next owner, that is, no copy/no modify/transfer.

Then I'm adding two assets: a full perms animation, and a full perms texture.

Now, if you want to inspect my box and check the permissions I've set for the contents, for next owner, you have to do this (for example, for the animation):

• Right click the animation in the content tab
• Select "Properties" from the menu
• You now see a window show
• And then, at the bottom part, we can read "Next owner can:"
• There we see the Modify, Copy, Resell/Give away

Do you all see that the animation has set as permissions for next owner, FULL PERMS? Now check the texture to see that it happens the same. Texture, for next owner, is full perms.

And the box itself, no copy/no modify/transfer (for next owner).

Now I'm taking the box and sending you all a copy. Please give me a moment to complete this. Don't rez anything until I've finished sending boxes.

(I always sent this manually. Yes, I could have set it up in a supplies box for them to buy it, but this way they focused in what was arriving to their inventories.)

Now you all have a no copy/no modify box in your inventory, right?

Some would think that my animation and texture should be protected. Are they?

Rez the box.

Yes, now the box is not in your inventory anymore, but inworld, since I set it no copy specifically for next owner.

But edit it, and go to the "Content" tab. You all see that the animation and the texture are full perms. You can, in fact, drag them into your inventory.

Do it.

The box's permissions have not prevented from you taking a copy of the full perms items within, nor they've automagically changed the permissions of assets in the content of the object.

What is this telling us?

That we have to set the permissions to all the items in the contents of the object, not only to the box.

This is a common mistake and that's how some animations have ended up distributed as "freebies". They're not freebies. So this is the first mistake to avoid.

And does it seem to obvious as to make it?

Then let me say something. I am bored, yes, bored, of inspecting hunt gifts and assorted furniture I have bought, and finding animations and scripts with the permissions not changed. At all. Even more: less than 20% of my customers sending me an object set with my scripts, so I can assist them, have set permissions for next owner as I request in my licenses.

This happens, and it's more common than what we would desire.

So remember to always set permissions not only for your object but also for all and every of the contents.

Fortunately we can set the permissions for all the items in the box at once, as we're studying next.

I'll assume that you now have a copy in your inventory of the full perms animation and texture. Delete the box itself and rez a new one. Once you've rezzed that box, drop the animation and texture. Drop them several times, if you wish.

In edit mode, in the "Content" tab, click the "Permissions" button.

A window shows giving you options to set all the items, or all the scripts, or all the animations, etc., with a specific set of permissions.

In our example here, we would tick the animation icon, then the texture icon, and then below "Next owner", we tick the permissions we want to set, then click "OK", and that will apply the permissions for ALL the animations and textures, in this case.

My screen capture shows a few more assets ticked, but obviously, if you don't drop any of those inside your box, that will not affect.

It notifies with a message when it's done:

This is, then, a "permissions set batch" that can be very handy.

In this example, it will change the permissions of ALL animations AND textures in that object, to copy/no modify/no transfer for next owner. If instead of one animation, you have 20, the permissions will get applied to the 20 of them.

You have to do this for EACH child prim that has assets!

Also, as a preventive measure, change permissions to next owner for your full permissions supplies to be included in the "Content" tab of your builds (scripts, textures, animations, sounds...) AS SOON AS YOU ACQUIRE THEM, in your inventory.

If you want to make completely sure that you've set them correctly... Send the item to an alt, and have your alt check the permissions. The item your alt receives will have the permissions for next owner that you've set.

Now...

Common mistake case two

I'll explain this one with an example.

I'm going to rez another box, and set it as copy/modify/no transfer.

Now I'm adding the animation and the texture, and changing permissions for next owner to no copy/modify/transfer, because I don't want next owner having more than one copy of the animation and texture.

Please inspect this box, and tell me which permissions for next owner do you see for the box (prims) and the contents. Remember to enter in the properties window for each asset, to check this. You have to right click the asset, then properties, and then there, you see it :-)

Now I'm taking the box to inventory.

Then I check the properties in inventory, and tell myself "Hey! These are not the permissions I set for next owner to the box!" (it shows as no copy/modify/no transfer)

This is, I forget that what appears in inventory is the addition of restrictions, and I decide to "fix" permissions in inventory, by setting them to copy/modify for next owner... in inventory! (and yes, those quotes for "fix" are correct :o) )

Ok, what I've done in fact is break them. Please wait while I send a copy to all.

(Same as before: I always sent this manually, for this way they focused in what was arriving to their inventories.)

Before doing anything, as you receive it, notice something interesting: the item appears in your inventory as copy/modify/no transfer.

Now please rez your box. This time, you keep having a copy of the box in inventory.

You can extract a copy of the items in the box in the ground. Yes, this will make the box empty... But you have another copy in your inventory that you can rez to extract more copies!

Once I knew a girl that used this to send copies of clothes that were gifts from MM boards to her friends (when those gifts from the MM had this problem, of course). I'm sure that the creator would have not agreed. She rezzed the box, took a copy, sent to a friend. Rinse, repeat. Needless to say, this is WRONG to do.

Moral is: Never "fix" permissions for OBJECTS in your inventory. If you're not sure, rez the object, and fix the permissions inworld.

I know, it's a pain. But it's the only way we can make sure.

Let me insist:

You CAN change SAFELY permissions for next owner in your inventory for animations, textures, scripts... But to make sure of permissions for next owner for OBJECTS, always rez them inworld and test permissions inworld. Not in inventory. Not while attached. Inworld.

It's the objects which are a problem because they might have CONTENTS, and those contents... have their own permissions!

To finish with this class on the basics for permissions, let's do a trivia.

Trivia time

QUESTION 1: You've created a notecard with information about some places, embedding pictures and landmarks. You want this notecard to be freely distributable but you don't want the content to be modified so nobody puts words on you. Which permissions should you set?

QUESTION 2: You've designed a tattoo and want to send it to your friends. You want your friends to be able to modify the tattoo (perhaps to add other textures in the avatar body parts your tattoo doesn't use), but not to be given away by them. Which permissions should you set?

QUESTION 3: You've created a house using a white list notecard to set the access configuration, and this notecard has to be edited by the user. Which permission, at least, do you have to set for the house?

QUESTION 4: You've created a piece of furniture with an experimental script that might need to be reset from time to time by the user. Which permission, at least, do you have to set for the piece of furniture?

QUESTION 5: Now you've created a couch and you don't want that next owner makes any copies at all, nor can modify the couch. The couch uses a script to change texture, but the user should not be able to modify the couch at all. Which permissions do you have to set for the couch?

QUESTION 6: Continuing with the couch above, now you also don't want that the script can be open and the code copied by next user in another script of their own. Which permission should you check for the script, apart from the couch itself?

QUESTION 7: Continuing with the script above. If this script is changing textures and the textures you're using have a license saying explicitly that they never should have set both Copy and Transfer at the same time, which permission should you check for the script so you abide by the license terms?

Answers to the trivia questions

QUESTION 1: Copy, No Modify, Transfer
QUESTION 2: Copy, Modify, No Transfer
QUESTION 3: Modify
QUESTION 4: Modify
QUESTION 5: No Copy, No Modify, Transfer
QUESTION 6: No Modify
QUESTION 7: Here, I would do this:

If the furniture is No Copy, then No Copy/No Modify.
If the furniture is No Transfer, then No Modify/No Transfer.

Always CONSISTENT permissions! It's going to save you a lot of headaches :-)

And this is all for class!
I wish that you come away with new knowledge. Thank you all for coming.

Annex 1: (Edited) Conversation with a creator about sounds, textures, licenses, permissions and UUIDs in notecards.

Creator (C): Hey Auryn. I bought [one script] yesterday. I wanted to make sure that I stick to your licence. My products are mod/copy/no trans. So if I set permissions for next owner to copy only in your script, that should be ok, yes?

Auryn Beorn: Yes, that is perfect :-)

(Some minutes after)

C: Sorry to bother you again, Auryn. I knew there was something else. You mention in the documentation something to do with sounds. Are you saying that I need to enclose the actual sounds I'm using, in the objects contents? I can't just copy the UUID into the notecard, without having the actual sound in the contents? Just wanted to clarify.

Auryn Beorn: You can do either. But if you copy the UUID in the notecard, there's a license problem. Let me explain.
Auryn Beorn: Sounds, like textures, animations... are subject to license. Normally, you are not allowed to distribute them in your builds in copy/transfer form.
Auryn Beorn: Now, there's an extra problem with sounds and textures.
Auryn Beorn: If you obtain the UUID of a sound, or a texture, you can use them *as if you had them full perms*, even if you do not have them in your inventory.
Auryn Beorn: A script having the UUID of a sound/texture, can use them.
Auryn Beorn: So you should make sure of two things...
Auryn Beorn: One, that you don't distribute a copy/transfer inventory asset - this is the part we all have very clear.
Auryn Beorn: Two, that you don't distribute the UUIDs either, because that would be the same as distributing the asset as full perms.
Auryn Beorn: There might be sounds that allow you to be distributed, like for example the Linden sounds from our library: you could use only the UUID there. And of course, you can do whatever you wish with your own sounds (sounds you've uploaded.)
Auryn Beorn: But normally, you've purchased the sounds.
Auryn Beorn: So you would set permissions for next owner to copy/no modify/no transfer (for the prims in your build are copy/no transfer)
Auryn Beorn: Drop the sounds with the permissions changed together with the script
Auryn Beorn: And in the notecard, write the *sound clip name*, as they are in the object you want to sell.
Auryn Beorn: All this long explanation is so you understand why normally you should drop the sound files, with permissions changed, and in the script configuration notecard, use the sound file name, not the UUID.

C: Ahh, I see. I just used the UUID in there. So I need to change that to the actual sound name.

Auryn Beorn: Correct :-)

Annex 2: Reply to a creator about why you need special licenses for props that are meant to be used in givers (e.g., a fork, a cake piece...)

«I am making an item that is an attachment in an item I'm selling. Which permissions should I set to the attachment, since it comes from a giver? Everything copy/transfer? If this is the case, would be enough to set the object as no modify, to prevent the contents from being extracted? Are there any scripts to prevent this?»

This is again the "you can't extract contents items from a no modify object" myth. Nothing can prevent this from happening, not even a script. You CAN extract contents from no modify objects. Anyway, I gave a full-long explanation, which follows.

When we talk about permissions, you have to see them always separately:

• The permissions the PRIMS have themselves
• The permissions of the ASSETS they CONTAIN within the "Contents" tab
• The permissions that are shown in inventory when you take the object

The last ones are what make people believe that a modify object is no modify, for example.

So in the case you describe, I read that you're making:

• A copy/no modify/transfer object, with permissions set inworld when rezzed, NOT when attached
• Assets like a script and sound clips, which are initially copy/no modify/transfer

In order to abide by the sounds and scripts license, you have to set the assets inside the object to copy/no modify/no transfer, or to no copy/no modify/transfer. The problem is, when you take the object back to inventory, you will see that the permissions for next owner in inventory have changed to this too. The prims continue to be copy/no modify/transfer, but the object in inventory, and this is important, what the giver object is going to see, will be copy/no modify/no transfer or no copy/no modify/transfer, which makes it not work for your project.

You would think "ok, then I set script and sounds to copy/no modify/transfer too, and then the object will show as copy/transfer in the giver". The problem is, ANY avatar getting a copy of such wearable, CAN extract the contents of the attachment, and those contents they extract are... copy/transfer!

This means that you have to make sure you use scripts, sounds, etc... that allow in their license, to be used copy/transfer. That's not going to be easy to find at all.

I would first analyze the situation, in case you can transfer the script functions to the object giving the attachment, so they would be running in the giver, not in the wearable, and thus you can set the permissions the licenses demand.

(A little note here: make sure that the sculpts/textures license allow to be used in wearables - I know of at least one texture & sculpt creator that does not allow the textures and sculpts to be used in objects that should be copy/transfer.)

If, after analyzing the situation, it's impossible for you to transfer the script functions to the giver object, then you will have to look for scripts and sounds (in this case) that allow to be used in copy/transfer form, because in order for the giver to work, you're forced to set the contents of the wearable to copy/transfer, and avatars will be always able to extract copies of those copy/transfer assets, no matter the wearable is no modify or not.

No modify does not protect the assets from being extracted: they can be COPIED to inventory. No modify prims will only make that the contents cannot be removed from the item (and even there's an exception - no copy assets from no mod objects), but no modify prims cannot prevent copies of the contents from being done.