Texture Permission Reform Needed in the worst way

I read it differently.

I am builder and buy textures from artists
In order to be able to sell my buildings, the textures needs to be full permissions.

When I aply a texture on my building and sell the building, the buyer cannot take the texture out.

No harm done.

Now the catch, I am honest and respect the creator's copyrights. But, since they are full perm textures, who pervents me from just giving the textures to anyone that passes through? I believe that is the issue the TS has a problem with.

So many people try to talk you into giving them the textures as well.
"I accidentally messed up the building, can you send me the textures so I can restore it?"
Any idea how many try that?
My buildings are copy/no trans, so I always write back, delete your build and rezz a new copy.

I think technically it would be damn hard to make it so, that I as builder cannot transfer your textures to someone else, but can transfer them when applied on a prim.

I hope that changes for you, I don't need transfer permissions on individual textures, I need them to be transferable if they are on my builds.

Sorry to necro this thread, but I just noticed it here, and I think there's some confusion about the objective of the jira, and the way things work right now. I don't think this is just a viewer-side issue. If one paints a no-transfer texture on a prim, that texture actually gets embedded in the prim. In fact, a separate asset pointer is created in the prim for each face that's painted with the texture. (They're just pointers--they all have the same UUID. So it's not an extra asset, just more crap that has to be persisted on the sim.) Then if those texture contents are removed--even by script--the faces revert to plywood. So that's how it works now.

On the other hand, the standard viewer contains a way to learn the UUID of no-transfer textures, so one can easily enough paint the prim with a script without getting the embedded asset. So, indeed, maybe a viewer change could do what's needed here. But it would still leave the behavior that a prim painted with that texture will "go plywood" if the texture is also in the contents of the prim and is removed.

Until recently, I'd never worked with no-transfer textures, so it was a surprise, and struck me first as incredibly inelegant. But then I got to thinking about it, and concluded that only the texture asset type has this bizarre permissions semantics, such that "transfer" doesn't just refer to the asset itself but to prims merely painted with it.

But it's more than just weird. It makes texture reselling the most IP-vulnerable business on the grid, simply because they can't use no-transfer to mean what it means with every other asset type. If instead textures worked the same as every other asset type such that the no-transfer permission applied only to the texture asset itself, textures could be sold no-transfer, builders could use those textures on their products, and everybody's happy--without resorting to the (somewhat legally tenuous) EULAs that accompany full-perm textures. The jira's main beneficiaries would be texture resellers who could for once actually protect the products they sell, using the built-in permission system.

The jira would indeed defeat those very rare cases where the desired semantics really is that the asset recipient should be able to paint any surface with the texture but not be able to transfer the resulting prims. But this is such an unusual practice that it's just silly to support it at the expense of all mainline texture businesses.