A thread every content creator must see.

argent, i wouldn't have done it if i hadn't had personal experiences (and customers reporting riffraff to me while offline) early on when i opened my stores. i first started with the usual normal scripts/rezzing privileges on. :\ i had to reduce them over time because some bad apples just want to abuse these privileges, either plain selfishly or with the intent of disrupting my and my visitor's experience (at first only reducing rezzing to auto-return five minutes, which i witnessed still being abused, so sadly i just turned it completely off). if you yourself have no probs with such things, consider yourself blessed...

old

Old what?

Just FYI, this would break existing valid content.

What about setting texture by script? Disabling that (without texture in inventory or contents) would break existing content. Allowing it would enable a workaround for copiers. Admittedly, it adds a hurdle, so doesn't necessarily kill your idea.

No, but a tool to copy an animation played by anyone in view range wouldn't be difficult to code, starting with the standard viewer.

The good news is that this is an "exploit" in the classic sense, and can be fixed by LL. Servers simply should not take clients' word for permissions.

As far as clothing and skin copying is concerned it should effectively stop being able to reuse the original texture UUID which is a big leap forward already when it comes to doing damage-control when copied content is found.

When it comes to prims it should be possible for LL to keep existing - compiled - scripts working as they are and only change the behaviour for newly compiled scripts. I.e. either by deprecating llSetTexture in favour of a "llSetTextureFromInventory", or by compiling the llSetTexture call to a different function internally.

Having the sim perform the inventory check and doing something about llSetTexture doesn't have to happen at the same time either. Just doing the first would already actively help with body parts/clothing copying if it currently doesn't involve having to reupload the texture.

(Obviously llSetPrimitiveParams with PRIM_TEXTURE would need the same restriction for *new* scripts)

I respectfully disagree. To me, "theft" means "taking what isn't rightfully yours to take", and copyright infringement qualifies, especially in the case of what this kind of tool allows.

BTW, your argument that it's not "theft" because you're not deprived of anything is incorrect. You are deprived of your exclusive right to determine who sells your product, and at what price. This has tangible value.

It also takes lindens, practically out of your pocket.

IMHO, it's theft. Those who say it isn't are playing a semantic game, just as those who say it is. The semantic game is really unimportant; the abuse is what's important.

We all know what we're talking about here. I'm sure anyone who's had it happen to knows that it's no less emotionally devastating than the kind of theft where objects disappear as a result.

Would you call it "theft" if someone steals your real estate by fiddling the paperwork? I sure would! Doesn't matter much to me if the appropriate legal term would be different.

BTW, it used to be that there was a very significant difference: for most cases, copyright infringement was a civil matter, not a criminal one. However, for this particular case, thanks to DMCA (which I feel is not good legislation, but that's another story), it is indeed criminal, so that discrepancy disappears.

In any case, property is a "legal fiction". It exists based on laws created by humans. To say there is a significant difference between "actual property" and "intellectual property" is to say that the laws differ for the two. And they do. But that doens't mean "intellectual property" is an inappropriate term, as many websites claim.

So, if I wanted to sell an object that could change between some static list of textures but didn't want to include all the textures in the objects inventory, I wouldn't be able to do something like that any more?

Good point: scripts apply only to prims and particles. Your suggestion would be very helpful to prevent skin and clothing abuses.

Scripts can get the textures from any number of sources. Unfortunately, existing scripts could be used to sidestep this, so the "no new compiles" rule would only raise the bar a bit.

Correct, you'd be in the same situation that we already are for animations. A nuisance, but tolerable?

It would be more tolerable if it actually blocked the possibility, but it doesn't.

Dunno if it's tolerable. It seems like a pretty annoying thing to do without much benefit.

I don't see how that would keep me from uploading a new copy of anything I see, if I wanted to.

That would break so much content that it'll never happen.

Dispite my objections to Kitty's suggestion, I like her approach and think it deserves further exploration. It is vastly better for copied content to require a new UUID!

Right, but requiring it to have a new UUID means that the copies can be easily expunged, with minimal disruption on the grid and to innocents, if caught quickly enough.

That's the core idea in Kitty's post that we should try to keep alive as best we can.

With the understanding that if you already sell an object like that then it should of course stay working as it has (although the script would never be able to be updated), that would be one side-effect yesh.

There are definitely many good uses for it, but it's technically an exploit in the sense that neither the viewer or a script should be able to just specify any random UUID of a texture without actually having that texture in inventory.

Add the fact that it's become the de facto way in which copying tools go about copying and that it makes it impossible to rather easily cripple copied content and I think the balance might tilt over in favour of closing that hole.

It also doesn't prevent LL from coming up with a new way to still accomplish your example by relying on another identifier than the texture's UUID (since you have the original texture in your inventory and someone else wouldn't) but since that would likely involve more work we can probably rule it out as being a realistic alternative .

I dislike any situation where a working script stops working if recompiled.

But maybe there's a way to make this work, despite the issues. I suspect that there is.

The question is whether it raises the bar enough to actually matter. It might just.

It would change how a copybot works from:
* rez prim, set parameters, apply textures
to
* rez prim
* drop in script
* communicate texture key to script
* script applies textures and deletes itself

It wouldn't break a single thing since only newly created bytecode would result in executing the new code on the sim. Existing scripts would continue to work as they always have.

Is it a sacrifice? Yes, obviously. It's also something that's far less invasive than some of the other suggestions that are floating around.

And like I said: the change wouldn't preclude a new and different way of having textures be usable by scripts without needing them to be present in the prim's inventory.

Why not? Animations can be copied. I don't know if this viewer can do it, but it's not a complicated programming exercise.

Not without dozens of other changes in LSL, each of which would also break working content.

If you're concerned about unverified accounts, eliminate unverified accounts.

Until recompiled. And, yes, there's existing full perm scripts that change textures like this. And it wouldn't slow down ripping content.

Is that really better?

If LL gets a report that something's been illegally copied, doesn't seeing an object with a texture that they don't own tell them something? Having just the UUID lets you apply that texture to an object but it doesn't get you a copy of the texture..

edit: I'd rather they just include the texture creator in Inspect.. I've wanted that for ages.

If you can recompile the script then you (or more generally *someone*) can rewrite the script to make it work under the new restriction.

That's not the point.

Taking Rebel Hope's example: both her furniture and the copied furniture will be using the exact same textures and hunting down all assets that are a copy is virtually impossible as you know since assets are immutable and every change and "Take" results in the creation of an indepedent new asset. The best LL can do is remove the asset UUID of the original box and its contents, but that just affect copies of the original that haven't been changed in any way.

Forcing the sim to check for the existance of the texture in either the user's or script's containing prim's inventory is not only sane since the supplied simply can not be trusted, it also forces copying tools to reupload the texture rather than being able to reuse the existing ones.

In RH's case that would mean the new texture UUIDs can be removed along with the asset UUIDs and whatever assets are left over will become untextured and rather useless for resale or further distribution.

Not if I don't have the texture.

They can remove prims textured with that UUID that don't have Rebel Hope as the creator. Much simpler solution that doesn't break anything. And it won't force people to put extra copies of textures in prim contents in the future, with the associated permissions issues, and the additional opportunities this would provide for people to copy textures in-world.