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.
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:
- Developers must apply to be registered.
- LL vets them and supplies a compiled Digital Certificate.
- The Certificate is added to the Viewer code.
- The Viewer source code (including the code required to PRESENT the Certificate to the LL servers) is published
- LL update their servers to only accept Viewers which present a Certificate.
- 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?