Category: Third Party Viewer Policy

Third Party Viewer Policy Update

Posted on by Inara Pey

Sometimes you can’t help but sympathise with Linden Lab – to some degree. They must at times feel like they are trapped between a rock and hard place.

Last week the Third Party Viewer Policy rolled out – and caused everything from flag-waving to howls of despair.

On the one hand, people were happy to see the policy – warts and all – while on the other there were screams about it violating GPL and Creative Commons.

For myself, while I applaud LL for taking action, I was concerned over a number of aspects of the policy: the ambiguity expressed in some sections, etc.

Such was the storm of feedback received, Linden Lab did the right thing and started walking through the minefield of opposing views to try and nail down concerns and produce a policy that can do what needs to be done. While I had to smile at a reported comment from one Linden Lab employee, “Linden Lab has approached outside legal experts with your feedback, and one of these experts is a lawyer who specializes in open source license compliance issues.” *cough*, a shame this wasn’t done from the start –  what we have here is an attempt by the Lab to produce a document that meets the demands of those worries about such things as data and content theft, honours the Lab’s own need to maintain the integrity of the grid and which avoids falling into a legal pothole around the issue of GPL / open source, etc.

In the interim, they’ve issued a FAQ to address many of the issues around the policy. Chief among the clarifications are:

  1. The policy applies to ALL Third Party Viewers wishing to connect to the grid, spelling out non compliance = no connection
  2. It “clarifies” concerns I personally had (as did many others, it seems), section 1h – inasmuch as by “clarifies” I mean Linden Lab are eliminating it from the policy.
  3. Matters around publishing personal data (real name, address) has been clarified. Real names and addresses must be supplied to Linden Lab, but do not have to be listed in the Directory.

These are all to the good. (1.) in particular is beneficial – the policy may have implied such – but it needs to state as much outright.

There is much more to be done – and it is going to be interesting to see what comes out of the current re-drafting of the Policy. However, these are pretty much moves in the right direction.

Whether this policy also spells the “end of saving full permission textures” remains to be seen. I rather suspect not, and that the argument being put forward that it does is both too narrow and too selective of specific phrases within the FAQ passages it points to. If nothing else, it’s a demonstration of my comment on LL being between a rock and a hard place; whatever they do on some matters, there will always be someone ready to start shouting “the sky is falling! the sky is falling!”. What’s more, even when LL react to such cries and revise their position – they still hear “the sky is falling!” being shouted across the forums  – sometimes by the very individuals / groups that shouted for the change in the first place…

Viewer Policy

Posted on by Inara Pey

Alongside the announcement of the Viewer 2.0 Beta, Linden Lab also announced their Third Party Viewer policy is moving forward.

The policy itself can be read in full here. At first glance, it is pretty comprehensive, listing items related to required functionality and disclosures, prohibited functionality, intellectual property rights (both the protection of, in the case of in-world content, and ownership of, in the case of the Viewer code), data access and privacy, branding, and other aspects.

Deeper analysis shows that while it is attempting to cover the bases, there are some statements that require clarification / reconsideration. There is also the not-so-small matter of the policy being almost entirely one-sided.

To start with the former, where clarification  / re-wording is needed:

Point 1h: Central to Second Life is the principle of shared experience. The services we provide through our viewers, for example, our Land Store, the LindeX exchange, and the Xstreet SL marketplace, are designed to enhance Residents’ shared experience. We may ask you to make changes to your Third-Party Viewer if it disables certain of our services, or if we believe it is inconsistent with the principle of shared experience or otherwise negatively affects the Second Life user experience. If we do, you agree to make the changes we request.

  • Where does this leave “lite” Viewers supplied by third parties (i.e. variants on the SLIM product, such as the Second Inventory “remote login” tool)? Or text-based applications? We may assume these are excluded from the above statement, but…
  • Where does this leave Viewers that may opt to promote what might be considered rival services. XStreet is all well and good, but what if Viewer X opted to include a link or links to another on-line web service that is viewed as an alternative (aka “rival” in LL’s eyes) destination? While it fits the bill of the “Resident’s shared experience”, we’ve already seen the removal of posts from the forums that simply reference such sites. Will the same heavy-handed censorship find its way into how Viewers are seen, because such references are seen (by the Commerce Team in particular) as “negatively affects the Second Life user experience”?

Point 5b: Your Third-Party Viewer name must not be confusingly similar to or use any part of a Linden Lab trademark, including “Second,” “Life,” “SL,” or “Linden.” For example: You must not have a Third-Party Viewer name that is “________ Life” where “________” is a term or series of terms.

  • “SL” “Second Life” (note the quotes) and “Linden” are all quite reasonable; but singling out the use of the word “life” is perhaps going s tad too far; it’s a generic, everyday term (as is “Second” for that matter). While one can see the need to protect both the brand and the naive user from attempts to confuse or obfuscate via deliberately provocative names (e.g. “Pey’s Invincible SL Viewer”) – banning the use of a term like “life” is a tad unreasonable, particularly when Viewer developers have to comply with 1C, to wit: The name of the Third-Party Viewer and a disclaimer that “This software is not provided or supported by Linden Lab, the makers of Second Life.
  • It is unclear where this leaves Viewer options such as Restrained Life. Now more predominantly known as “RLV” – to the point where “RLV” could be considered its branding – is this Viewer code now banned on the basis of its name, despite the fact that in every other respect it is complaint. Where it called “the SL Restrained Life Viewer” (or even “the SL RLV”), I’d be more sympathetic towards LL – but as it is, discriminating against the use of the word “Life” comes over as pettymindedness.

Point 6a(ii): You must provide true and correct information in the Viewer Directory Application Form, and you agree that the information you provide in the fields that are marked by a cross (†) may be published in the publicly available

This again appears to go beyond what is required. Yes, the Directory is a good idea, and having a list of “certified” Viewers from third party sources increases user confidence. But….

…why is it necessary to openly publish information relating to the real-life business address of the Viewer developer (and possibly a real life identity, although not having seen the application form, I have not idea if this in mandatory – I can only make a call on the business address is this is shown is being publicly available in the sample directory listing)?

Such public disclosure serves absolutely no purpose whatsoever. Period.

  • YES – developers should give real life information: name, contact details, business / home location to Linden Lab
  • YES – this information should be retained by Linden Lab for as long as the developer supplies the Viewer
  • YES changes to the developer’s real life information, or information relating to a Viewer “changing hands” between developers should be recorded and passed to Linden Lab
  • NO none of this information should find its way into a publicly accessible list
    • It does nothing to improve the “validity” or “safety” of the Viewer the developer is supplying
    • It does nothing that helps the user understand the veracity of the codebase
    • Ir does however open the developer to the risk of harassment, griefing and God knows what else

Given it is unlikely that the majority of third party Viewer “developers” are going to be corporate entities in any way, shape or size, but rather they are:

  • EITHER going to be individuals working from home, in their spare time and out of a passion for Second Life – such as Marine Kelley, Henri Beauchamp et al,
  • OR going to be a part of a loose-knit, hobbyist team working on a distributed project, such as the Emerald team

….do those at LL responsible for this policy:

  • Really expect such individuals to go out and take on the expense of forming an off-the-shelf company that can use a (fee-charging) registered address on order to provide themselves with some protection
  • Actually believe making home addresses of users available to the public at large is justifiable?

Some will say that development of a third party Viewer removes a developer from the protection of anonymity. To these people I can only say, “cobblers”; the development of a third party Viewer only removes a developer from the protection of anonymity in their dealings with Linden Research. There right to anonymity in their dealings with the rest of the community remains unchanged.

Point 7a: You are responsible for all uses you make of Third-Party Viewers, and if you are a Developer, you are also responsible for all Third-Party Viewers that you develop or distribute.

This is at best ambiguous. Exactly what does the term “you develop or distribute” mean? If I develop my “Pey’s Invincible Viewer” and make it available via a website in due compliance with this policy….

  • Does my responsibility for the code end at the point of download, or
  • Will I be held responsible for the actions of those who download my code and then amend it for their own nefarious ends?

“Distribute” can cover a multitude of sins, not all of them the developer’s fault.

Beyond these issues lies a bigger problem with this policy: the fact that it is totally one-sided.

From start to finish, the onus is on the third-party Viewer developer entirely. No-where does the policy imply any actions are required by Linden Research – particularly when it comes to stopping / blocking non-compliant Viewers.

This is Failure One: Not only is the policy voluntary and self-certifying, Linden Research clearly state they’ll do the absolute minimum to police it, vis: We may analyze any Third-Party Viewer and its code, content, and data for any reason, including to ensure that the application complies with our policies and is safe for users. Although we do not guarantee that we will conduct such an analysis, we may do so in our sole discretion.

Note the terms, “may” and “sole discretion”. Yes, reviewing every line of code of every Viewer submitted is clearly beyond the pale. However, by having third party developers document specific instances of code that branch from the accepted standard for the Viewer, or which introduce new functionality into a Viewer should be enough for Linden Lab to test  / review that particular functionality  – and it is not as if we’re going to be talking millions of lines of code.

What is wrong with a Viewer developer having to go through a QA cycle whereby new iterations of their Viewer can only connect to the test grid and subjected to user testing much as the official Viewer is bumped around, prior to being formally released? Obviously, there are issues around this, but they are not insurmountable – and they’ll again increase user confidence.Again, we’re not talking about dozens upon dozens of new Viewers…

Failure Two, however, cuts right to the core of the issue. Absolutely nowhere is it asserted the Viewers failing to register with the Directory will be blocked from accessing Second Life.

By not specifying the fact that Viewers failing to register their compliance with the policy, and what actions will be taken against such Viewers, Linden Research is overtly suggesting that things will be pretty much business as usual for such Viewers.

It’s a thorny issue. I don’t profess to have all the answers – I openly admit to the fact that software coding and development is as foreign to me as the bottom of the Atlantic Ocean. I would, however, expect to see a policy that is a little more proactive when it comes to LL’s position than is currently the case.

Of course, any proactive action LL tries to take is going to be prone with issues and is hardly going to be foolproof – but this is no excuse for not trying to be more aggressive / assertive with this policy. At the end of the day, a passive policy is potentially as bad as no policy at all. Worse, it’ll be seen as further proof that Linden Lab are interested in little more than papering over the cracks.

ADDENDUM

When I drafted this, I included comments on digital certification but, as stated above – I’m no coding expert, so I cut the section out, thinking it was potentially a load of dribble. However, I’d like to thank Spikeheel Starr for pointing out that, in essence, my idea was correct, and for making the original point I wanted to make more robust.

That point is simply that *if* Linden Lab wanted this policy to be effective, they could have insisted upon a form of digital certification for ALL Viewers wishing to connect to the grid:

  1. Developers must apply to be registered.
  2. LL vets them and supplies a compiled Digital Certificate.
  3. The Certificate is added to the Viewer code.
  4. The Viewer source code (including the code required to PRESENT the Certificate to the LL servers) is published
  5. LL update their servers to only accept Viewers which present a Certificate.
  6. The Certificate itself is issued in a secure form within the Viewer installation script.

I understand the code changes wouldn’t be that hard to implement, and providing a Certificate / certification process wouldn’t break GPL.

So again…assuming all the is right – and I’ll bet my hair Spikey is right, the question must be asked, why aren’t LL even appearing to move in this direction?

LL Announce Third Party Viewer Policy

Posted on by Inara Pey

Jack Linden isn’t the only one setting up new programmes within SL now the Adult Change fiasco is “sorted”. Cyn is back, with an announcement concerning third party viewers.

On the whole, this can only be seen as good news: while open source viewers are not the root of all evil as some would have us believe, it cannot be denied that there are several out there that exploit weaknesses in the SL environment in order to make activities like content ripping easier. As such, it is right and proper that LL work with the community as a whole to develop the means of keeping such unwanted elements – Neillife, Cyrolife, and their ilk – well out of SL for the good of all.

However, this does not mean that all third party viewers should be condemned. While the usual voices can be heard again screaming the house down over the Emerald viewer in particular and to the exclusion of all else – again, it cannot be denied that open source development on the Viewer has also been a power for good. It has allowed those who experience uneven results with the “official” Viewer to find a degree of stability with one or more alternatives that has dramatically enhanced their SL experience; it has allowed those so-minded (and who can remember back far enough) to enjoy the benefits of some of the “old” UI that were lost when LL forced us into acceptance of things like the catch-all “Communicate” window (which was a terror when it first came out). Third party viewers have eased the use of legitimate API functions, they have provided improved menus, improved access to building tools (Imprudence being one of the first in this regard), and so on. Perhaps most importantly, they’ve introduced genuine bug fixes and helped clean up code far quicker than would have been the case had the Viewer remained closed – and in doing so, have directly benefited the “official” Viewer itself, as these changes and fixes have been fed back into the code – something those all too keen on screaming “ban the open source!” seem to forget.

So in this regard, policing third party viewer development, such as through the use of a register that places real life accountability against viewer code, can only be a good thing if handled correctly. There can be little doubt that those “honest” third party viewer creators – the guys at Imprudence, the team behind Emerald, those working on the various flavours of Cool Viewer  – all will be the first to sign-up to a properly thought-out and implemented policy and registration / policing process.

To this end, and leaving aside the banshee wailing and biased finger-pointing that repeatedly singles out just one viewer for vehemence, there have been many very excellent ideas posted in the blogrum discussion following Cyn’s post. Anne O’Toole hits upon one important element, while others offer ideas for helping ensure the development process can be more properly integrated into SL – the worry that any policing could inevitably drain the patience of “legitimate” open source developers if it puts unreasonable hurdles between them and their goal of improving the SL experience for everyone. And while it may require a lot of technical input (and possible cost), Marine Kelley possibly hit upon one of the best solutions.

Right now, the real question is, will LL actually engage fully and openly with those most involved in the development of third party viewers? Macabe Maxstead from Imprudence raises a genuine concern with his question, and has every right to be worried when Blondin Linden announces that while there will be Brown Bag meetings  – they will be run more-or-less like those for the Adult Content changes – i.e. open only to a select few, with the criteria for selection known only to LL themselves.  That the latter were carried out as closed-door sessions gave people cause for much alarm at the time – alarm that was all too easily justified as it became clear just how little room there was for actual engagement with LL and discussion around their decisions relating to Adult Content.

It’s a cleft stick to be sure: no-one can justifiably stand against measures that control third party viewer use on the grid when the control is fairly aimed at reducing the ease with which those so minded can carry out malicious acts. But, by the same token, Linden Lab need to be prepared to engage fully with the open source development community to ensure that the actions they take both safeguard those of us who use Second Life and allow those passionate enough about SL to continue to work at their own expense to improve our in-world experience.