Should people be allowed to "rip" scripts?

woo.

*adds "Creativity Facist" to his resume*

I complain to the left people.

I disagree with the above comment. If I purchase a ticket to a theme park, I am allowed to ride the rides, not take a roller coaster home with me at the end of the day.

If you come to my themepark in Second Life called SimCast, you are purchasing equipment to experience our combat system. The scripts inside those objects are not yours to decompile at will. They are the very thing that allows us to create such an atmosphere for all players to enjoy!

Let me ask you something. Do you drink Coca Cola products? You probably do. Have you written them an e-mail asking for the formula for that product because you bought a single can of soda?

Blah blah blah blah blah.....

Again, the issue isn't being able to decompile your scripts. We can't do that anyway, as long as you have set them as no-modify.

The issue is whether I should be able to remove your script from your backpack and replace it with another; or to put the script in a new backpack (or magic wand or sword or whatever) and keep the functionality with a new "look".

From what you've said about your security efforts with your system, Prong, it would appear that I can currently remove the scripts from my simcast backpack but I'll simply be left with a useless set of scripts and a non-functioning backpack.

From my personal perspective, what I do is ask: I've done some absolutely outrageous things to the code of the uberscripters of SL by throwing them into watermelon-related items and rescuing them out of their UTTERLY UNWATERMELONY FORMER SHELLS, but I ask beforehand. Some of those scripters have posted in this thread.

My motives go far beyond any singular financial transaction. Even if I buy something cool, I wanna get to know the person who made it, and hopefully find out that they're good to get along with. I wanna know their inspiration, what went into making the script, and maybe swap some jokes.

I've made some great new friends this way, so hey, win-win!

But, that's just me.

Though I'm inclined to agree with you, this is yet another horrible analogy in a thread full of abominable analogies. The circumstance is nothing like a can of coke, nor a theme park, nor anything else I've yet heard mentioned.

In the end, it comes down to two things: the right of first sale, and the right to reverse engineer. Both of these are rights granted to consumers by the courts or by the legislature. Let us first consider first sale as it applies to people harvesting scripts for personal use: upon selling an item, you lose the right to dictate the use of that item. Should the user wish to resell the original item, he is free to do so. Should he wish to destroy the item, he is also free to do so. If he wishes to use the item in a manner that was unintended by its creators, he is still free to do so. In a previous discussion on this subject, someone cited software as proof that first sale is not a definite right. However, that raises a debate about the difference between selling and licensing which is so complex that it cannot be easily distilled into a short response. In the end, software manufacturers assert that they're not selling software, but rather a license to use it. The courts have previously ruled that first sale is still applicable since the licensing agreement is not available at the time of purchase (Softman v. Adobe). The fact that LL allows for someone to make an object non-transferrable suggests that they do not fully embrace the concept of first-sale, which even further complicates the debate. In the end, I'm not sure which way I side on the subject. So long as users are purchasing the scripts at fair market value and not reselling the newly combined item and script, then it's an act which does not harm the creator of the script. If that same person were making unauthorized copies of the script, putting them in his car, and claiming credit for the work, then it's not kosher. It is definitely not a black and white issue.

As for the complaints that users are reverse-engineering their scripts used in multi-player games, I suggest that people read the relevant information regarding the legality of reverse-engineering. In the end, despite some infamous and egregiously abusive lawsuits that were lacking in merit (e.g. Blizzard v. BNETD), it is my opinion that the statutes actually protect the behavior being described, and that the finding in Blizzard v. BNETD was in error. In the end, you have a very simple means to prevent cheating in your games: write your code to specifically account for this behavior, and ban known offenders. I suggest you take advantage of this opportunity, as it sounds highly unlikely that they will be implementing any permissions changes until CC is implemented. Even assuming the Lindens were somehow persuaded to your side of the argument, which I find unlikely.

That would be correct. If our scripts are removed from the objects we sell them in and placed in another object, the item will cease to function. This is done for two major reasons.

1) If moving sripts were allowed, anyone could simply slip a script into the new object to listen for our game channels being used. This in itself would upset the even battlefield we want to create and provide to the community for all to enjoy.

2) By allowing scripts to be placed into any user created object, you break away from a solid theme and enter the world of bananna swords, trash can helms, and space suits. We want to provide an immersive environment, and have worked hard to provide matching content.

Without enforcing the above conditions, why even bother to keep in theme at all? All games would look the same and play the same. It would produce even more uneven battlefields like Rausch and Jessie all over again.

It is sad that we have to impose these restrictions on our player community, but what other choices are we really left with? With all the freedoms players have in Second Life, how do game developers within Second Life create something truely unique without imposing restrictions?

We provide high quality weapons and armor that serves two purposes. They look great and match our theme, and they also provide functionality in our game. When the item finally serves its purpose, the player can delete the scripts in the object and keep the high quality shell for display.

If a customer chooses to tamper with an active game object, that choice will void our warranty and render the item useless for game play. The customer will forfeit all future upgrades on that component and will not be issued a refund.

I can honestly say that for every customer who calls this unfair, there are 10 other customers that appreciate our approach to this subject......

Just got up, calmer and more refreshed - I can now get back on-thread

Un, you speak alot of sense, as do all of you. Its obvious that this is not a simple black and whilte issue, and depends upon the context of the product in question (I would never compare my simple gadget scripts with the amazing work done by the Simcast crew and other game developers of that kind of gaming experience).

One thing I wish I'd said last night, instead of that silly line meant as a joke to Yashu about negotiating a fee for my scripts, and is only relevant to my sphere of products, is that a few times a fellow resident has seen and used a product of mine, and suggeted a groovy variation or alteration, and I have made a new version based on that players suggestion. I have always given them a free copy as a thanks for their suggestion/ideas (as well as copies of other related items).

In this particular case, does this not counter the argument that a customer should be able to put my scripts into another 'shell'? I'm basically doing the work for them and they pay nothing, yet get exactly what they want.

I don't see anybody here changing their stance, and that is good. If we all thought the same, SL would be boring indeed

I just wish I hadnt gone on the defence last night with Yashu and veered off the discussion base - no hard feelings dude.

I don't really have a dog in this fight, but there is one thing I wonder. This is obviously an important topic for developers of in-world games, since hacking their stuff can compromise the game.

But are there any non-game script developers who have experienced actual problems due to users hacking their non-modifiable scripts? Or is this really just a problem for games?

While this is a valid concern, I usually wear my furry avatar when I play games, and since most helmets and such are moddled for regular human heads and bodies, I find it quite useful to be able to remove scripts and place them in objects I've created that have a close facsimile to the original.

Not everyone removes scripts to cheat the game or ruin the immersion. Some of us *have* to remove scripts and place them in other things in order to enjoy the game along with everyone else. I'm probably one of the 1 out of 10, but that doesn't make my complaint/concern less valid.

Does the existing permission system prevent this... if I want you to be able to resell the original object? In other words, can I set the script no-resell, but allow you to resell the object it's in? I honestly don't know the answer, and I'd like to know. I suspect that if you could resell the original, you would also be able to resell your modified item. This is at the heart of the issue for me. I'd prefer to let people resell or give away my items-- intact. I like to buy gifts for friends and if someone wants to buy one of my items as a gift, I'd like them to be able to do that.

And this doesn't address the other central issue. Suppose I make a fountain script with a particle pattern that you think is just right... but you don't like my fountain base design. You buy my fountain, then make your own fountain base and put it on your land, with my script in it. Someone wanders by, admires your fountain, and rates you through the fountain. Who gets the rate? Never mind the rating income -- I'd just as soon rates were done away with as a source of income, personally. But whose name pops up when the visitor tries to rate the fountain? Yours. Is anyone likely to come to me to buy a similar fountain? Or even send me a note saying, "Hey, nice fountain script!" Not likely.

Does that seem reasonable to you?

Perhaps part of the problem is that the "creator" field only lists the name of the person who built the prims of the object, rather than giving credit to all the contributors (scripts, textures, notecards, etc.). After all, in the above example, both prim builder and scripter are contributing to the object, and possibly yet another creator who made the texture, and another who wrote a poem that the fountain hands out when clicked on.

But then suppose the Creator info is altered to display all contributors, and someone takes my fountain script, unbeknownst to me, and installs it in some rather explicit tantric staturary on a mature build. I don't object to such statuary existing, but I don't want to be part of such a build quite that... intimately. Leads to people getting rather misleading ideas about my personality. So I'd prefer to be able to choose to sell my items non-modifiable. Others may choose not to buy them, preferring modifiable items, of course. But I really think both buyer and seller should have some choice in this matter, without having to resort to complex scripts that may introduce bugs at the next SL upgrade.

neko

Our game tags have to be attached to the nose of the avatar. Mosy Furrys have no problem reattaching their heads to another location to accomidate our combat system requirements. We will also be releasing weapons and armor in various sizes to provide the most variety for a player. This will not make everyone happy, but it will certainly help.

very well put neko.

Everyone has their own creativity, different skills and different motivations for being in SL, and the current script permissions are not compatible with some of them.

There should be a standard (i.e., built into LL) "off" state that supresses sensors, timers, particles and lights. Then you could catch the state change and change the appearance of the item when it is on and off, using visual cues so that onlookers would know that your item is "off" and that it can be turned "on" somehow. (by touch, sitting on it, whatever).

Scripters CAN do this now. But I think it should be built into LL that owners can turn things off, and scripters can define what happens when they go on and off. The "off" limitations would be like attach limitations are now. (Certain things don't work when something is attached to an avatar. Scripters know this and cope.)

Buster

i read this thread again. i agree that some scripting projects, like darklife etc need protection for their scripts to prevent players from cheating. there could be a measure that if players break the wrapper, that they can no longer use the item with the game. perhaps players can then speak with a game rep to license their software or provide a a new 3d model/texture for the game in exchange for this permission.

i really like what tiger is saying though. that i can break the wrapper, lose copying or transfering rights and be able to use your script in my own product for personal use. scripters, please think of it this of it this way:
-you made an amazing car or furniture script - but your item is not aesthically to my taste.
-i make the item exactly to my taste - but i cannot script.

all i want to do is buy your car, take your script, and put it in my car. now my car cannot be sold or transfered, only i can use it.

somebody mentioned this as plagarism, and if i entered this item in a "hot bod" contest for 1st prize of 250L$ then yes. but i can not sell it as my work, infact, i can't even give it away. and this defining feature of the system would prevent me to benefit. i believe under the current system i would have to purchase a new item for everytime i wanted to pass on a transferable script. in this case it could be plagarism (although the scripter would not be financially cheated) so perhaps the name should show up somehow on the object if this is allowed by LL.

remember, now in this situation, the inverse is possible too. you could break the wrapper on my nicely built vehichle or furniture and rescript it for your own personal needs

Jauani,

For the purposes that you mentioned, a wrapper isn't even necessary. Permissions are set separately on scripts and objects, so if the script is already set with the permission as no-transfer, then you won't be able to transfer it.

The solution already in place is simple, elegant. I believe that it nicely balances the rights of sellers and buyers. For more complicated systems, where creators would be worried about nefarious things being done with the component parts of their items, scripters have at their disposal scripting-based means of creating wrappers.


If we are going to add more changes to the permissions system of commerce, I'd be interested in a new permission that allows owners to transfer even items that would normally be considered no-transfer but deleted all instances of the original from their inventory.

Example: I buy a super nice sweater with copy/ no-mod/ no-transfer permissions. I can incorporate it into multiple outfit folders in my inventory, but can never give it as a gift or sell it. The new permission would allow me to do that, but eliminate all copies of the sweater from my inventory.

Personally, I like being able to remove inventory items, especially animations so I can use them in something else. For some scripts I wrote that I didn't want people to mess with, I have the creator check, and I use llXorBase64Strings between scripts so noone can use my messages.

string encryptPass  = "somepassword";

string encryptMessage(string data)
{
     return llXorBase64Strings(llStringToBase64(data), llStringToBase64(encryptPass));
} 

string decryptMessage(string data)
{
     return llBase64ToString(llXorBase64Strings(data, llStringToBase64(encryptPass))));
}

default 
{
    state_entry()
    {
        if(llGetCreator() != "myKey")
            llRemoveInventory(llGetScriptName());
        llMessageLinked(LINK_SET, 0, encryptMessage("STARTED"), encryptMessage("Whatever!"));
    }
    link_message(integer source, integer int, string data, key id)
    {
        data = decryptMessage(data);
        id = decryptMessage((string)id);
        //Do whatever
    }
}

Off the top of my head, but you get the idea. You could go further and do an llMD5String with a random number on entry, and kill the script if you don't get the expected responses.

string password          = "somepassword";
integer otherScripts   = 4; //We need 4 good responses

integer authCode;
integer goodResponses;

default 
{
    state_entry()
    {
        if(llGetCreator() != "myKey")
            llRemoveInventory(llGetScriptName());
        authCode = (integer)llFrand(99999999);
        llMessageLinked(LINK_SET, authCode, "AUTH", "");
    }
    changed(integer change)
    {
        if(change & CHANGED_INVENTORY)
        {
                goodResponses = 0;
        }
    }
    link_message(integer source, integer int, string data, key id)
    {
         string challenge = (string)id + password;
         string md5 = llMD5String(challenge, authCode);
         if(data == md5)
         {
             goodResponses++;
             if(goodResponses == otherScripts)
                 state authOk;
         }
    }
}

state authOk
{
     state_entry()
     {
          llSay(0, "Authorized");
     }    
}

and the other scripts would have something like :

string password = "somepassword";

link_message(integer source, integer authcode, string data, key id)
{
    if(data == "AUTH") 
    {
        string md5 = llMD5String(llGetScriptName() + password, authcode);
        llMessageLinked(source,  0, md5, llGetScriptName());
    }
}

That also is off the top of my head. There's probably some mistakes in there somewhere. It's 6 am here, I'm just heading to bed. But again, you should get the general idea. You could get more detailed, have every prim with a script check to make sure the llGetInventoryNumber(INVENTORY_SCRIPT) count is correct, and instead of using LINK_SET send to specific prims.

The first method alone is enough to stop most people.

If the object is No Mod then I believe the contents, and textures should Not be viewable. If you can't modify the object then you don't need to be looking at what is inside. By viewable I mean you shouldn't be able to click the tabs and see them. The texture should be grayed out in the picture.

It is ridiculous that someone is able to pull a script out of something that is made No Modify. If the creator wanted the buyer to pull the script out the object then it would've been sold as Modify.

You don't even have to own the item. You can rip out scripts and other contents even if someone else owns it.

I think this puts rather a crimp in the "I own it, I should be able to rip it" argument.

neko

Only if the scripts are set to "anyone can copy."

What convoluted hack is necessary to steal a script from a no-mod item which you do not own? I was under the impression that the most recent exploit had been patched. If you know of a new scheme, you should report it to the Lindens.

As for your other comment: how does this in any way detract from Fair Use and First Sale arguments? You allude to an incident of theft, and then suggest that this somehow applies to the discussion. In fact, this has absolutely nothing to do with a debate over whether someone who owns an item should be able to remove the scripts from that item. It is a completely separate issue. One can support the rights of the consumer without being a thief.

Again, there is a miscommunication or semantic misunderstanding

Just because an object is no-modify, that does not mean that the item is no-modify.

Object = A collection of shaped, linked prims, or a single prim.

Item = Object(s) + Script(s) + Notecard(s) + Texture(s)

"Object" and "item" do not have the same meaning, when you are discussing the particulars of the permissions stystem.

Currently, I'm not sure if there is any such thing as a no-modify item in Second Life.

Obfuscation tricks aren't a productive use of a scripter's time. Moreover, they cost compute cycles, which can be really important if you're trying to do things in real-time, such as games.

In SL, game designers often make comprises between security and speed, because LSL is really really slow.

I don't think anyone particularly minds if you delete their scripts. But hacking really ruins the game for everyone. It would be nice if we could protect yourself from those tricks.

Also, the security limitations in SL prevent people from offering more services. Ever wanted to try out some jewelry/hair/scripted attachment? The complete lack of security in SL prevents people from being able to use try-on scripts, so you can try things out free of charge

Probably the item I saw this happen with didn't have its permissions set correctly. I was very sleepy at the time and didn't check closely. My reasoning was that if anyone could get the script/contents out of an item whether they owned it or not, the current permissions aren't even doing what they are supposed to for non-owners, and need to be tightened up, even if it makes owners unhappy. Possibly I was too sleepy when I wrote this comment as well.

I've done some more thinking about this. I think it should be possible to make no-mod items that people can copy scripts out of. (Owners or non-owners, for that matter.) For example, I make teapots and teacups that steam. The steam script that I use is based on a pretty common particle system, and there's no good reason I should be trying to lock that down. If someone else wants to grab it and make something else steam, I have no problem with that. I worked on the script, but it's based on someone else's original script, who was generous enough to share it with the community, and under the circumstances I can hardly treat it as proprietary.

However, I also plan to make custom glazes (textures) for my pottery. They will cost me L$10 each at least to upload, not to mention the time and effort I'll put into getting the image right. They will be a unique hallmark of my work. I don't think it's reasonable that anyone should be able to get them out of my pottery and use them on something else. (And if you want to make analogies to RL, I can tell you that RL potters quite often are highly selective about sharing their glaze recipes, and "right of first sale" doesn't enter into it.)

In short, I think the tools should let creators decide which parts of their objects they're willing to share as individual components, and whch parts they are not. Buyers can then decide whether they want to buy items with those permissions/restrictions (or talk to the creator about getting components in isolation).

Unlike some who have posted, I acknowledge that there *is* a creative element to assembling a variety of components into something new -- collages of found objects are a real-world example of an art medium based on this concept. I support Unhygenix's version of the idea for listing all content creation contributors, and in my own context-dependent rating proposal, I also included a category for "final assembler" as someone you could rate, because that's a skill too. But a lot of work goes into some scripts, textures, animations, etc., and sometimes they give a very distinctive look and feel to an item. For that reason, I think the original creators should have some say over whether or not they can be reused.

I'm not sure if the "Wrapper" idea LL is proposing for the new permissions system will resolve this or not. If not, what I'd like to see is a "removable" parameter for contents of objects. If I set a content to "non-removable", it can't be ripped. But I could set it to "non-modify/notransfer/nocopy", but let it still be "removable" and anyone could take it out and do whatever they like with it. I could see this opening up a lot of possibilities for both creators and buyers.

neko

I am not sure if you are the best person for talking about optimisation ^_^

I voted No. But if we can remove a texture from an object and place it on any other objects, remove the size/shape data of an object and apply it to another object, Unlink a nomod object.

The yes.