LL should do a better job in protecting IP rights, publicising offenders, and giving them harsh penalties. There needs to be an education programme about how and why such theft is wrong and illegal.

To this end, people should also be named in the Police Blotter. In RL you can find out the names of those convicted of crimes, why are they hidden in SL?

What would be the purpose of not allowing it to return parameters you can see in the edit window?

however the issue today is automated replication systems being used in an effort to destroy Secondlife.

manually recreating something complex is tedious. people that do this intentionally will be doing so in the full knowledge they are violating the SL TOS which gives LL even more ammo for permabans.

With the copyright metadata enhancements these fields could be nulled out when returned from the server to any client attempting to view them but still allow scaling and alignment.

SVC-1581 calls for an immediate disabling of the automated replication tools using existing techniques and then the copyright metadata portion is pretty darn close to SVC-701.

If this was implemented I would end up spending a lot less money in SL, because I routinely add scripts to products I buy, and calling get/set sequences to modify parameters is a pretty damn common process.

I've largely quit buying no-mod prim-based products, except for the occasional Tiny, and for similar reasons I simply won't buy no-mod clothes.

I've already had a big chunk of stuff I've bought effectively trashed when they decided to keep you from being able to remove contents from no-mod objects, so I can't use stuff I bought as props because I didn't clean them out when I had the chance.

The thought of having another chunk of my inventory (including scripts I've already been using) trashed in a vain attempt to prevent copying really doesn't thrill me at all.

And vain it is... you know that it's pretty trivial to modify either the standard client or libsl to do the same thing, without going through the manual process of sticking a script to pull in the parameters in every prim in the object. The gate you're trying to close isn't just too late, it's not the one the horses are getting out through.

libSL would be meaningless on this use case if this solution were implemented professionally.

As a matter of fact I am in favor of making the client do little except send messages to the server and if authorized receive data back rendering most of the negative aspects of the currently swiss cheese security model clients useless. That is good software engineering. message based systems managed by transaction systems with automated recovery on failed transactions.
Then new features can be rolled out without changing the client and without exposing vulnerabilities all over the place. that would also pave the way for better skin capabilities, etc.

http://blog.secondlife.com/2006/02/14/opengl-copying-and-stealing/

The client, whether LibSL or the official client, already does "little except send messages to the server and if authorized receive data back". The data it receives is, and must be, everything that is required to render the image that data represents. Which means it contains all the prim geometry and textures, all the animations and sounds. The whole thing is, and always will be, on the honor system.

The more the geeks yell out how to rip people off the faster sl will be gone.

the reason major rl retailers are not really interested in sl is because LL does not even try to combat IP theft.
So those retailers go to places where there is no user content upload capability.

Sure you guys can go there and steal content. but why don't you? Because in SL you make money off of it. we want LL to make it more difficult. and to definitely render it a clear cut TOS violation if you are proven to have uploaded any content into sl that was replicated from a legitimate creator.

people using the script kiddie tools don't know they are violating the TOS and there is no shortage of the "everything is free" open source crowd out there gleefully lying to them about it and failing to mention the tools they are selling unsuspecting customers may result in the customers being permanently banned from secondlife. In fact it should be a permanent ban for even making and then selling devices that can be used to violate the TOS.

By taking an ethical stance on these matters LL will demonstrate they are serious about SL as a commerce platform.

basically, if you do not have a use case for a capability then that capability should not be present in the code.
there is no legitimate use case for replication of copyrighted content into content created by you using lsl.

Not without destroying working content. I'm serious. You can not change LSL the way you want without breaking stuff that people are selling, right now, and making money from, right now. People who are NOT aiding or abetting theft.

"but this is about taking the capability out of the hands of non technical people. "

It is more difficult to use a script-based replication systems than the easily obtained client-side tools for doing the same thing.

"the reason major rl retailers are not really interested in sl is because LL does not even try to combat IP theft. "

We went from music companies talking about suing Apple for their "Rip, Mix, Burn" ad campaign to agreeing to sell music with no technical protections through the iTunes Store. We're not talking about some low rent "geeks" here, or unsuccessful companies, we're talking about Steve Jobs.

Here's what he said: "When we first went to talk to these record companies—you know, it was a while ago. It took us 18 months. And at first we said: None of this technology that you're talking about's gonna work. We have Ph.D.'s here, that know the stuff cold, and we don't believe it's possible to protect digital content."

The reason "major RL retailers" don't want to get into SL is there's no money for them in SL. The SL market is smaller than the desktop Linux market, and "expensive" products in SL cost about as much as a plate of General T'so and a side of egg rolls.

"render it a clear cut TOS violation if you are proven to have uploaded any content into sl that was replicated from a legitimate creator."

Make that solid, with some kind of appeal process so griefers can't abuse it to harass people, and more power to you. But that's a completely different proposal than "let's break MORE working products in exchange for a false sense of security".

• NOTICE: After writing the following and re-reading it a few times, I note it can be taken as somewhat abrasive or caustic by some, though it is not what it was meant to. I have edited it a few times to make it less so and still get My point across, but I can't really edit it too much more without loosing the point I am trying to convey. So if you are worried about potentially abrasive points of view, just skip this comment entry...

While it is a nice idea, it will also serve to cripple a good number of scripts out there...

There are a fair number of scripts that use llGetPrimitiveParams to gather the original or current specs for a prim before applying llSetPrimitiveParams or similar... Amongst these scripts are the resizers that everyone says to use as a way to make things no mod or even things like Loop Rez that is used to make prim skirts.. So you will immediately undercut yourself crippling the scripts that use such...

Reasons why NOT to cripple llGetPrimitiveParams:

Limiting llGetPrimitiveParams to a full perm only object immediately disqualifies it from anything that is copy / mod / no trans, which you can already duplicate since you have mod perms anyways... Given this what would be the point in adding additional work to the server to test whether the command is allowed to be used or not? Such would only incur additional potential lag...

Limiting it based on a copyright system will require a full re-write of the perms, otherwise you will have to limit it to prims you create AND own, otherwise such could be considered potential copyright... Given the existing perms system, you only have five bits of data to test against... Owner, Creator, and the three perms... Assuming that you would want to allow others to call llGetPrimitiveParams for things like resizers, and such, that means we are now down to the perms again as owner and creator wouldn't match if someone made a skirt or similar and sold it... And if the mod right is checked then what is the point in stopping the use of a scripting command that does exactly what can be done by hand anyways?

Side note: Re-writing the perms system means that ALL existing content has to be adapted to the new perms... Stop and figure out how many objects are in existence, both in world and in everyone's inventory... I know I have roughly 27,500 items in My inventory... Willing to leave the perms on them to the system's best guess if they re-write it, versus what the original maker wanted for them? Personally I will take being able to control my own creations... As it is, I already use scripts with internal protections, such as limiting what can be added to the object, whether or not it has to have Me as the creator or such.. Even these have thier limitations as others have pointed out, but they are measures I have taken to protect My own work instead of asking others to do My job...

Any crippling of commands such as llGetPrimitiveParams is just pointless. It will only serve to negatively impact both development and long term performance of Second Life. By attempting to limit the command a good deal of development with LSL will be snuffed out before it goes much further. Not to mention the additional load on servers. Even without the use of llGetPrimitiveParams there are SEVERAL ways to copy items from SL. Both inworld and out... Unless you were to totally remove all of them, which can't be done, as the data can still be interecepted on the end users comps, unless you want to confine them to premade systems, such as XBox 360, PSP3, or similar, and take away the ability for all users to build and upload content, but wouldn't such defeat the whole idea behind SL?

I know I have rambled, but it just frustrates Me when I see people who cry wolf and want to cripple things that have a good number of legitmate uses that would suffer by crippling them just because it doesn't jive with their view on things... Hate being cynical, but what ever happened to looking after your own work, instead of asking someone else to take care of your work for you? It's bad enough we keep letting our governments take away our freedoms and rights, and become the real parents to our children... Now you want the people who gave you freedom once again to take it away from you? Sorry... Sheeple can go play games, and leave the simulations to individuals...

Want to protect your work from things like LSL based copiers? Then take an active role in hunting down copy cats, and abuse reporting them... Think you are the only one capable of comming up with an idea? Think again... There are a number of ways to build pretty much everything in SL, as well as write the scripts... In short, quit resting on your laurels just because you hit it off with one or more good products... Get out and actually use the brain you were given... Start creating the next top product, and keep your eye out for people that have outright ripped your work without permission and tried to resell prim for prim duplicates with little to no original effort put into it. Get out there, produce quality products, get them known by people, and make people want to come to you for them instead of your competition...

I leave you with this bit of wisdom once told to Me...

Imitation is the sincerest form of flattery... ( http://www.bartleby.com/59/3/imitationist.html )

PS: Before you complain to Me about My little rant, know this... I have already had some of My work duplicated by such means, and I took it in stride, discussed it with the one doing the copying, and came to terms with them, all without having to ask for someone to limit something, or such... It is amazing what can be done using your brain and dealing with problems yourself, instead of running to the first authority figure you can find and asking them to strip away what you feel is the problem, instead of confronting it yourself, and speaking to the one who wronged you... Guess the sheeple want the government to spoon feed them the world already chewed and digested...

Limiting llGetPrimitiveParams is stupid because there are other faster and more versatile ways of stealing content that can be done entirely client side with total disregard of the permissions system or ownership.

If you think of SL like an airport, and TSA being security. Restricting llGetPrimitiveParams would be like not allowing nail clippers but meanwhile allowing fully automatic weapons and bombs in the form of copybot* and various other hacked clients. The problem is you can't stop hacked clients (not without Trusted Computing).

What we have at the root of this is a social problem and no technical solutions will give a satisfactory or lasting result. The solution must be social first.

*When I say copybot, i mean the original, not the scripted crap that is being passed off as copybot.

Your suggestion #1 will break a great deal of content already existing in SL, including content I've written.

Here's how the system works now:

Any script running in any object, regardless of the perms, has the ability to get and set primitive parameters. The permissions system prevents any person from putting a script into any object that they do not have modify rights on. This means that if you can't modify an object normally through the UI, then you can't use a llGetPrimitiveParams() script to get all of the params. Conversely, if you can modify the object, then you can add a script to it to get the primitive params. You could just as easily read off the primitive params right from in the UI manually.

The bottom line: if you don't want your customers to be able to see (and presumably copy) the primitive parameters, don't distribute the object as modifiable. If you need to give people the ability to resize the object, then include a script with a dialog that does the resizing for them. I believe Jeffrey Gomez wrote a script to make this kind of thing easy for content creators.

A huge number of scripts already existing in SL depend on the fact that scripts placed in an object before the object became no-modify (when transferred to the buyer) can still see and modify primitive parameters. As people have said above, you cannot implement your suggestion #1 without breaking a great deal of content across SL and destroying an entire segment of the scripting economy.

And from Cory's blog: "...OpenGL must have access to the geometry, textures, lights, and transforms."

You also seem to have misunderstood Cory's post. "Some of that" refers to "law, culture, and community"... most explicitly not "technology".

I will, in addition, note that there is nothing in the iTunes software that prevents one from writing an Applescript to burn that track to a CD and re-rip it, in a lossless format, and if it were available from EMI or any number of independent artists it wouldn't even require that much work to get the ability to copy it.

I have routinely burned and re-ripped every track I have purchased from iTunes, and yet I have passed precisely zero copies of them on to other people. Why is that? Perhaps it has something to do with 'law, culture, and community'? It certainly has nothing to do with technology.

I'm generally not in favor of further complicating the permissions system, but I'd like to hear what Ann Otoole and others think about this idea.

I don't like having to pay ransom for extra scripts to overcome the poorly thought out permissions system in Secondlife.
The argument can be made that making the permissions system more robust and scalable to support Linden Lab's responsibilities for Safe Harbor status under DMCA will result in more code running. The fact is more code will be required. There is no way around it.

The underlying thrust is to make it difficult to replicate copyrighted content inside of SL. In addition the people who don't care about laws need to have no option to say "LL allows it" or "I didn't know it was copyrighted", etc. Thus once someone is identified as a repeat offender they can simply be removed from SL. When they are removed all traces of the stolen content must also be removed. This includes the deletion of textures that were stolen. People that bought stolen skins will have to suffer the cost of replacing them with legitimate skins. There are enough high quality open source skins available in SL for free so there is no legitimate argument against it.

There are additional ideas being expressed for such permissions as number of allowed transfers, etc. Lots of good ideas but the overall effort remains splintered and subjected to verbal (or textual maybe?) abuse by people resisting a move of SL into a more responsible business space.

When I said you appeared to misunderstand me, I meant that you appeared to believe that I was taking a position that I did not intend to express. I apologize for leading you to that conclusion and I hope I have explained myself better.

When I said you appeared to misunderstand Cory, that is because my understanding of the text you quoted did not appear to support your position. If my own understanding of his comment was faulty, I am certainly willing to believe I was mistaken.

Ann Otoole:

I do not believe that someone using a cloning script to copy a product in SL is in any position to plead ignorance, and if Linden Labs is unwilling to sufficiently sanction people who abuse the technical limitations of this (and any other) rights system under the current scheme, I have serious doubts as to whether they would exert any greater effort to apply the force of "law, culture, and community" after implementing your scheme.

The real problem is not the technical limitations of rights management schemes, the problem is Linden Labs inability to provide the necessary degree of negative reinforcement to solve your problem.

I am not "resisting the move of SL into a more responsible business space", I am resisting a change that will not improve the ability of creators and businesses to operate in SL, but will rather decrease it. The change that is required to solve the problem you're addressing is not technical, it is a matter of policy. The current technology and terms of service would work for you if Linden Labs chose to make them work for you. If they don't, no technical tweaks will fix the problem.

Just a note: the script I mentioned is free and open source.

"There are additional ideas being expressed for such permissions as number of allowed transfers, etc. Lots of good ideas but the overall effort remains splintered and subjected to verbal (or textual maybe?) abuse by people resisting a move of SL into a more responsible business space."

Remember, we're getting defensive because what you suggested will break content we already have deployed in SL. It's no surprise that we'll try to avoid letting that happen. It's not that we're against IP, not by any means. I depend on IP rights in SL for a good portion of my income. I'm not suggesting not to make changes that help business in SL... I'm just trying to avoid a change that will destroy business already being done.

I'm not sure what you're getting at about megaprims. Havok 4 final will explicitly support megaprims up to 256 meters in size, and already supports megaprims better than Havok 1.

This puts the onus on the creator to rez products and set the new permissions and then repackage them.
A pain to be sure but not much different than how we are already having to make monthly checks for flags being mysteriously changed during server side updates. This would take me a couple of days to complete but would be a welcome task if it means content theft is more limited to use of external tools in clear violation of the SL TOS.

And Ann, since you ignored My citations on legal uses of the llGetPrimitiveCommands on SLX here are a few, with direct links for you to examine:

Prim u-Stor:
http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=171134
Allows you to back up your creations to an offworld database, then restore them at a later time should SL bork your inventory.

!Meta Elemental Multiform Craft: http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=159032
Uses llGetPrimitiveParams to allow you to change between different modes / shapes. Without the use of llGetPrimitiveParams this would not be entirely possible.

Morf Engine:
Developed by Pale Spectre this engine script set allows others to build vehicles which function like the Elemental, at present I do not have an existing SL link for it, but do have a copy of it in My inventory, that is used as part of existing builds that will be released.

On a side note to all... What of people who desire to use scripts such as those provided by Xcite, Sensations or others? This issue is far more reaching then just a single LSL command, as thier are legitmate reasons for using mod perms but at the same side using them does open up potential for abuse as is true in any system of checks and balances.

I have proposed the following at SLX as well as a few other places and aside from some not wanting to take part in INTELLIGENT discussion as they are so wrapped up in one specific way of fixing they are blind to others, what of this potential suggestion:

When a script runs for the first time in a user's login session that uses llGetPrimitiveParams, a dialog, that is different in color and size from the regular ones popups up with an advisory on the use of llGetPrimitiveParams, something along the lines of "This script contains functions which can be potentially misused. Note that your clicking Okay below will be logged and recorded as certification that you will honor the SL terms of service and international copyright laws in your use of this script. Failure to do so will result in legal prosecution..." Perhaps something in red and about the size of the new Debit Perms dialog?

llSet(Primitive|Object)Permissions( [PRIM_COLOR, ALL_SIDES, PERM_MOD, PRIM_TEXTURE, ALL_SIDES, PERM_NONE, PRIM_SIZE, PERM_ALL,PRIM_DESCRIPTION, PERM_NONE,...] );

Defaults would be set to make this transparent and the client UI could present a simplified version addition to the existing with one or two reasonable switches. The script itself could handle the finer granularity and the call would only work for the creator of the object/primitive. It would also open up a market of sorts for permissions scripting. It occurs to me, as another beneficial example, that this would allow branding, in that, one could burn the company logo on one side of one prim while allowing the user to texture and color the other sides to their liking.

I appreciate that I don't have the detailed knowledge of the SL server/client required to present a more thorough implementation or even to judge the feasibility for this concept. (I will offer, however, that I am a professional software developer, for the record.) Perhaps this would be too onerous to implement in any practical way with the way the protocols are currently designed. Traffic between the server and client being an obvious possible problem. It does however, conceptually offer a seamless migration and opens the door for content creators to have much more control over protecting their work so I thought I would offer up the notion. Perhaps also, it has been mentioned and dropped before and my apologies for repeating if so.

I would just like to add the I have been thinking about legitimate llGetPrimitiveParams use cases for a few days now and I really can't think of one other then copying prims and objects. Using it to record state, as was put forth earlier in this thread, is just a bad idea in my humble opinion. Granted, since there are no real good ways to persist data inside SL, this is a problem, however using a prim to maintain state is equally lame and prone to misuse. I appreciate that people do do it however. For that use, all one need do is put the prim in a known state first and carry on from there. That is what I would do regardless. A saner option is a small script and llMessageLinked to record the state of an object or object params.

• Modifying a prim's current parameters dynamically. For example, reading a prim's current slice, cut, twist, texture, alpha, color, whatever, and then changing it.

• Modifying only one element of a multi-value parameter, such as lighting or flexi.

• Tracking external changes to the prim's own state.

• Adding dynamic behavior to purchased products.
  • Avatar attachments
  • Furniture and poseballs
  • Vehicles

Storing the data away somewhere and blithely writing it out means that the internal state of the object will change from the actual state. This is basic database design here: only store data in one place. If you don't want your customers changing the prims in the object through the editor, make your prims no-mod (and the original problem never comes up). If you don't make them no-mod and the customer changes them behind your back then when your script runs it will trash their changes. That's just bad design.

Given the small number of cases this blanket proposal would affect, I feel I have to support it for the greater protection it offers the creator. I personally have shied away from putting my real business efforts and talents into SL because of the gross shortcomings of the current protective measures available to creators. I think this proposal takes a step in the right direction and yes, would hinder a small number of products, but for the greater good I think. A more granular permission system would mitigate this in the end and put the protective measures in the hands of the creator where it belongs. Even if it simply comes down to another bit for resize. I would also like to add that regarding a point you made earlier in this thread about not buying no mod products at all, I feel very much the same way and it pains me to sell anything no mod and I rarely buy anything no mod. I can paint my own RL car can't I? With a toothbrush if I choose. However a more granular system would allow people to sell "no mod" items that did allow certain specific mod permissions and would possibly make those products usable to you again for your purposes while protecting the creators efforts.

BTW, thanks to all for the debate. It's good to hear all sides of the issue. I might even change my mind cheers!

And it's not a matter of "using a prim as a database", the simulator is a database, the prim is a row in a table in that database. Something like:

TABLE prims (
id uuid primary key;
scale vector;
name varchar;
desc varchar;
...
);

Maintaining a second copy of part of the data in that row denormalizes the database, and while there are occasionally good reasons for it, "not using the prim as a database" isn't one of them.

And this proposal does not provide any additional protection to the creator. Seriously, it doesn't. It provides the illusion of protection. We've already had enough changes made in SL to provide the illusion of protection without actually doing anything useful as it is... for example, you can't just read off the position of objects you don't own any more... you have to call llSensor() and read them off that way, which is asinine. It's like fighting off barbarians by putting a sign up saying "you must be nine feet tall to storm this castle".

If the lack of the illusion of protection has been keeping you out of the market, I'm sorry to hear that... but it's never going to be more than an illusion. Maybe this will encourage you: I've put my three most popular scripts out as open source. They're still my top sellers. I've had a grand total of one person throw a hissy-cow about not going along with the moderate requirements of my license when requested.

As for my staying out of the market, what I mean by that is I have a hard time taking SL seriously enough to invest the full time and effort that creating a serious and extensive product entails. I've decided not sell anything that handles money for instance. For myself, I write stuff that does because I am willing to take that risk, but I won't sell that stuff to anyone else because I know what lies beneath it and I don't want to take that responsibility on their behalf. For me the measures in place don't make the risk worthwhile. Just my personal position. In the real world I have all kinds of tools at my disposal to protect my work, to protect the work of my clients and employers and to protect the assets of their and my customers. These types of tools are simply not available in SL and so I am not really interested in investing the weeks and months into designing and implementing an extensive product if that product's ability to operate is not at least somewhat defensible with a solid layer of tools and protocols beneath. This particular issue is but one small aspect of those lack of tools for me. That said, I also realize that a dedicated person can break those tools in any world, regardless of my best efforts, but I do feel better knowing that I and the frameworks I use have at least done their very best to prevent or curtail such a breach.

As for the normalization of the data, I think that could be accomplished without breaking any acceptable relational db design practice. Without knowing the actual schema in place on the server side I hesitate to offer anything but a wildly thrown dart but it seems to me a simple long int bitmap added to the table above would suffice to encapsulate read perms. There is not much point talking about that however since I certainly don't have access to the schema so I can't really make any valid contribution in that regard.

Anyway, you have certainly given me something to chew on. cheers!

The most likely bug is that the owner of the object modifies it, and then that modification is undone by the script. This is actually a fairly common bug in scripted objects, and one that I go to some effort to avoid, myself. The result of this is that I use llGetPrimitiveParams quite a lot in my own code... and I would expect that any developer who wishes to produce the best possible product would do the same. It's just so much more powerful to allow a customer the full capabilities of the SL object editor than to restrict them to just those modifications that one cares to take the time to implement.

Using llGetPrimitiveParams() is not an exploit, as has been explained above numerous times.

Let's try to keep it civil, rather than slinging veiled insults at each other. This thread is quickly turning into a flamewar.

Let's toss out some theoreticals and see if something can rise up that satisfies all interested parties.

The prime objection by knowledgeable scripters is attempts to cobble existing lsl functionality. One negative factor is adding execution time to function calls.

Assume for a moment that a greatly improved set of permissions were deployed.
Perhaps the script execution system could check the permissions prior to allowing the script involved to commence execution and deny execution if the object permissions denied certain function calls based on the permission rules. There would be a minor delay before execution. If the permissions were allowable then the script could freely execute as originally designed.

The bigger problem is that I really don't think LL cares about content theft. We see no participation from LL on these matters while LL allows reapeat offenders to openly operate across SL.
I would love to see LL step up and state they are interested or not interested in these matters. If not interested.. I.e.; we are wasting our time.. then we can publish it in the media for all to see and make sure potential new creators know they are wasting their time. To tell people to keep making more and better new stuff to be ripped off is absurd.

In fact using llGetPrimitiveParams to replicate prims is not really that efficient or quick, you have to place the script in one prim, create a new prim, put a receiver script in the new prim, initiate the replication, then repeat all that for the rest of the prims. Then you have to figure out someway to rip the textures, and since VWR-1919 there is no easy way to do that, then you have to texture all the prims and then link them all together. Probably not that much faster than using the UI. And it can never be used to copy scuplted prims since llGetPrimitiveParams is incapable of getting the scuplt map UUID without full perms. It is way easier to download a copybot viewer and truly copy the object. This proposal should also include removing the information from the UI along with llGetPrimitiveParams to be really thorough. Though, IMO you need something like Lex's resize permission instead of breaking content in this way. And the enhanced permissions Ann mentions and is similarly proposed in SVC-1656 are good ideas also.

And of course LL cares about content theft, the problem is just reporting places and avatars in things like SVC-676 is not giving them anything they can work with. The creators have to submit DMCA reports, if you know someone is using copybot or replicating prims report them to LL.

Things like watermarks, digital signatures, copyrights, enhanced permissions, IMO are the right way to go.

LL approves and supports replication systems while at the same suggesting the creators of these things warn customers of potential TOS violations.
of course the creators of replicators gleefully ignore this "suggestion" and sell then to unsuspecting noobs that then clone shoes and other things which results in the overhead of DMCA activities.

There is a cost to this activity in the form of staff overhead to deal with DMCA filings. and the worse it gets the sooner we will all be paying extra to cover the overhead.

watermarks are useless. so are digital signatures. too easy to simply screenshot and thus remove that data.

copyright metadata fields are mandatory. and automation to leverage copyright metadata becomes possible.

And it is the same way with a lot of replications, you can copy a software CD for backup purposes, but then giving or selling that backup to someone else violates your license for that software.

And I have been to the Mono Office Hours where Babbage and Scouse have said they prefer not to add to or enhance LSL but would rather incorporate other languages and C# is always the first brought up.

I am also all for creators filing DMCA report when they think their content has been stolen.

1. This is not just a matter of "this does not appeal to me". This is a proposal that would break scripts that I use every day, and break content that people are currently selling and that is NOT being used to rip anyone off. Breaking content is a bigger problem than ripoffs, because you can't sell broken content at all... instead of losing (say) 50% of your sales to copycats, you lose 100% of your sales. This proposal (not the alternatives, the one that this Jira is for) will destroy businesses.

2. Neither I nor (I believe) Harleen have argued against Lex's alternate proposal or the other alternate proposals that have been discussed here. Have you noticed that? Apparently not.

3. I am not attempting to get you to remove your bleeding vote.

If you or Lex or anyone else want to take the alternate proposals here and create a new JIRA entry that describes a proposal that doesn't involve breaking working content in SL. you might be surprised who votes for it. But this JIRA entry is for limiting llGetPrimitiveParams, not for creating a new "semi mod" permission.

B) I have not asked that you pay attention to me. I have not said one word on how people should vote. Votes are, at best, something to indicate to Linden Labs what people care about, and clearly people care about this issue.

I have asked that when you do comment in response to me, or to Harleen, that your comments reflect what we're actually saying, in context. It's not your conclusions that are the issue, it's your characterization of the people who don't agree with you. Using terms like "hallucinations" and referring to someone as a "chaos programmer shoplifter" without the slightest provocation are a long way from merely drawing separate conclusions.

The only solution to the problem will be closed source clients run on an encrypted link.
Since this is about as likely as the wealthy and powerful of the planet suddenly deciding to redistribute the wealth to ensure the needy of the world are taken care of I see little point in continuing the campaign for author rights enhancements in Secondlife.

Simply put: If LL cared they would have provided the long ago promised enhanced metadata for IP protection.

But LL doesn't care.

So why waste any further time on it?

the issue here is that even if the scale flag were added the new copybot would still have access to the data.

there is no solution to this problem short of closed source client and encrypted data stream.

The person to take this matter up with will be whoever is selected as the next CEO of LL.
that will be the only person who can do something about the problem and do so by issuing an order to deal with it the hard way.

pigs may be flying on hoverboards through a frozen hell by then.

we all want theft stopped but only LL can do it and only one way and that way is not on the table.

200 people voted for voice out of 6 million. we got voice.

1051 people want more groups. we are told groups will not be touched.

do the math.

There are no feature requests to integrate facebook with SL yet it is being pushed and i suspect facebook "friends" will be added to search relevance forcing even more gaming activities to protect your business interests. next should be blog integration with SL and blog feeds count as inbound links. sl is being turned into a popularity contest. damn what people need search for.. to find things.. its all going to be about finding a select few people and providing exposure only to those people whom LL likes and promotes.

what is wanted by the most people is not addressed. sometimes because it just isn't possible with: technology in place, talent in place, policy in place, odd ideas by people at LL that do not use SL at all in respect to what they want sl to be, etc.

only an executive order will bring about change.

and then, if the Tao is retained, only if someone at LL thinks it is important AND they are not directed to work on something else (which really does happen at LL despite the "tao", slurban myths about tasking priorities, etc.)

/rant

Have you made a JIRA proposal for a closed client with anti-tampering software? What's the number?

If you want to see the suggestions in this discussion treated seriously, I sincerely believe that this would be best accomplished if you were to open a NEW entry, or multiple entries if appropriate, for the ones you are actually advocating, add them as "related" links here, and let this one (which is not about these other suggestions, no matter how desirable they are) be closed.

I await your new proposals with great interest.

I'm not going to hijack this proposal because I do not believe that this is appropriate behavior. When I have in the past succumbed to the temptation to do what you are asking me to do, the results have not been positive, and I've learned better.

As an aside, I don't believe sub-tasks are intended for the purpose you're suggesting. They are not for alternative proposals, they are for, as the name says, sub-tasks. Steps in implementing the proposal that can be taken independently. Using them rather than editing the proposal directly is still hijacking it.

We'll leave this as "Won't Finish", please don't reopen it – continued disruptive accounts which waste time & energy for others will have their Issue Tracker posting privileges removed.