"Third owner can..."
|
Add a "Third Owner can.." function to items?
Dont Know / Dont Care
1 (10.0%)
Total votes: 10
|
Amy Burton
Registered User
Join date: 14 Dec 2006
Posts: 16
|
01-31-2007 08:47
I'll try and keep this post as short as possible. As a supplier, I sell Poses and Animations mainly for Furniture stores. But as i've played in game, I know people can steal these poses/animations from furniture after they buy it from my Client. Most people (as i've seen) sell furniture from a prim to save prim-counts on parcels, meaning I would need to make the pose/animation Copy And Resell. There are only a select few big stores which sell furniture from the floor. Most of my products the "Next Owner Can" only Resell. Preventing any copying by the Third owner, but this is a real downer on my Clients' store, and a dampener on my business. My proposal is, add an option to the creators' property dialog which has: Creator can: Mod, Copy, Resell. (already here) Next Owner can: Copy, Resell. (already here) .. But add also, Other Owners can: Copy. (using copy as an example for furniture sales) This would make the Supplier>Client>Customer trail so much more stable in terms of preventing any abuse by the Third owner. (I bet i've missed something I can already do in-game to prevent this, but as i say this will be easier, if an option is added, to control it) Thanks for reading, and hope you can give feedback on this, Amy. p.s. I have put up a vote here too: http://secondlife.com/vote/vote.php?get_id=2796
|
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
|
01-31-2007 09:08
I suggested this a while back: http://secondlife.com/vote/vote.php?get_id=1026I think however that there's probably a reason why the Lindens are reluctant to make any changes to permissions. And that is that all existing objects would have to have the new permissions set to default values, which might not be what their creators wanted, and any change they made to the meaning of the existing permissions would be applied to the existing permissions on the item, which also might not be what the creators wanted. So if you add the "future owners" option, then the server has to set a default value for every existing item. To get the same functionality the server would copy the "next owner" mask to the "future owners" mask. But the problem is that the human meanings of those permissions change as a result even if the functionality doesn't, so then your business partner calls you up and says, "Hey, you know that object you gave me before the last update? I'm giving it out as a freebie because you said it was OK for all future owners to copy and transfer it."
|
Amy Burton
Registered User
Join date: 14 Dec 2006
Posts: 16
|
01-31-2007 09:21
That is a very good point indeed, then the way around it would be that no-modify objects CANNOT be tampered with at all, this includes taking stuff from its inventory.
|
Kitty Barnett
Registered User
Join date: 10 May 2006
Posts: 5,586
|
01-31-2007 20:40
From: Amy Burton As a supplier, I sell Poses and Animations mainly for Furniture stores. But as i've played in game, I know people can steal these poses/animations from furniture after they buy it from my Client. All your client has to do is set the next owner permissions on the animations to NM/C/NT or NM/NC/T depending on what they'll be selling their furniture as. The problem you're having is due to human error or plain not caring on your clients' part. If you find that someone is reselling your anims without the proper restricted next owner permissions then you should be following up on that, because they're the one who are in breach of your redistribution license, there's no fault on the "third owner", and definitely no need to break totally unrelated content like you're suggesting.
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
02-02-2007 08:23
I've suggested a general mechanism for doing this kind of thing, a "wrapper" that you can place on an object that will mask an underlying set of permissions until the object is unwrapped. Unwrapping could be set to happen on transfer, or be done explicitly by the user, or by a script. It could also require payment to *you* to break the wrapper.
For example, you could give your object with "transfer, no copy" on the wrapper and "copy, no transfer" on the object... now someone can buy it as a gift, give it to someone, and when they unwrap it they can have multiple copies. Perfect for clothes and jewelry... and the recipient can even try it on, and return it, if they don't remove the wrapper.
You could have "copy, no transfer" on the first wrapper, an automatically breaking "transfer, no copy" on the second, and "copy, no transfer" on the third. This would let you sell someone a product they could resell, but their customers couldn't, but both could make copies of it.
Put a price on the first transition, and you have an object that sells for a commision.
|
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
|
02-02-2007 08:52
From: Argent Stonecutter I've suggested a general mechanism for doing this kind of thing, a "wrapper" that you can place on an object that will mask an underlying set of permissions until the object is unwrapped. Unwrapping could be set to happen on transfer, or be done explicitly by the user, or by a script. It could also require payment to *you* to break the wrapper. I think this already can be done, "sort of" - but it's a dubious, bug-tweak type of functionality that I can understand folks not being too keen on using to protect their products.
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
02-02-2007 14:31
I think this already can be done, "sort of"
Not in any way really useful. The closest you can do to it is create a "token" that every recipient in the chain must rez-and-run or show to a vendor to get the next token or the final object, and it doesn't allow for you to sell "builder's materials" like animations, textures, scripted components (like rez-fu), or anything that needs customization for a build.
And besides...
Giving someone a coupon for a diamond isn't the same as giving them a diamond.
|
Amy Burton
Registered User
Join date: 14 Dec 2006
Posts: 16
|
02-05-2007 06:30
From: Kitty Barnett The problem you're having is due to human error or plain not caring on your clients' part. If you find that someone is reselling your anims without the proper restricted next owner permissions then you should be following up on that, because they're the one who are in breach of your redistribution license. Thanks for that, Is there any way to actually enforce this redistribution licence?
|
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
|
02-05-2007 08:31
From: Argent Stonecutter Not in any way really useful. The closest you can do to it is create a "token" that every recipient in the chain must rez-and-run or show to a vendor to get the next token or the final object, and it doesn't allow for you to sell "builder's materials" like animations, textures, scripted components (like rez-fu), or anything that needs customization for a build.
What I was actually referring to was the "tringo trick" (I only call it that because Tringo was the first item I saw in-world that used it) where you make a NT/NM object and put an NM/NT script inside it. Then you pick it up and use the Properties menu from Inventory to make it NC/NM/YT. The result is that when passed on, the object is NC/YT, until it's rezzed - whereupon Second Life remembers that it contains the NT script and propagates the permissions from it to the main object, thus making it become NC/NT. So you get an object that is transfer ok, but only until it is rezzed. The problem is, this seems a bit too much like making use of a bug to me  I would have liked to use it on my own products but I'm not sure it can be depended on. But no, sadly, I can't think of any way of doing the equivalent for builder's materials. If scripts could set permissions, I could see how it could be done, but I understand there's good reasons why they can't.
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
02-05-2007 11:05
From: Yumi Murakami What I was actually referring to was the "tringo trick" (I only call it that because Tringo was the first item I saw in-world that used it) where you make a NT/NM object and put an NM/NT script inside it. Then you pick it up and use the Properties menu from Inventory to make it NC/NM/YT. The result is that when passed on, the object is NC/YT, until it's rezzed - whereupon Second Life remembers that it contains the NT script and propagates the permissions from it to the main object, thus making it become NC/NT. So you get an object that is transfer ok, but only until it is rezzed. Yes, I know about this trick. It's kind of limited, and the bug it depends on really needs to be fixed. And while that's being done, I don't think that it should be possible to make an object NM/NC/NT, period: the SL permissions system is supposed to only allow one of "no copy" or "no transfer"... that's what Lindens have said over and over again when people complained about not being able to somehow bundle up all their copies of a no-transfer item so they could transfer it en-mass - no-copy exists to ensure that the right of first sale is preserved. Originally, you could at least pull the inconsistent components out of an object even if it was no-mod. That might break the object, but you would at least be able to transfer or copy parts of it. They recently changed that with no more explanation than it was to "prevent an exploit". Well, personally, I consider it an exploit in itself. When you set inconsistent permissions on an object, it should be marked "inconsistent". An object with inconsistent items in its inventory should be similarly tagged. And an "inconsistent" object should be "no transfer" even for the creator. This won't break existing "inconsistent" objects, but new objects will have to be made consistent.
|