Permissions: Traversable License Trees

The permissions system is flawed.

How to make it work:
A license tree is made up of sets of nested permissions for an asset.
License tree is basically a version tracked inventory for the object, when a new license is added to tree a new snapshot of the asset is stored into the node. If the user reverts to a license closer to the root then the object reverts to the state of the object when that license was created/modified; they will be asked if they want to save the current state back into the tree, the default action is to have it generate a new child at the same level as the current. If the user changes to a license further down the tree, they will be asked if they want to import the previous levels object into the current level. A user can remove licenses from a tree. An object from one level may be propagated down to it's child licenses but not up. Unlinking causes the License to slit amongst the objects (creating a new child). When you link two objects with licenses the trees combine (and yes you can revert back to the two previous objects. At midnight (or when ever; or when anyone edits the object) and the objects license has been reverted to a higher level, the asset implodes (this would be hard to enforce on the clothing/tatu's currently on the av).

New folder in Inventory: License
An asset can have it's license put into the license folder by clicking the "Copy to License Folder" button in the objects Licenses window (which can be accessed by the Licenses button in the objects properties, or the Licenses button when the object is open). This folder is so that a license setup can be controlled remotely without having to find the objects inworld (could be used to find lost assets; say your no copy car gets lots, you invalidate the license on the inworld object and the license engine gives you a copy of the original object).

This would require a graphical tree like what you would expect for a family tree.

Asset: 
Fabulous Avatar(Transfer, No Mod, No Copy)
+Mod Version(No Transfer, Mod, Copy)
+Trans Mod Version(Transfer, Mod, No Copy)

As a developer, I'll sure like this implement. But, won't it result in more disk space and loads to the server? As the objects could likely to appears like dozen times

Edited: Just a new idea. What if LL charge a one-time fee upon creating a new node in the tree? That will make everyone think before add somethings to the tree, because it has to worth the charge. And it's also pulling more L$ off the system as developers saving backup of their works. (as someone mention the lower value of L$/US in another foum.)

Heh. This looks like a more sophisticated (and perhaps complicated) parallel to something I posted recently, though I see yours actually came first. Given the current discussion threads that's not surprising.

I was thinking of something that could be more easily understood, and came up with "wrappers". basically, when you apply a wrapper to an object you can put permissions on the wrapper... and the object would be indistinguishable from any other object with those permissions until the wrapper was removed.

To remove a wrapper, you'd have to be the owner of the wrapper, or you'd have to perform an action that matched one of the conditions the creator of the wrapper set.

For example, the wrapper could be removed on sale or transfer. So you could get an object with no copy/trans permissions, give it as a gift, and what they receive would be copy/no trans.

The wrapper could also be removed on sale for at least a certain amount, with that payment going to the owner of the wrapper... not the object. This sale could still be made if the object was otherwise normally no trans... so you could give someone a copy/no trans object they could still sell copies of, and get your royalties from each sale.

The wrapper could be set to be removed at a certain date or after a certain time, so you could sell an object that's got a time limit on how long you can keep modifying it. I also thought of having a wrapper that would effectively llDie() the object when it's removed, so the time limit would let you create rental or demo objects with a limited lifetime.

It could also EXTEND the public domain. For example, you could have a script that would become open source after a year... by which time you're likely to have received most of the profit from it and moved on to something else.

But the wrapper metaphor, and a simple linear progression of states rather than a tree, seems easier to understand to my tiny mind...

err, are you a linden? that is exactly what they said they wanted to do.

They said they want to do? Wrapper? or Traversable License Trees?



Er...I think I see a problem here. If someone got mod/no-trans object, won't this wrapper allow them to make money of their no-trans object easily? Just attach a their prim as a root prim, and apply wrapper to it. Or I'm missing somethigns?

Yes, Argent's wrapper idea is very similar to this proposed plan by Cory Linden:

/20/fd/25069/1.html

Err...I'm sorry again. I tried to read them many times. And still confused...

What the 'wrapper' really is?!?

I can understand the traverse tree. But...what's a wrapper, and what it will look like really in SL o.o

Edited: It seem i misunderstood your concept of traverse tree completely o.o I thought you mean like...version control machanism in the programming applications o.o Oh well. Still not understand the wrapper though o.o

Good point. I'm not sure that this would happen: if the wrapper is subject to existing permission system you wouldn't be able to grant rights (including sale) in the wrapper that you couldn't grant on the object beneath. I mean... permissions are already inherited, so if you put an object in a box you lose the ability to set the box transferrable, and the wrapper is just like an "invisible box" that lets you "see" the object beneath it.

Think of it like a new attribute of an object, one that lives in the asset server and only gets used when you sell or transfer an object (or under other conditions, potentially, but this is the important one... the rest are options). You'll see it in the hovertips and properties:

Wrapper: "Giftwrapper by Creator Resident. (Details...)"

If you're not the owner of the wrapped object, Details would be greyed out.

If you are the owner, you'd click Details and see something like:

Original permissions: mod/copy/no-trans/...

Sale price: L$0.

If you're the owner of the wrapper you'd be able to modify these fields.

When someone who isn't the owner of the wrapper transfers the object to someone else, the wrapper would be removed and the permissions on the object go back to what they were before the wrapper was applied.

If the wrapper had a 0 sale price, you could just give the object to someone else. That would be the normal case for a gift.

Otherwise you'd have to set a sale price on at least as high as the wrapper's sale price and let someone buy it. When they buy it, the wrapper is removed (and if the wrappers permissions were no-copy, you lose it). The proceeds from the sale would be split between you and the owner of the wrapper. So you could set the L$500 object to sell for L$600 and pocket L$100 as commission.

I had absolutely NO idea that the Lindens were already thinking of something like this, let alone had picked the same name.

My proposal has the advantage of being simpler, and would open up a new economic niche... commissioned salesmen. That would be good for the Linden economy, I think. Good for me too, I've already sold a couple of people Chage McCoy's Mehve and it'd be nice if I didn't have to take them to Abbotts and interrupt what we're doing to do it (and it'd be nice to get a commission, too, but I probably wouldn't bother charging that for friends).

Charging users works for me. Replacing an existing node should be free.
This would be an extention to the current permissions. It would use a few of the bits in the permissions bit mask to indicate the existance of an extended license.

Truth be told, this is just an extention of the wrapper topic brought up last year, it just dawned on me now to let users traverse the tree both up and down. As really licensing isn't inteded to restrict what the user can do with the item, but copying. Often we loose sight of that.

I created a new thread to speed up obsorbtion of the idea. It takes people too long to read the long threads and ideas get lost too easily.