Boy Lane :: Cool Viewers for Virtual Worlds

If you want to experiment with this yourself, search for
"Yasminia". It is one of the few private islands which are 'correctly' flagged as Adult already (I have not affiliation with them, they were just the first of those which I found).

You should be able to find it in search (places) and visit it (assuming you are 'Payment Info Used' or 'Adult Verified').

Lil writes:

First off, thank you, both of you, for the info!

However, I fear that LL might use this as the ultimate excuse to lock out third party viewer eventually. Hope I'm too pessimistic, though...

@Lil

Actually, to give credit when it's due (and I'm not squeamish when it comes to give a spanking), the Lindens have been pretty fair so far with 3rd party viewers. Even my oldest still run, and that's something which I did not expect.

On a further note, I digged through the Linden 1.23 source a even if they somehow (intentionally or through stupidity) remove older viewer's access to adult stuff it won't be too hard to backport the new flags to older code.

Yar Telling writes:

Yea If anyone wishes to come down to Yasminia Its open for all. We are not big but we have allot of fun. And Valerie Webwyre will be happy to make all your dreams come true. You can find her in the slave lounge. Just look for the red one with horns.And no thats not a joke :P

Happie writes:

Hello all!

I think LL find a way to make ppl who use alternate viewers to verify her/his acc, because I find the following suspicious thing. So heres the story: Everything working fine untill the new release of Sl viewer come out...at that time my pc got a really bad virus and I cant remove it so I simply formated my winchester and reinstall every viewer that I use (cool, emerald, rainbow , and the normal). I logged in with my cool viewer and I got terrible lag and only good for chat, ok I log in the emerald because I think it will resolve my problem but NOT. I reinstall all of the viewers but the same hapens than I remove my video card driver and install an older one driver again the same, BUT when I logged in with the normal viewer it everything works fine and I can teleport, use the build normally without any lag with normal frame rate. Oh did I mention when I use the cusom viewers I had framerate below 10 but I think that was max 3FPS lol.
It looks like this is the LL action against the old viewers.
Anyone have the same experience about it?

Happie writes:

Thanks I will try that and see what happens.
When I done it I will write here my experiences :D

Yar Telling writes:

/me Pokes Boylane. psssttt hey Boy now that your not with henri could we maybe get that little glitch with 1.19 fixed? I had told henri about it he said I was full of it but can show you it if have to. Thanks

Yar Telling writes:

I had sent you a notecard on it.But the glitch with been able to touch stuff even after your blocked.

Yar Telling writes:

Awsome will RLVa still work with all the RLV commands?... and it only happens in 1.19 lol.

herina Bode writes:

Hello Boy, a stupid question, what is RLVa ?

@herina: RLVa is an alternative, opensource, RLV implementation by Kitty Barnett.
It is 100% compatible (with some minor interpretation reserves) and even proposes new features (with no implications on the API, so there is no API forking).
For instance, one feature I like is the possibility to define a folder as an unsplittable "whole", such that when an item is RLV-stripped, all the folder content is detached. The folder can also be considered as a "shirt" or "shoes" or any non-prim layer name.

There is currently no public viewer using this patch, but there are success stories with SLV 1.22, 1.23, Emerald Greenlife, Rainbow, Imprudence, and even SnowGlobe (just tested this yesterday).
Imprudence 1.2 will officially use RLVa, and according to Boy, next version of Rainbow/CV also will.

Anonymous writes:

@Satomi Ahn: Thank you :) THese features seem to be nice... but I am wondering if there was a need for an alternate RLV, is Marine Kelley included in the developpement of RLVa? You talked about minor reserves, I am afraid these reserves become more and more important. You can already see in relays implementations great differences, I wouldn't like to see such differences in the RLV viewers. Thinking of scripters and future nervous breakdown when you will have to know which distribution of the RLV you are using to apply the right commands. (anyway great job for the relay scripts Satomi :))

herina Bode writes:

grrr, didn't put my name in the previous post in reply to Satomi

Happie writes:

I did everything that you said boylane and it wont work with the first time, but I totally uninslall all my viewers than reinstall do everything that in the read me fila and what you told and viola :D it worked. Hehe I tought LL take actions the custom vievers that not include the new "filter" but thanks god the problem is in my machine lol.
I also hope i dont give LL a tip wit that :)

Thanks your help and keep up the good work your the coll and rainbow are a really good one

Anonymous writes:

Does anyone of a Link or anything for more info on RLVa.. if so could you please post it.

@helena:

* the motivation for RLVa is twofold:
1 - Kitty wanted to experiment new stuff and have an implementation free of the bugs Marine did not fix
2 - Marine stated that RLV wasn't opensource.
Whether or not she has the right to distribute a closed-source patch for GPL'd code is not the question (no one wants to go to court and find out!).
However, lots of viewer makers want to be clear with copyright (Imprudence wants to be 100% GPL, for instance). Moreover with RLV's current license, you remain tied up to whatever idea Marine has about how RLV should be used and what it should do. For a standard that should universally be used by secondlife BDSM object scripters (not only RR!), that is no good.

* considering the previous "*", it is clear that Marine wouldn't take part in RLVa (to be honest, Kitty is the only coder of RLVa, but she gets ideas and feedback from me and a handful of guinea pigs, and now some viewer makers)

* the "minor" differences are generally small improvements and fixes about things Marine had overlooked (but might eventually fix, as Kitty generally reports bugs to Marine): maybe an avatar or location name here and there that she forgot to hide, stuff like that.
The point is you script for RLV API, not for RLV-Marine or RLV-Kitty.
(well, I believe there are also new @commands or plans for them... but retro-compatibility is not endangered.)

As for relay implementations: well this is another issue, due to the fact that RLVR protocol is underspecified. Areas of the specification that are subject to interpretation differences should be pointed to Marine. Hopefully she will fix those in the next protocol version (well, mischievous people might ask why Marine would care, as none of the device she sells use RlVR... ).
Anyway, my feeling is that relays and in-world device usually work well with each other (occasional bugs do happen, but is that so different from what happens with HTML or other standards?).
Btw, now there is a new group for discussing relay issues and standardized extensions:
[url]https://wiki.secondlife.com/wiki/LSL_Protocol/Restrained_Life_Relay/OpenRelay_Group

@Anonymous: pointing to the current RLVa wiki or Kitty's SL wiki page wouldn't be a good idea at this stage. Those are completely outdated!

)) Whether or not she has the right to distribute a closed-source patch for GPL'd code is not the question (no one wants to go to court and find out!). ((

Btw, here is my take on the issue. She *might* have the rights on the patch, but not on the source code. Once she distributes the full viewer source as is required by GPL, it is GPL itself and has to live by it's rules.

And anyone can take that (full) source, diff it against the original Linden source, and use the outcome in whatever way they desire, as long as it's again GPL compliant itself. I have done this with the Linden sources many times myself, like diffing version 1.19 against 1.18 and use the diff back on 1.17 and such.

At the very heart of GPL is idea that you have the right to tinker with stuff. Taking something GPL, tinkering with it and trying to keep others from tinkering with your outcome is distintly what GPL tries to avoid.

Behind all those ideas in all the long clauses of the GPL license is one common thing, one philosophy: You can't take something that has rights and pass it on with less rights to those who use your modified thing. You can't take the benefits or 'freedom' of someone's GPL product and then keep some of those freedom just to yourself.

I much more prefer BSD or MIT myself Licenses (which would allow even that, taking open stuff and mashing it into something that has less rights), but GPL is very clear in this regard.


Nick

Yes, this definitely gives the outright feeling that what she is doing with RLV is not "right" (given GPL and FSF's purposes).

However the technico-legal discussion is non-trivial.
For me the answer was clearly that there was no way to justify the distribution of binaries made from mixed GPL and non-free code.

But some disagree (Marine considers the binary is no derivative work... This is obviously wrong.
Who would be the binary copyright holder, if it was true? As compilation is a trivial transformation from source code, the copyright holders are the same as those of the source, thus including LL (and yes binaries *are* subjected to copyright, or software piracy would not be a legal offense!). Then the binary should either be subjected to GPL terms... or not be licensed, and not distributable at all. My feeling, is that GPL would be completely useless if it did not apply to compiled code.

Other people, in the contrary consider that the patch itself is a copyright violation, as it contains lines of GPL code.
I would say that if it is decided the patch is a derivative work, it would not be because it contains those lines (only a technical necessity IMHO, those lines are not the patch per se), but because the patch has no purpose except modifying SL code.

This is of course bordering on legalese (and there are many who feel inclined to interpret GPL), but the very basic of GPL is this:

You can not make a non-GPL 'product' if your outcome/work takes in GPL source. GPL in -> GPL out, Period. You can mix (your) proprietary source into it, but as soon as you release something to the public that is tied to something that is/was GPL, the outcome needs to be provided under the terms of GPL too, and these state (it is really the essence of GPL) that you have to enable people to rebuild that (functionally) very same binary thing and to allow them tinker with it under the same terms as and with no less rights than the original.

All the complicated clauses in the GPL license (like the changes to GPL 2.0) just have one purpose: To stuff loopholes which folks were using in order to turn GPL code into something that gives users less rights than the original code had. These rights are: build, change and be able to release the result to the public again.

If anyone does not like it, it's easy ... don't take in GPL code. That is what the OpenSim folks do, they painfully avoid getting anywhere near anything that is GPL, so they can release it under any license they wish, BSD in that case.

With GPL there has been some fuzz over how exactly the source has to be provided. Technically it needs to the be whole set, but I've bent this rule a bit myself, providing just the diff as long the original is available from LL and seeing the intent of GPL served, i.e. as long it's rather straightforward to get all the stuff together and to build a binary that is equivalent to my version of viewer. If Marine just provides a patch, I'd consider that an bending of the rules too, while it would still satisfy the intent of the GPL idea (i.e. the patch enables people to (re)build their own binary of the RLV viewer without going through unreasonable effort). But in that case the diff/patch has to be the seen equivalent of the full source which has to be provided with the binaries and the source has to be GPL.

Nick

)) Other people, in the contrary consider that the patch itself is a copyright violation, as it contains lines of GPL code.
I would say that if it is decided the patch is a derivative work, it would not be because it contains those lines (only a technical necessity IMHO, those lines are not the patch per se), but because the patch has no purpose except modifying SL code. ((

The point is this. Providing just the patch and not the full source is a violation of the terms already (as said above, I've done this myself too for practical reasons ... but it was clear that the stuff I provide is GPL).

Nobody will (or in my case) did complain, as long as the intent is served: Build, preserve rights, tinker, mix/mash, re-release.

If Marine says her lines of code are proprietary, just ask her to then comply with GPL and provide the *full* source based on GPL that enables a rebuild. Once you have that, you're free to with it whatever you want within the bounds of GPL (diff it against the Linden stuff and/or do what else you wish).

If she says she does not want to comply for practical reasons (because it's trivial to rebuild the full source with the Linden base), she at least needs to admit that the result from applying patch must be equivalent of the providing full source as GPL requires. I.e. apply the patch to the Linden source, then treat the result as if it was provided as 'full source provided with binaries under GPL' and do what you like (as long as you comply with GPL yourself).

I mean, it's really simple. Take the full source (either way) and look at the comments at the top of the source for your rights.


Nick

Marine's intention, from what she says in her blog, is to prevent redistribution of tinkered derivative work from her patch. So I doubt she would comply to any of the 2 alternatives you propose. This is not a practical reason, but an assumed choice of hers.

Therefore, following your reasoning, Marine is violating the GPL (or will be, as soon as she declines a request for GPL'd code). I believe we agree on this.

Still, it wouldn't be right to use her code as if it was GPL'd, just because of her misinterpretation of the GPL.
I believe it is not only safer, but also more civil, to replace RLV by RLVa (provided you need opensource code, of course).

(/me hopes this was my last post about licensing in this thread! Discussions on this topic tend to never end :-()

)) Therefore, following your reasoning, Marine is violating the GPL (or will be, as soon as she declines a request for GPL'd code). I believe we agree on this. ((

Yes agreed. Ask her, point out the issue and terms of license (GPL is more about making people conform rather than sue them out of existence). If she denies (either way, fully to the letter or giving a practical alternative) and the license is violated.

Well, in fact I don't think she actually violates it, because she offers source. With GPL (what they call viral licensing) it automatically adopts GPL be virtute of inherent acceptance. (She takes GPL code, therefore by action accepts it's license and it carries itself further). If you ask a GPLer, they will say, not matter what she says, the code is there and it's GPL.

OTOH, you're certainly right on a practical level. The above is legalese and paper (or bits) is patient and are not doing nothing in themselves. The least anyone wants is a fight and I think it's safe to say that we all prefer coding over dealing with this shit.

So, remake the features (I mean, as your effort shows, none of this is rocket science), provide people with GPL code without hassle, and soon you'll have GPL viewer builders knocking at your door and using your alternative, because everybody prefers clarity over potential fuzz. In fact if I read this right, it already happened.

However, one of the quickest and easiest ways to make oneself irrelevant in the GPL world is to challenge the license or it's intent through what you're doing. So in my view Marine isn't doing *herself* a favor (which shows already, if she would comply, there would probably not be a RLVa), especially if she wants to establish a standard and wants to become and stay the trusted and respected keeper of that standard.

But either way, life goes on


Nick

I don't know about inherent acceptance... looks too strong to me, but maybe you're right.

Well, all you say makes sense but is not obvious to anyone not used to how things go in software development competition when opensource is involved.

This reminds me a discussion I had with Marine in-world, a few months ago, on related topics.
Back then, I told her, more or less, I thought that closing the development process to external contributions was as good as a call for a fork (at that time, I was still believing RLV was GPL).
A few days after our discussion, she published her licensing "clarification" on her blog (Was it because of me? Or was it bound to happen? I don't know.).

The future will tell, but if some day the API forks, it will be because of RLVa (or another alternative), and because of Marine's ill advised licensing decision, made exactly for preventing that!
Honestly I would prefer if the API would as soon as possible become a concerted effort...

))as your effort shows(( huh? RLVa is Kitty's work. I am only an enthousiast supporter.

herina Bode writes:

Well, I didn't understood all :). I am not a lawyer, I am not a viewer maker, only a user on the client side. Thank you for that interresting discussion, I learned many things. I hope it will be a concerted effort, I do not want to change my viewer depending on the objects I worn.
Marine did and is doing great works, spending lot of time, I can't explain and my english doesn't help, I am certainly wrong and mixing all but I am feeling something which looks like the arriving of OpenCollar in Amethyst (and Dari.....) gardens. I know it's another thread, only want to not have to choose between one or another. If only implementation differs and API remains the same, no trouble. I am afraid it will not, that all.

Not sure whether the comparison is relevant: both RLV and RLVa are free (as in free beer), so there is not this competitive advantage OC has on Amethyst.
On the other hand, collars are only collars and do not propose an API with which every other device has to be compatible. So potentially, RLV vs RLVa might have a greater impact (if the API became different). If the API remains the same however, there will be almost no change for the end user (except some goodies that are not related to the API), only more freedom for viewer makers.

herina Bode writes:

Sure, it is not relevant and as a Cool Viewer supporter, it seems I will use the RLVa :). I hope it will not be a competition, even if both are free.

)) The future will tell, but if some day the API forks, it will be because of RLVa (or another alternative), and because of Marine's ill advised licensing decision, made exactly for preventing that! ((

Well, if nothing else, it will happen because her license terms puts those other makers of RLV at jeopardy. They need to share fully compliant GPL source. Luckily LL is rather relaxed about this stuff, but if Marine insists on her code not being GPL, BoyLane and others are well advised to swtich, if only to cover *their* asses and to avoid possible nastygrams.



)) ))as your effort shows(( huh? RLVa is Kitty's work. I am only an enthousiast supporter. ((

Ouch, got that mixed up ... thanks for clarification.

)) I don't know about inherent acceptance... looks too strong to me, but maybe you're right. ((

Just for the fun of reading: http://www.gnu.org/licenses/gpl-2.0.txt (section 5).

Nick

Oh I found something interesting, that looks a lot more powerful than RLV API (potentially):
http://wiki.secondlife.com/wiki/User:Nexii_Malthus/Script_Collaboration (implemented in Vertical Life Viewer, whose existence I just learnt about... it is based on Cool Viewer and Rainbow Viewer. Maybe Boy knows more about it?)

The protocol seems to be derived from this one:
http://wiki.secondlife.com/wiki/LSL_To_Client_Communication (from Dale Glass)

)) Just for the fun of reading: http://www.gnu.org/licenses/gpl-2.0.txt (section 5). ((
Just because it is written in the GPL doesn't mean it is legally enforceable. But yeah, the intent is here.

Marine has a new license for RVL:
http://realrestraint.blogspot.com/2009/03/rlv-license.html

Innula Zenovka writes:

Just a heads up that, at his office hours yesterday (i.e July 1st), Blondin Linden was suggesting that 1.23 will become mandatory for accessing SL sometime late August. I don't know how this will affect your versions of older viewers or what changes may be necessary.

The relevant exchanges were:

[16:16] Blondin Linden: [16:05] Innula Zenovka: Blondin, when do private regions have to flag as Adult, if that's what they need to do? Live Help were quoting DanielRavenNest's wiki article last time I asked them, saying the end of August... is that authorative? ANSWER: A lot of regions have already switched over but yes, I believe the end of AUgust is the rough timeline. Eventually, 1.23 will become a manditory DL for everyone to access SL. Once that happens, private regions should have their maturity level flagged

[16:32] Blondin Linden: [16:16] Innula Zenovka: ah..any idea when it will become mandatory, Blondin? ANSWER: Um, i'm not sure on the exact date but end of August. 60 days after 1.23 was released would be my best best

[http://www.slapt.me/wiki/index.php/Office_Hour_transcript_-_Blondin_Linden:_07-1-2009

@Nicholasz: weird License isn't it?

I mean, the code under GPL is fine (well it was almost mandatory anyway), but how can the API be licensed when it has no copyright patent or any other IP rights to license?
She mentions moral rights, but AFAIK moral rights
1 - are pretty much inexistant in the US,
2 - when they exist, they protect a work that is subjected to author rights, which in no country I know of, protect pure ideas (like the API is).

If by the API she actually refers to the text on the wiki, then it is under creative commons BY-SA (SL wiki license).

<rant>
Moreover she is saying nonsense again:
))
* 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.
((

Maybe she wanted to say: "This is to protect well established scripters from being threatened by new scripters who are smart enough to use whatever functionality is provided by the viewer and script more interesting stuff instead."

I am not the only scripter who strongly disagrees with her positions and disapproves of her attitude, I mean scripters who actually are still making new stuff. Can't she be honest sometimes and say: "I want to protect my business, period." ?

Anyway, if RLVa eventually proposes disruptive innovations that are not in RLV API, I will be happy to use them in my scripts *along* plain old RLV API functions, no matter what Marine says.

IP law is already too often hindering innovation, no need to invoke fanciful laws over those.
</rant>

By the way, for people asking about RLVa, now Kitty has a blog: http://rlva.catznip.com/blog/

No binaries yet... but a reference viewer (likely based on SnowGlobe) is to be expected very soon.

I don't think the license is too bad. Opening the code was inevitable, and if nothing else, it now allows people to build a viewer with her patch without risking to break the Linden's GPL license as well (otherwise a viewer like CV was pretty much caught in the middle between LL GPL and Marine's old RLV code license).

On the other hand, APIs are something that needs to be consistent and usually have a gatekeeper (a single person or a group, e.g. the Perl language has just one guy, the one who invented it, make those decisions).

Not sure about the extensions (or trying to prohibit them), but making an API predictable (i.e. not having it changed at whim by anybody) is a good thing.

She's even right that GPL requires you to make visible to the end user (and in code) when you distribute something that has changes in it, so her key request "you can't call the viewer you distribute a RLV if it is not working like the original RLV" makes sense to me.


Leaving some of the details aside, licensing the API or possibly just the name of the API in my view is a lot less 'fundamentally flawed' than doing this through the code as she did before.

If it holds in court is another thing (nobody will take something like that to court anyway), maybe it's not perfect ... but a lot more reasonable and practical than before.

And it just depends how open she is to suggestions about improvements. If she handles the evolvement of the API sensibly, it may and end up as a really good thing.

Or (just rambling) extensions could be made a new API (let's say Kitty-Bondage-Language or KBL), responding to a script->viewer request for @kblversion.

For in world users and scripters, I think it is really necessary to have stuff easily recognizable. Like a script/attachment for RLV should run on all viewers who claim RLV as a feature. Period. And let's say you make and sell an attachment that requires the extras, you need a simple way to tell the users and customers what they need to use it, like you'd say: Works with RLV but requires KBL extension for bla-blah.


Nick

If I used extras that are not in RLV API, I wouldn't call them RLV, of course, that would not benefit the consumer (or my business).
But I don't want an obscure license to remove my right to refer to RLV for the part that is actually RLV compatible.

Also from the viewer maker point of view, it seems abusive that making extensions would remove the right to call RLV what actually comes from RLV API, even if Marine does not like the extensions because they allegedly threaten her business.

I am for transparency: RLV is RLV API, period. RLV + foobar extensions is still RLV API + foobar API, so devices using both should have both labels "foobar" *and* "RLV".

Well, maybe what Marine meant is no more no less than that, which would be fine with me.

2 things I reproach her though:
- trying to invoke legal protection when there is none (when an explanation about why keeping RLV a unified standard would benefit everyone would suffice)
- saying that it would kill businesses if a viewer implemented too many features, when the truth is only that it would benefit other businesses more than hers.
Didn't it come to her mind that her competitors might also feel threatened by the very fact that Marine can choose to implement only commands that would be useful to her business?

frank writes:

i think it's safe to say the end has come:
i attempted entering an adult region through 1.22 (never even touched 1.23), and there it was: a pop-up telling me i need to age verify.

Anonymous writes:

Not sure where the best place is to comment on this is, but there is a major issue with the Bulk Permissions tool in viewer 1.23 and also the CoolViewer version. You might want to put out a new version Boy that removes this feature.

For the JIRA link check out here
http://jira.secondlife.com/browse/SVC-4444

Simon

Rob Earst writes:

I'm really enjoying the Cool Viewer, but I DO miss the new feature that allows me to read a profile from the mini-map. Any possibility that this will be included in future versions? Thanks for all the work!

Rob

herina Bode writes:

Hello Boy, are you working on a new release including RLV 1.19 version?

herina Bode writes:

I have read your comments about the 1.23 version, and agreed for most of them, I diodn't understand that RLV were a part of your comments (except if you want to use the RLVa and if it is not including the new Marine features). Does your answer mean the cool viewer is no longer following RLV updates, it is 1.17 in cool viewer and 1.19 in Marine's implementatin with signifiant changes betwwen the two.