Permissions: need support for value-added resellers

The recent debacle concerning MLP beds is just another example of a problem that could have been avoided with a technical solution.

Briefly, here's what happened. One or more animators made animations, and sold full-perm copies to a maker of furniture whom I'll call EC, who used them with the free MLP scripts. Unfortunately, EC distributed one or more copies with full permissions. (It looks to me as though it was a Business In A Box situation, which is likely to lead to this kind of problem.) Those copies got widely distributed.

One or more of the animation makers filed a DMCA claim, and SL took the action of deleting all inworld content (and perhaps also inventory content, though I'm not sure about that) created by EC -- including items in the inventory of other objects.

The resulting fiasco is documented in other threads.

The underlying problem here is that SL's permission system does not support a model for value-added resellers. Because of this, those who make items intended to be used in other people's products must distribute their items with full permissions.

No doubt there are other threads on this subject, and I'd be happy if folks could post links. My search efforts haven't worked.

First, I'd like to point out that the SL permission system is really quite remarkable. It is very useful and yet relatively simple. Yes, it seems confusing at times, but if it were any simpler, it would be terrible. I shudder to add more complexity to it, but I think it's necessary, and that doing so would increase the quality of inworld content.

Many times I've made things that would be nice to sell to resellers, but I don't want to see it appear as freebies, so I keep it to myself and my own products (or I go ahead and make it free). I doubt I'm alone in this!

I have a strawman suggestion that would involve only one new checkbox: a "reseller limitations" checkbox. This box would be dark unless an item allows next owner copy/xfer permissions. If the object has copy/xfer permissions, it becomes active and is unchecked by default.

If checked, it means that the next owner gets copy/xfer permissions, but must set the object to copy/no-xfer or xfer/no-copy before transferring it in any way. Attempts to violate this requirement would lead to the same behavior that trying to transfer no-xfer content has now.

This allows makers of textures, animations, scripts, and other included content to sell their wares to people who use them in builds or creating products, without worrying about them becoming unintended freebies. It would reduce LL's burden regarding DMCA claims, because makers would use SL features rather than difficult-to-enforce license agreements.

Modify permissions would be unaffected. If there's a great enough need, we could provide a second checkbox for "next-next-owner can modify", but I hope we don't need it.

Note that my suggestion doesn't support a multi-level value-added reseller chain. If anyone has a simple suggestion that would cover that case, I'd love to hear it! For example, I make an animation that someone builds into a scripted pose set, that someone else builds into a furniture item, that someone else builds into an apartment, that someone else builds into a sim, that someone else buys as the end user. The only solution I can think of would be to have an L$ cost deducted for each transfer*, with proceeds going to the original creator -- and I doubt LL wants this much complexity. But that sure would incentivize multi-level creation!

[* With limitations I won't go into that allow you as the end user with xfer/no-copy perms to sell the item at any price without further remuneration of the original creator.]

Comments, suggestions?

Craig Altman has come up with some kind of scripted perimssions system that allows items purchased full perms to retain full perms by the original purchaser but those items can only be passed on with either copy OR transfer checked - not both.

It would certainly be easier for an integrated solution in SL but resident created solutions are starting to fill the gap.

The problem with scripted solutions is that they only work if you include the script. As such it only really provides a solution for protecting scripts!

I certainly would support a system which allowed you to control the permissions the next owner can grant as well as what they receive.

A better provenance model whereby you could see at least who has made mods to a modifiable object as well as who created it, wouldn't go amiss either.

Matthew

I did suggest a similar thing at one time, by which there would be a "third" permission set. So you would have "Current perms", "Next owner", and "Future owners". In this way, you could make the next owner a special case (if they were going to be a reseller for example).

But I believe the problem has always been, when you add a new permission, what do you default it to? Remember there are millions of objects in-world which all have permissions, there must be some kind of simple algorithm for deciding what the newly created permissions fields should be set to but it's really hard to think of one that doesn't end up creating objects with permissions they're not supposed to have or vice versa.

Yumi, I prefer my suggestion to yours for the simple reason that the maker doesn't need to stock two copies of each item: the reseller gets to choose the model. It also has fewer checkboxes. These are minor issues, though.

For existing objects, the answer is simple: the "reseller limitations" would be unchecked, so the current semantics would remain. For the case of your suggestion, it's equally simple: they would be copied from "next owner", which would retain the current semantics.

This proposal sounds fine in theory but in terms of getting it implemented I shudder - why? Well, the perms system goes right to the heart of SL functionality. There is no such thing as a simple change - are people going to be prepared for the versions of sims and the viewer that are broken and people can walk away with stuff they should not because it became full perm by accident or No Copy, No Transfer stuff becomes Copy, Transfer, or conversely be prepared to replace stuff that becomes No copy, No Transfer when in fact it should be copiable and transferable?

Then there is script compatability to worry about when existing compiled scripts meet the new perm bit - could result in significant script breakage.

Just my thoughts - be careful what you ask for is all I am saying.

But there's the problem: as soon as you've done that, it becomes indistinguishable from an object where you _genuinely intended_ the reciever to give the object away.

In other words, all existing items that were being passed on as freebies without authorisation would essentially recieve a permissions mark (ie, reseller limitations unchecked) saying that it's OK to do so.

Which they already implicitly have. Furthermore, the item's creation date indicates whether the mark was set explicitly or not.

IMHO, the problem is worse than the risks of solving it. Any change has risks. Arguing only about those risks means never improving anything. You're certainly correct that the implications to LSL would have to be carefully considered.

LL has understandably resisted adding complexity to the permissions system. But the recent and ongoing problem with this kind of stolen content won't go away until they do. LL needs to own up to the fact that their permission system forces content creators to open themselves up to this problem by selling items with full permissions. It's broken and needs to be fixed. Trying to resolve every individual case where this happens is untenable. As it is, LL only acts when the harmed parties are big-time players with clout.

Change causes upset, but lack of change is stagnation.

The only permission that needs to be seriously considered is owner-after-next copy, and is only active if copy is enabled. I wouldn't limit owner-after-next transfer, because some poor schmuck who buys a couch he changes his mind about could end up stuck with it.

in all honesty, the permissions system is the LAST thing i want ll tinkering with.
i dont trust them not to screw it up and leave it broken for a year while they polish whatever shiny has caught their attention.

That doesn't quite work. Your point is valid that nothing should ever be no-copy/no-xfer, but that's currently not possible anyway.

The reseller should get to choose whether to sell using the copy/no-xfer or xfer/no-copy model. Both make sense, both are useful, different people prefer different models for different kinds of things for all manner of reasons. My suggestion allows a single copy to be sold by creator to reseller, and reseller gets to choose which of these models.

If the only option is "owner-after-next-copy", then it's not possible for the reseller to sell as copy/no-xfer.

Understandable, but perhaps you're not in the business of creating things that are commonly used in others' products. For those of us who are, this is a big issue. And it affects everyone, because the current situation creates a huge disincentive to create and distribute this kind of content.

I know I've weighed in on this somewhere before, but search is not my friend in finding the ancient threads. But anyway, I recall my old ideas being kludgier than this, requiring a sort of "next-next owner" permission set that replicated all the current "next owner" permissions. And I think it's exactly right that "next-next owner Modify" permission, separate from "next owner Modify" is unlikely to be necessary.

I'm not quite sure, from a usability standpoint, whether these should have the "sign" of limitations or permissions.

Somewhat orthogonal to the semantics is the internal representation of these permissions. In http://lslwiki.net/lslwiki/wakka.php?wakka=llGetInventoryPermMask there's a hint that a lot of individual permissions could be added (PERM_ALL being way more bits than are currently twiddled by existing individual permissions), but I think what we're really talking about is what this function would call a new permissions *mask*.

(Unless I missed a reference to this already in the thread, see also http://jira.secondlife.com/browse/VWR-1673.)

The permission system is due to be completely overhauled by 2005 to better accommodate customer needs.

I kid thee not; Robin announced it somewhere.

I just found http://jira.secondlife.com/browse/VWR-1673, and it matches my suggestion. I've added some refinements concerning LSL implications and backwards-compatibility.

Thanks for the link in any case Qui, and also for the pointer to the LSL call. I knew there was one, but it wasn't on the top of my head.

Please vote for the JIRA entry if you agree.

Here's my comment on the JIRA entry:

SL needs a permissions model to support value-added resales.

Currently, those who create basic items used in others' products, such as animations, textures, and scripts, are forced to sell them full permissions to the OEMs who use their products in theirs. This inevitably leads to content being distributed freely, and illegally. This leads to DMCA claims and fiascos when LL attempts to respond to the claims (as recently happened for Eva Capalini content).

The simplest solution is, as suggested above, a single checkbox inhibiting next owner from transferring copy/xfer. This checkbox would be inactive (gray) unless next-owner copy/xfer boxes are both checked.

This suggestion would only permit single-level value-added resales chains, but that would be a huge improvement over the current situation.

Previously created content should retain the current semantics -- that is, anything with full perms should continue to have full perms. This gives the false appearance that they're intentionally unrestricted. To avoid this problem, instead of a checkbox it could be a "restricted / unrestricted / unset" selection, where the semantics of "unset" are identical to "unrestricted".

For llGetInventoryPermMask:
add PERM_RESTRICTED, which would only apply to MASK_NEXT. This means that the next owner is restricted and cannot transfer the item with full permissions.

Note that modify permissions are unaffected.

====

Comments please!

One thing you might like to consider is how your new flag would interact with scripts.

At the moment, if a user has full perms on an object, they can insert a script which uses llGetPrimitiveParams to dump the parameters (including texture keys) for the entire build, and then rebuild it with themselves as the creator. Presumably your reseller flag would have to stop this happening, but what permissions would you restrict? (At the moment, you can get the prim settings of any object with modify permission, but getting the texture keys requires full perms.)

Also see this:

http://jira.secondlife.com/browse/SVC-1654

I'll be looking into it. Looks well-thought-out at first glance, but I need to study it. Interested in your thoughts as well.

First, anims and scripts can't be copied this way. Second, anything that method works on can't be protected completely anyway. Third, raising the bar on content theft is a good thing, even though it's true that there will always be pole-vaulters who can get over the bar no matter how high you set it.

Fourth, this is related to Modify permission only, which I think we should leave alone. Don't want this kind of threat to your objects? Make them no-mod.

So, interesting consideration, but I don't think it argues successfully against the proposal. Thanks for your input!

IMHO - I think that by the time an SL'er joins the SL economy, I would think that one would be savvy and sophisticated enough to handle a touch more complexity in the permissions solutions, after all, if you really want protection, go to the extra effort.

As LL does with the handling of the Lindin dollar exchange, why not establish a two tier system, a basic (as it is now) and advanced tier for Creators who need resale permissions.

It sounds like a good idea. I do realize that this would be a very big change and with the Lindens it's hard to predict how it successful it would be. We should always weigh the cost and benefits. Let's look at the benefits of this reselling perm change.

Knowing your product can't end up as a freebie will encourage people to:

1. Create more resellable products. People are put off with the idea of giving out copy/transfer items and don't even attempt to sell or don't put out as much as they could. Resale perms would inject both confidence and creativity for both the basic component creator and the final product creator.

2. Lower cost of resellable products. People price their full perm items with the knowledge that their items could get resold or turned into a freebie very much like the way software companies raise their software prices. Peace of mind=lower cost.

3. Create more custom products and lower the cost of such things. Knowing that a custom product could become totally the opposite of custom certainly puts off people. If you gave out a custom product for 5 people to resell you would be assured that it would stay at 5 people.

4. Create new business models. BIAB could actually mean something good. We could actually create models that reflect the real world where we have a set of clothes made by different people being sold under one roof.

All these benefits result in more, better, and cheaper products for the buying public.
I'm sure the corporate and educational customers of LL would also be able to make use of such changes as well. It would be great to see SL move forward in a more substantial way than just getting more realistic looking trees or something.

Your point of view is valid and I agree for people in your position it is a big deal, however in the grand scheme of things it is still a niche area.

Putting it a different way, to fix it for the relative few there is significant risk it will get broken for the majority and there are bigger problems that need attention before this.

i understand how a proper implementation of something like this would benefit many people, but i simply dont trust ll to implement it properly.