Linden Lab have issued an update to the Third Party Viewer Policy, and it is causing something of a stir.

The key additions to the policy are sections 2.a (iii), 2.i, 2,j, and 2.k. These were discussed during the Viewer development meeting, and additionally announced via a blog post which followed the meeting.

Each of the clauses are given below together with key bullet points for each of them taken from Oz Linden’s presentation given during the Viewer Developer’s meeting. An audio transcript of the entire meeting is also available on-line.

Privacy Clauses

Three of the four new clauses (2.a.(iii), 2.i and 2.j are related to privacy issues.

2.a.(iii): “You must not provide any feature that circumvents any privacy protection option made available through a Linden Lab viewer or any Second Life service.”

• Any privacy protection options that are coded into the Viewer cannot be removed, but must be implemented within a TPV in a compatible manner
• This does not in any way limit or impact the use of client-side radar tools
• If there is a feature in Profiles, a Second Life Service or the official Viewer which says, “I do not wish people to see this about me”, then the function cannot be overwritten or ignored
• Directly affects “on-line truth” tools, whether built-in to a Viewer or scripted via LSL (llRequestAgentData())
  • The function will be altered such that it will only return true presence data if the script or object containing the script is owned by or created by the subject of the request
  • When the change is made, it is anticipated that any scripts using the function will simply return a false value (unless the subject is the owner or creator) rather than breaking
  • Objects like club or store-based on-line indicators will still work, providing they contain scripts created by the individuals whose status is being checked
• For Viewers such as Phoenix, which include the functionality within the Viewer code, it means the capability will be removed in the next update (via Jessica Lyon in a Phoenix Viewer blog update)
• The code change is in development, but LL do not currently have a release date for it
• There is a possible use case situation with regards to sandbox tools (and similar) that run a check to see if a person is still within the region prior to requesting / running a clean-up of their prims, and this will be investigated for impact

2.i: “You must not display any information regarding the computer system, software, or network connection of any other Second Life user.”

2.j: “You must not include any information regarding the computer system, software, or network connection of the user in any messages sent to other viewers, except when explicitly elected by the user of your viewer.”

• These more-or-less directly applies to Third Party Viewer client tags
• A region update scheduled for next week (Tuesday / Wednesday) will be break the tagging system for all Viewers
  • The changes to be implemented will also break people’s abilities to set colours against the tags they see in their own world view
• These clauses do not impact the ability for a TPV to include a check box users can use to specify their Viewer within, for example, Group chat (again as is the case with Phoenix / Firestorm support, as such a system in “opt-in”
• An “opt-in” capability for people who wish to display their Viewer tag will not be allowed
• These  clauses do not prevent people from voluntarily adding the name of the Viewer they are using to a Group tag

Shared Experience

2.k: “You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.”

This is the hardest clause to summarise, and the one that presents the greatest number of issues.

Essentially, LL are ring-fencing certain aspects of Viewer development – a move which is liable to stifle a degree of innovation within TPVs. To help understand the clause, Oz cited a couple of examples of what the clause isn’t directly about:

• The clause is not about different ways of presenting the world – so things like an improved renderer, such as seen in the likes of Niran’s Viewer or Exodus, is not (to quote Oz), “A big deal”
• The clause is not about changes to control mechanisms – so if someone develops a new means of moving objects in-world, that’s not an issue providing the way in which the object moves is seen to be the same no matter what Viewer is used by anyone witnessing the object in motion
• The clause is intended to prevent is having a Viewer change the manner in which objects and / or the world behave without working in concert with Linden Lab.
  • As an example of this, Oz cited the old “second attachment” system initially seen in the Emerald Viewer, in which objects additionally attached to an avatar using Emerald’s secondary attachment point (“hand 2”, “shoulder 2”, etc.), would present “correctly” to other users of the same Viewer, but would not be presented correctly to anyone using any other Viewer (they would generally appear to be trailing along behind the wearer’s bum)
• In terms of developing such “shared experience” features within the Viewer, Oz said: “That’s fine, that’s good. But you have to do it with us, and we have to get it into our Viewer and then propagate it out from there.”
• Linden Lab is working hard to improve its responsiveness to Viewer shared experience feature requests and to better engage with developers – Qarl’s Parametric Deformer was cited as a case in point
• However, if a shared experience feature is rejected by Linden Lab, then it cannot appear in any TPV used on Second Life
• LL hope to “work as fast as we can” to get things done on the server-side, and then work as fast as possible with TPV developers to get things done on the Viewer side
• LL request that in order to make this work, that TPV devs work on the LL code base rather than their own code when it comes to shared experience functions
• The stated reason behind the addition of this clause is (51:06): “We have observed user confusion and problems that result from  the fragmentation of the experience depending upon what Viewer you are running. And we think that all users should have … fundamentally the same world to be in, regardless of which Viewer it is.”

Thoughts on the Changes

I’ll be honest and say that the first three changes to the policy leave me in a neutral frame. The proposed changes to llRequestAgentData() strike me – admittedly a non-coder – as fair and reasonable and that they should overcome issues relating to fear of breakages.

TPV tags (and colours) are something I’ve never had an interest in, and while I can see cases where they are useful, I don’t actually see their removal as that big a loss. Certainly, when it comes to the issue of user harassment based on Viewer usage, I will say that Oz is not the first person I’ve heard this from; much the same has been said in TPV development circles – so eliminating tags could be a good thing.

The final clause, 2.k, on the subject of “shared experiences” is proving to be the real kicker however, stirring a lot of reaction – most of it negative.

I actually find myself sitting in the middle of the road somewhat when looking at it. Which probably means I’ll get run over from both directions…

On its own, the idea of ensuring all users are presented with a world that behave predictably the same way not matter what Viewer is in use, and with which users are assured they are seeing and sharing the same experiences as those around them are seeing and experiencing, is fair enough. There is actually a lot to be said for the approach in principle –  as was said in the meeting, “It doesn’t help anybody, really, if someone implements a feature half-arsed … in whatever manner they can manage without the proper back-end support, versus the whole feature getting a project and … get proper back-end support and get it on-line properly for everyone at once, versus it getting half implemented and getting used, say like, by half the grid instead.”

There is also the fact that Linden Lab has, as a company, changed somewhat over the past year or so. While they do still have problems within and of themselves, the fact is that they have become more responsive, are putting more time into the platform, dealing with issues and working hard to bring the Viewer on. They’ve responded to user irritation with the V2 / V3 UI, they’ve taken-on feature development such as region Windlight settings (whether this is a result of Viewer parcel Windlight settings or hasn’t quite been implemented as some hoped isn’t entirely relevant – the point is, the Lab responded). We’ve seen them begin to solicit TPV developers for help in general Viewer functionality (such as with Kitty Barnett porting and re-coding her Spell Check for inclusion in the official Viewer). As such, when it comes to the company stating they want to work with TPV developers in order to implement accepted shared experience features as quickly as possible, one should perhaps take them at face value.

But in trying to ring-fence specific aspects of Viewer development, Linden Lab risks unravelling what has otherwise been years of highly innovative and beneficial (for users, to the grid and to LL itself) Viewer development which has not only dramatically improved their product as a whole, but which has been able respond to user requests and implement them with a level of flexibility and imagination that Linden Lab cannot hope to emulate, allowing the Lab to remain focused on core issues.

There is a very real risk that this policy change will completely stifle Viewer innovation – or even drive it away from Second Life entirely. One can well understand developers no longer wishing to invest their unpaid time into code and functions that LL might ultimately decide is unsuitable for the Viewer and SL as a whole.

Even if a feature is accepted by Linden Lab, things don’t appear to get any easier for the TPV developers. For a start, the function will have to propagate through LL’s development and release cycle – which means it is at the whim of the Lab’s own priorities well beyond the control of the developer. Then there is the added fact that should LL opt, for whatever reason, to alter the submitted code / function, the TPV also has no choice but to go back and change their original code to match. Finally, even if the code is accepted and percolates through the Lab safely, the TPV developer still can’t release it until after it has reached a release version of the official Viewer. All of which could leave even the most stout-hearted thinking, “Why even bother?”

Of course, it should again be emphasised that clause 2.k doesn’t apply to every function developed by a TPV. As such, it is currently hard to see how this will pan out. Certainly, TPVs are going to have to mull over the revised policy and determine how they are going to respond in terms of their development plans. Perhaps they’ll opt to bite the bullet and move ahead as best they can; perhaps they’ll opt to refocus efforts purely on those aspects of the Viewer that are not affected by clause 2.k.

One thing that is clear is that with Viewer tags due to be broken next week as a result of the server-side changes – something that is bound to bring matters to the attention of a wider public within SL –  coupled with requests for the matter to be discussed at the next developer meeting, this is an issue that will be reverberating for a while to come.

Related Links

• Oz discusses TPV changes – March 10th
• TPV changes: Oz provides further explanation; Tateru gets answers – Feb 29th