[sldev] Permissions

Dale Glass dale at daleglass.net
Mon Sep 24 02:25:40 PDT 2007


On Monday 24 September 2007 11:07:00 dirk husemann wrote:
> i think that the whole permissions systems is an "honor" system at best.
> why? well, the client --- or better: a client --- will always get the
> prim coordinates as well as the texture references from the grid. with
> open source clients you cannot count on nor can you guarantee that they
> will NOT act as a "copy bot" --- with the exception of scripts, but with
> open grids/open sims that will change as well.

They don't have to.

Simply add a new flag: "Bind to domain". When set on an item, the 
originating server refuses to hand it out to one owned by somebody else. 
So an asset with my scripts would be simply forced to remain on the LL 
grid. If the script remains there, and the LL grid doesn't out the source 
to it, then it still remains safe.

> as the "DRM" debacle of the last years has shown, "DRM" never really
> works in the end --- and it always drags with it more problems
> (useability, maintainability, etc), that become a pain to interact with.

Not my personal opinion, but content providers argue that even if a perfect 
solution isn't possible, permissions should still exist, if only as a way 
of indicating the will of the author.

There is a certain sense in forcing people to bypass the system, even if 
it's very weak. If you bypassed it, you can't really argue you didn't know 
what the creator wanted.

Really, IMO, the permissions system should continue to exist. If you don't 
want to restrict your own stuff, then don't, and just release all your 
stuff as full perms. But there are a lot of people who will be really 
annoyed should it vanish completely.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/c62e047f/attachment.pgp


More information about the SLDev mailing list