Hello there,
I have just received a message from a Linden asking me to encourage all of you who are building RestrainedLife viewers for any platform, to change llversionviewer.h to set the correct "Restrained Life" channel instead of the original "Second Life" one. This is because Linden Lab is gathering statistics on how spread each custom viewer is used, according to the channel used on login.
This is important because it will help LL decide whom to include in the "early disclosure" list of custom viewer maintainers, which members are able to receive warnings about security holes before the public, hence allowing them to publish patched viewers before the wave hits the shore. In other words, you and your users would not have to wait several days before getting an updated version.
For the same reason, please do not incitate your users to put a "--channel" in the shortcut they use to run the Restrained Life Viewer, or that would defeat the code hereunder.
So please, don't forget to apply this change to your code before releasing a new viewer :
In llcommon/llversionviewer.h
- const char * const LL_CHANNEL = "Second Life Release";
+ const char * const LL_CHANNEL = "Restrained Life Release";
Thank you for your attention !
Marine
Tuesday, March 24, 2009
Wednesday, March 18, 2009
RLV license
This post is meant to be a bit formal, because I feel I have to remind a few things about how the Restrained Life Viewer ("RLV" for short) is licensed. It has a double purpose : to protect my work and to reassure the users and scripters about the consistency and the unicity of the RLV.
First of all, let me make a distinction between the RLV and its implementation (source code and executable). This license only applies to the RLV itself, neither to its source code nor to its executable, which are both licensed underthe GPL v2 (see http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt) whatever license the source code of the original SL viewer, that the RLV modifies, says it is (at the time of this writing, it is licensed under LGPL v2.1), in short you have the right to read the source code, modify it, build it and redistribute it at will. The source code used to be licensed under a loose copyright but it was upsetting a lot of people for no real benefit on my side, and was not practical to defend. It was just there to fulfill the purpose of this very post, but it was done at the wrong level.
Being the original author and maintainer of the Restrained Life Viewer, and recognized by everybody as such, I am legally granted authors' rights on its concept (and have been since the beginning, see http://en.wikipedia.org/wiki/Authors%27_rights). I will not even attempt to rephrase what "authors' rights" stands for in plain English, the definition and scope are already complex enough, but this post is meant to state ground rules about what third-parties can do with the RLV, and what they cannot do, in other words it is focusing on my moral rights upon this project and not at all on my economic rights. In Europe moral rights are strongly enforced while in the USA they are not bound to copyright. This is not a problem since all I want to do is to protect my work from defamation and unfair competition.
The Restrained Life Viewer is a modification of the original open-source Second Life Viewer to allow in-world scripts to control some of the behaviours of the Viewer (as in "send commands and requests to it"). The following rules state what a third-party viewer must comply to in order to pretend to be a Restrained Life Viewer :
* It must implement every command specified in the RLV API and no other (see https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeAPI), and this API is written and maintained by Marine Kelley (me) only. It may improve a command by "making it better" (for instance fixing a bug) as long as it doesn't change the way scripts use it through the API. The key concept here is "interoperability", which means that a script designed to be RLV-enabled should work the same with all the RLVs built by different developers, regardless of their implementations. If it does not work the same with one viewer that claims to be a RLV, then that viewer cannot claim to be a RLV, even remotely (it would have to be clearly distinguishable from my work by any user).
* It must not do what a script or a set of scripts can do. This is to protect scripters from being threatened by viewer developers when it comes to making and selling SL content. The exception to this rule is : it is allowed to do what a script can do if the regular SL viewer can do it as well.
* It must not break content. In other words, when a command is implemented, you must assume that some people are selling products that rely on it and are making a living from it. If the command is flawed, repair it. If it is not broken, don't fix it.
* It must not compromise the privacy of its user or of any other person. This means the RLV must *not* and shall *never* send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.
If your viewer cannot comply with at least one of the points stated hereabove, you do not have the right to make it pretend it is a RLV, or even related to it. The fact that you base it on my code or not is irrelevant.
Please note : All the points above are only applicable if you are within the scope of the RLV. For instance, adding a button to teleport to a favorite location without using a landmark is ok for me, since it is not related to the concept of RLV, even if a script can actually do that.
To address potential concerns, I am not licensing the source code of the RLV under anything else than the same license as the SL viewer, but only making sure that the RLV stays consistent regardless of whoever publishes it, so that in-world scripts do not have to wonder whether they are interacting with one flavor of the viewer or another. This is the key concept and the most important thing to keep in mind when implementing a RLV. I will never claim royalties on any kind of use of the RLV either, it is meant to stay free (I couldn't even if I wanted to anyway).
I also do know that a few concepts inside the RLV are not my ideas in the first place, for instance sending a folder to the viewer inside the #RLV folder directly. There are a few other examples and I am not claiming authors' rights on any of them.
A good idea would be to identify different flavors of the RLV by recognizable names, the one I publish being "Marine Kelley's RLV" for instance (people who publish a RLV identical to mine but on other platforms are also welcome to use the same name if they want, so that the end-user knows what viewer they are using, but this is not an obligation). But don't forget to put credit where credit is due (as stated by the GPL & LGPL) and to tag your changes to the original source code clearly.
This post is also not meant to "paralyze" the creativity of other people who would like to work on the RLV. In fact it is the exact opposite : like the code of the SL viewer, they are free to modify it and redistribute it at will, and I am going to be more flexible regarding patches that people send me (this is a different matter that will be explained in another post).
To sum it all up, this "license" is not really one. It is merely here to define what a RLV is, rather than to tell you what you can do with its code. These are two totally different things. The older license was saying "you can't distribute a modified version of my code" while this new one is saying "you can't call the viewer you distribute a RLV if it is not working like the original RLV". Although both sound identical, they are not applying to the same level of abstraction.
Finally, a word to those who believe I am doing this "for the glory" : I am not. I was already well-known before even launching the RLV, and the latter has been successful because my name was on it, not the other way around. This viewer is my gift to the community, I have been putting my reputation at stake in it, so I am just asking people to show respect to the accomplished work. If you want to be acknowledged, work with the project, not against it.
PS : I am a very busy person, and this post is very likely to bring me a lot of concerned messages. If you try to contact me to ask whether you can do this and that without infringing this license and I don't respond, please assume the answer is "I have certainly already answered this before and if it becomes a popular concern I will communicate about it on this blog". But until I effectively communicate about it, either in a private or a public fashion, please assume the answer is simply "I'm afraid not".
Please note : Since v2.8 the RLV is able to manage a blacklist of commands. This means the user has a way to make their viewer ignore the commands that could potentially break their fun, and they do this through a debug setting. I am fully aware that this conflicts with the following rule, that I therefore removed :
" * It must not provide a way to inhibit or ignore a command by using a Debug Setting or other customization means, because the scripts must be able to safely assume that every single command they send will be executed once they are aware the user is using a RLV. The exceptions to this rule are potentially harmful commands (those which can be abused by griefers, like giving inventory directly inside the #RLV folder), commands that some system configurations cannot handle (such as @setenv) and the "RestrainedLife" Debug Setting itself since it makes the viewer cease to be a RLV totally when set to False. "
I know that modifying the license just to add a feature is bad, but this feature was so popular a request, that I sensed that this clause was actually getting in the way. That's why it's removed. I apologize in advance for any unintended confusion it might create.
First of all, let me make a distinction between the RLV and its implementation (source code and executable). This license only applies to the RLV itself, neither to its source code nor to its executable, which are both licensed under
Being the original author and maintainer of the Restrained Life Viewer, and recognized by everybody as such, I am legally granted authors' rights on its concept (and have been since the beginning, see http://en.wikipedia.org/wiki/Authors%27_rights). I will not even attempt to rephrase what "authors' rights" stands for in plain English, the definition and scope are already complex enough, but this post is meant to state ground rules about what third-parties can do with the RLV, and what they cannot do, in other words it is focusing on my moral rights upon this project and not at all on my economic rights. In Europe moral rights are strongly enforced while in the USA they are not bound to copyright. This is not a problem since all I want to do is to protect my work from defamation and unfair competition.
The Restrained Life Viewer is a modification of the original open-source Second Life Viewer to allow in-world scripts to control some of the behaviours of the Viewer (as in "send commands and requests to it"). The following rules state what a third-party viewer must comply to in order to pretend to be a Restrained Life Viewer :
* It must implement every command specified in the RLV API and no other (see https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeAPI), and this API is written and maintained by Marine Kelley (me) only. It may improve a command by "making it better" (for instance fixing a bug) as long as it doesn't change the way scripts use it through the API. The key concept here is "interoperability", which means that a script designed to be RLV-enabled should work the same with all the RLVs built by different developers, regardless of their implementations. If it does not work the same with one viewer that claims to be a RLV, then that viewer cannot claim to be a RLV, even remotely (it would have to be clearly distinguishable from my work by any user).
* It must not do what a script or a set of scripts can do. This is to protect scripters from being threatened by viewer developers when it comes to making and selling SL content. The exception to this rule is : it is allowed to do what a script can do if the regular SL viewer can do it as well.
* It must not break content. In other words, when a command is implemented, you must assume that some people are selling products that rely on it and are making a living from it. If the command is flawed, repair it. If it is not broken, don't fix it.
* It must not compromise the privacy of its user or of any other person. This means the RLV must *not* and shall *never* send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.
If your viewer cannot comply with at least one of the points stated hereabove, you do not have the right to make it pretend it is a RLV, or even related to it. The fact that you base it on my code or not is irrelevant.
Please note : All the points above are only applicable if you are within the scope of the RLV. For instance, adding a button to teleport to a favorite location without using a landmark is ok for me, since it is not related to the concept of RLV, even if a script can actually do that.
To address potential concerns, I am not licensing the source code of the RLV under anything else than the same license as the SL viewer, but only making sure that the RLV stays consistent regardless of whoever publishes it, so that in-world scripts do not have to wonder whether they are interacting with one flavor of the viewer or another. This is the key concept and the most important thing to keep in mind when implementing a RLV. I will never claim royalties on any kind of use of the RLV either, it is meant to stay free (I couldn't even if I wanted to anyway).
I also do know that a few concepts inside the RLV are not my ideas in the first place, for instance sending a folder to the viewer inside the #RLV folder directly. There are a few other examples and I am not claiming authors' rights on any of them.
A good idea would be to identify different flavors of the RLV by recognizable names, the one I publish being "Marine Kelley's RLV" for instance (people who publish a RLV identical to mine but on other platforms are also welcome to use the same name if they want, so that the end-user knows what viewer they are using, but this is not an obligation). But don't forget to put credit where credit is due (as stated by the GPL & LGPL) and to tag your changes to the original source code clearly.
This post is also not meant to "paralyze" the creativity of other people who would like to work on the RLV. In fact it is the exact opposite : like the code of the SL viewer, they are free to modify it and redistribute it at will, and I am going to be more flexible regarding patches that people send me (this is a different matter that will be explained in another post).
To sum it all up, this "license" is not really one. It is merely here to define what a RLV is, rather than to tell you what you can do with its code. These are two totally different things. The older license was saying "you can't distribute a modified version of my code" while this new one is saying "you can't call the viewer you distribute a RLV if it is not working like the original RLV". Although both sound identical, they are not applying to the same level of abstraction.
Finally, a word to those who believe I am doing this "for the glory" : I am not. I was already well-known before even launching the RLV, and the latter has been successful because my name was on it, not the other way around. This viewer is my gift to the community, I have been putting my reputation at stake in it, so I am just asking people to show respect to the accomplished work. If you want to be acknowledged, work with the project, not against it.
PS : I am a very busy person, and this post is very likely to bring me a lot of concerned messages. If you try to contact me to ask whether you can do this and that without infringing this license and I don't respond, please assume the answer is "I have certainly already answered this before and if it becomes a popular concern I will communicate about it on this blog". But until I effectively communicate about it, either in a private or a public fashion, please assume the answer is simply "I'm afraid not".
Please note : Since v2.8 the RLV is able to manage a blacklist of commands. This means the user has a way to make their viewer ignore the commands that could potentially break their fun, and they do this through a debug setting. I am fully aware that this conflicts with the following rule, that I therefore removed :
" * It must not provide a way to inhibit or ignore a command by using a Debug Setting or other customization means, because the scripts must be able to safely assume that every single command they send will be executed once they are aware the user is using a RLV. The exceptions to this rule are potentially harmful commands (those which can be abused by griefers, like giving inventory directly inside the #RLV folder), commands that some system configurations cannot handle (such as @setenv) and the "RestrainedLife" Debug Setting itself since it makes the viewer cease to be a RLV totally when set to False. "
I know that modifying the license just to add a feature is bad, but this feature was so popular a request, that I sensed that this clause was actually getting in the way. That's why it's removed. I apologize in advance for any unintended confusion it might create.
Friday, March 13, 2009
RestrainedLife 1.16.1
Hi there,
Finally LL released their latest viewer version 1.22, so here is the RLV that works with it : 1.16.1.
It is not only a "catch-up" version, it contains a lot of small improvements and bugfixes, plus reattaches locked items automatically when they are detached by a script... even by one they contain !
Grab the viewer here :
http://www.erestraint.com/realrestraint
The hash for the Windows zip file is fd873779f5d5debe839b546f14c6e4fb
Edit : If you had performance problems with this version, please download again. This was due to a settings.xml file that was not appropriate for a Windows viewer... since it was the one I used on my Macintosh. I was lazy and just pasted it in the zip, but it is not good enough. The new one is the one coming from the official SL viewer v1.22.11, so I expect it should work better. The executable itself and the patch have not changed one bit, only the settings.xml file.
Have fun !
Marine
Finally LL released their latest viewer version 1.22, so here is the RLV that works with it : 1.16.1.
It is not only a "catch-up" version, it contains a lot of small improvements and bugfixes, plus reattaches locked items automatically when they are detached by a script... even by one they contain !
Grab the viewer here :
http://www.erestraint.com/realrestraint
The hash for the Windows zip file is fd873779f5d5debe839b546f14c6e4fb
Edit : If you had performance problems with this version, please download again. This was due to a settings.xml file that was not appropriate for a Windows viewer... since it was the one I used on my Macintosh. I was lazy and just pasted it in the zip, but it is not good enough. The new one is the one coming from the official SL viewer v1.22.11, so I expect it should work better. The executable itself and the patch have not changed one bit, only the settings.xml file.
Have fun !
Marine
Subscribe to:
Posts (Atom)
Posts
