Resell / Giveaway Options

You know when you like buy a set of hair and you think, damn this hair looks terrible on me, or this skin looks horrible on me. But my girl or my boy would absolutely love em! Oh no, No Transfer. Sorry you need to buy it again.

But!

What if we could inplent a NEW Option when creating an object.

( ) Resell - YOU ARE ALLOWED TO SELL THIS ON, BUT NOT GIVE AWAY.

( ) Giveaway - YOU ARE ALLOWED TO GIVE THIS AWAY BUT NOT ABLE TO RESELL IT.

Of course you can only select either or in these.

Any feedback about this? Stupid, silly, dumb?

Thanks - Andre

But then we would need it to delete all your copies when you resell/give away, otherwise it just becomes a copy/transfer item of which you can give/sell infinite amounts.
Who would want to sell something that allowed infinite copies to be sold/given away?

I think the current permission options cover all the bases, with exception in regard to textures. It's really up to the content creator what permissions are set. And for most no-trans items, you can usually find a demo to try before buying.

The current permissions system doesn't quite cover everything.
No copy/no mod/no trans would sure be nice.

For those who can't comprehend why something should be no to all 3, say I create a custom tipjar for somebody, and want them to pay for each jar they buy. No copy covers that. What happens then if it's a jar that splits the tips with the owner, and for some reason I have hardcoded the owners key to send payment to. If they give or sell that jar, they will continue to recieve the split. Hence why no copy/no trans is sometimes useful.
The linden solution is to place an empty script in the object with no trans and make the object no copy, but this is easily borked and offers no protection to items in the inventory which cannot contain inventory items themselves (scripts, textures etc).

No offense, but hardcoding the owners key would just be a bad idea. Putting llGetOwner() in the rez event would prevent this problem. But scripting tips is another forum... There may be a few legitimate reasons to have all 3 but they are very few IMHO.

That was just an example, I use notecards for getting admin names.
Even so, llGetOwner will return the key of the group if the object is deeded. Not what you want in certain circumstances.

Even if there were no valid reasons to have all 3 options off, there are no valid reasons why we shouldn't be able to do it.

I'm not even going to try arguing this one, it's pointless.

If the object is no transfer, it can't be deeded to a group so it doesn't matter anyway.

There's always a way round these things

Join the group, place the object, set the options for next owner, deed it to group. Using the permissions settings, you can stop a member of the group taking that object or you can stop them copying it, not both.
You can throw in a no copy script and make the object no transfer, but it's still a workaround.

It's not technically possible to implement this because there's no way to distinguish someone calling llGiveInventory() because they're giving someone a freebie and llGiveInventory() because someone paid L$250 three seconds ago.

No, that should not be possible even with the hacks people curently use to fake it. That violates the "right of first sale" built deliberately into the permissions system, as a fundamental principle of how permissions should work, by Linden Labs.