Texture perms viral to prims--on purpose??

Some may recognize this from experience, or from http://jira.secondlife.com/browse/SVC-1226, but I just stumbled on this, and wonder if there's something I'm doing wrong, some way to avoid the craziness, or some understanding that it's really supposed to work this way.

I've been trying to use these copy/mod/NO-TRANSFER textures I bought. It seems that a copy of the texture gets put into the object. And sometimes many, many copies--often corresponding to the number of faces the object has that are being textured, but sometimes many more than that, and sometimes just one even when multiple faces are textured with it.

This of course makes the *object* no-transfer.

If I remove all the matching texture assets from the object contents, any faces painted with that texture revert to the Default texture.

Now, I know a way to paint a prim with no-transfer textures with built-in SL facilities and a script, but is it really the intended behavior that texture *asset* permissions should be viral to the prims on which those textures merely appear? That is, would my script be violating the actual intent of the permission on those textures? Or, put another way, is this really my punishment for buying a few textures instead of making them myself?

(To me, this whole behavior seems completely insane. It would make as much sense to force a prim to be no-transfer if it's ever in the past contained a running no-transfer script. )

Yes, applying a no-transfer texture to a prim can make the prim no-transfer. That is why the vast majority of texture sellers do not restrict permissions on their textures. Restricted textures are almost inpossible to use to create something you intend to transfer to someone else, later.

Thanks, Ceera, for your reply. I certainly know now that in practice, no-transfer textures are a pain as currently implemented, but I'm asking a somewhat broader question, so I'm gonna bump this once, and try to put it differently.

If no-transfer textures worked differently, wouldn't they be a good solution to the very real risk of selling full-perm textures? If copy/mod/no-transfer textures worked *exactly* the same as full-perm except you couldn't transfer the asset itself, one could sell textures that way and everybody would win, wouldn't they?

Instead, currently, non-transferability of textures is enforced ON THE PRIM as well as the texture assets themselves. This appears to be implemented the same way no-copy textures are enforced. So maybe this is just a long-standing bug.

So I'm proposing to write a jira about this, with two big changes to the semantics of texture permissions. If people have objections to it, I'd sure like to know in discussion here before I submit and start lobbying for the jira.

The changes would be, in the absence of an overriding EULA:

All textures with Copy/Mod/No-Transfer permission would behave exactly the same as full-perm except the texture asset itself could not be transferred. That is, Transfer permission would apply only to the texture asset itself, not to prims painted with the restricted-permission texture.

All textures with Modify permission could be downloaded and changed or used in other textures and re-uploaded as a new texture with the uploader as creator. That is, Modify permission is effectively a "derivative works" license--precisely its current semantics for all other non-texture content for which modification is possible.

These are meanings that need to be expressible, and the current need to use a EULA seems to abandon the permissions system unnecessarily. And yet, some considerable effort must have gone in to creating the current approach, so maybe somebody remembers how and why it got into this totally non-intuitive state.

I agree with what you are seeking, Qie, but I don't think it is possible, the way things work in SL. Texture artists have asked LL for years for similar changes, and either have been roundly ignored, or have been told "we can't figure out any way to do that. It's a technical impossibility."

Qie, what you describe is IMHO exactly the way it should work and should have been done in the first place. When this topic has come up before, though, I believe what breaks the deal has always been the issue of retroactively changing the behavior of all those existing textures. Somewhere there are textures never intended for transfer, ever, on a prim or not, as well as textures not intended to be edited, ever. Granting more options by tweaking the permissions system sort of implies a more permissive usage license (rightly or wrongly) than the original creators may have intended, and LL has historically shied away from making those types of changes.

Assets that were protected to some extent by the permissions system probably didn't come with a EULA forbidding that which the permissions system rendered (theoretically) impossible to do anyway. You don't see usage licenses which forbid modifying objects which are sold no-mod, that's just silly on the face of it (however smart it may be in a legal sense).

I don't know the reasoning behind why it works like it does.

I hope something can be done, the edge cases would seem to be a minuscule percentage and the benefits to texture artists of your proposal would be HUGE.

---

Personally I'd like to see a more generalized enhancement of the permissions system that covers the whole spectrum of assets provided as "raw materials" to builders for products which they will then resell. The problem with furniture animations is also very real, for the same kinds of reasons that textures for builders are a problem. I realize though there are probably considerable technical hurdles blocking implementation of something like the oft-proposed "owner AFTER the next owner permissions" flags, along with subtle considerations related to retroactive implied licenses and such. It's a real problem.

Okay, well... http://jira.secondlife.com/browse/SVC-3448. Maybe it will fly.

Well, despite my doom-and-gloom comments I voted. Very well presented.

There problems with people selling no mod or no copy textures too that's
one of reason I stopped buying textures from others all together and began to make my own. They do it intentionally to protect their textures, I admit I was guilty of it at firstwith no transfer textures too because I didn't know better.
What I experienced is when I buy or receive a texture that has any restrictions I can only
see it in my inventory and can't use it any where else.
How is the jira going to fix the issue if it's intentional because the texture maker didn'twant the textures transferable?

Well, in the jira, the no-transfer Texture asset itself can't be transferred, but if the buyer applies it to a prim, the prim could be transferred. So that preserves the texture maker's market: only people who bought the no-transfer Texture could use it for building.

The one very unlikely case supported by the current behavior of permissions is if the texture maker doesn't want the buyer to be able to sell-on things made with the texture, yet wants that buyer to be able to paint as many surfaces as they want for their own use. I simply don't think any seller nor buyer wants that. I'm very sure there isn't enough call for that to justify crippling the whole texture market the way it is now, where the most common texture sales model requires the seller to impose complex EULAs that are often ignored.

It would make more sense if the very rare case were the one that had to use EULAs to supplement the permissions system.

BINGO

I do know at least one merchant, whose primary busines effort is/was selling prefab houses, who DID rely on the current behavior, so she could sell texture packs that could only be used to repair textures or to create additional matching pieces for remodeling of a prefab. But she never intended peope to be able to create resellable items with her building textures, and as far as I know, she didn't sell any of her texture packs with a EULA, as that seemed unnecessary at that time. The perms, as they worked, enforced exactly what she wanted.

There are viable cases where a builder might want to make no-trans textures available to a buyer only for that person's use, and not to create transferrable goods. A "repair package" for a complex home's textures, in case someone accidentally retextures a wall or floor, is a good case in point. But these cases are pretty rare.

I think the number of people who would benefit from your proposal will far outnumber the few who sufer from it. And these days, with copybot and other thefy methods so readily available, a builder who relies solely on their texturing and the permissins as they are now to add value to their builds would likely already have gone out of business. So, you got my vote, and we'll see what happens.