On Wednesday March 7th, Jessica Lyon of the Firestorm team sat down with Oz Linden to discuss the recent TPV Policy (TPVP) changes. Originally Oz had asked to appear with Jessica on the last Phoenix Hour, which is normally co-presented by Jessica and Phaylen Fairchild, but it was decided to hold-off on any appearance for a more focused presentation.

That Oz made the offer again speaks highly of his desire to engage openly with the community on what has become something of a sensitive (and in some cases incorrectly viewed, given the way it has been wrongly portrayed as stopping “any” innovation within TPVs) issue, and his willingness to try to provide further clarification on the changes and the reasoning behind them.

I’ve included a summary of the discussion on the following pages. As it is somewhat lengthy and potentially subject to “tl;dr” (shame on you!), I felt it better to provide my own thoughts on the discussion up-front.

While listening to the discussion I was also seeing Twitter comments appear on my screen relating to the posting of the interview video and was – to be honest – surprised at the negative tone of some of the comments being made. Overall, I felt the Oz was open and direct in dealing with the questions and statements directed at him, and he did much to fill-in the blanks. And before anyone starts on the, “But he’s only an employee” tack, I very much doubt that he was in any way speaking in isolation or sans the support for his management. As such, this is precisely the kind of engagement we should be applauding, even if the message may not be entirely what we want to hear,  and which LL should be seeking to undertake more regularly.

Some have complained that we “don’t know” any more following the discussion than we knew at the start. To them I’d actually ask, “What more do you want to know?” The boundaries of the TPVP changes have been given better definition – indeed, Oz has provided clearer definitions here, and prior to this meeting. Unless LL produces a set of stone tablets detailing every case, it’s hard to see what more can be said – and it should be remembered that tablets of stone can be as dangerous as having a broad definition. Things do cut both ways.

Sure, what has been said previously, and is said in this discussion, doesn’t provide any safeguards against any fear of how LL might at some point in the future choose to interpret the TPVP – but really, this is an unreasonable expectation. No-one can predict what tomorrow may bring much less a time eighteen months or two years hence, and it is unreasonable to expect any company to give guarantees where the security and growth of their business is concerned. At the end of the day, SL is LL’s business first and foremost – and I applaud Oz for being so frank on the matter of the business / platform relationship – and as such they can change the rules howsoever they like; as such the hammer could be dropped on TPV activities with or without the use of such a policy.

However, I think it fair to say Oz is being sincere both on a personal level and as a representative of the company when he says that LL is not looking to end TPVs, but wants to enhance and grow their working relationship with TPV developers. While it is clear from the phrasing of some of his answers that LL would like to see their effective market-share of users increase in terms of Viewer use, it would be a mistake to attribute the TPVP changes to purely that motivation. It’s fair to say that if that was the goal, LL could conceivably achieve it simply by removing the majority of their Viewer development back behind the curtain, leaving TPVs forever in a catch-up situation.

Nevertheless, the risk of stifling innovation is still there, howsoever small a part the “shared experience” has played in TPV development, simply because of the concerns TPV developers have around the whole aspect of having ideas and proposals accepted by LL as Jessica expresses in the video. This is something that LL need to remain attuned to and seek to demonstrate they will help and support TPV developers when and where they do see an opportunity for developing a shared experience capability that isn’t on LL’s radar or to-do list.

Some will most likely remain dissatisfied with the results of the discussion, which is a shame. While the proof of LL’s commitment to developing and evolving the TPV / LL relationship can only be judged on whatever occurs going forward, there is currently no reason to take what has been said at anything less than face value.

For my part, I would say that Oz’s openness and his candour in dealing with the questions and concerns relating to the TPVP changes is to be welcomed. I hope he does take Jessica up on her suggestion of future discussions of this kind, and that we may yet see LL encouraged to participate in other such opportunities to address user concerns on various matters as openly and directly in the future.

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

On the 13th, Joe (Miller) Linden held the first of his brown bag meetings with TPV developers to discuss the Third Party Viewer Policy. The various transcripts and audio recordings make interesting (if headache inducing) reading / listening.

While it was unfortunate that LL decreed the meeting would be in Voice – thereby potentially limiting input and participation (specifics raised in chat seemed to be somewhat ignored) – the meeting wasn’t as fractious as might have been the case, given the amount of ire the TPVP has created. Certainly, despite the efforts of some to try an disrupt proceedings by crashing sims, etc., progress seemed to be made in the key areas of contention – notably Section 7 of the policy.

This section has caused contention largely due to the wording. If taken 100% literally, it would appear to be shifting all responsibility for TPV code onto the shoulders of TPV developers. While this was not LL’s intent – as I’ve said elsewhere, they are not malicious – the wording did leave a lot to be desired. And while some may disagree, part of the problem does stem from the fact Section 7 mixes the development of a viewer with its use by others. Beyond this, there is the problem that a literal reading of some of the clauses – 7a, for example, appears to give the impression TPVs take responsibility for LL’s code when LL absolve themselves of all blame.

Whether one agrees with this standpoint or not (I personally don’t – and I sincerely doubt the law would interpret the language in the manner some TPV devs fear) – the the wording does cause angst and could be reworded without compromising the TPVP rather suggests that there would be no damage done were minor adjustments to be made to the phrasing of the clause – and this was indeed suggested.

A similar discussion was had around clause 7d, where again, it was apparent that much angst could be resolved by simply striking the first sentence in the clause; what was more, doing so could clarify LL’s position on matters of liability.

Elsewhere, people were more receptive to the fact that the TPVP is concerned with connecting to a service, and therefore stands aside from GPL requirements – something that seemed clear to many “outside” observers on the matter, including myself. Most interestingly, Lance Corrimal indicated that the Free Software Foundation’d licensing expert did not find the TPV to be in conflict with the GPL. That it would be is something I’ve had a hard time getting my head around; again, LL are not stupid. They did blunder with the original draft of the TPV – but they also stated the re-draft would be passed in front of experts in licensing and the GPL. I doubt that they  would subsequently go ahead and release the re-draft without following through on their intent to do so; ergo, it was hard to see how the experts they potentially used to review the TPVP got it so badly “wrong”, while those (with the greatest of respect) not versed in licensing and law were so adamant it is “wrong”.

What remains to be seen for the moment is how much fruit this first discussion bears between now and the next (set, I believe, for next week). When one puts aside all the angst and subjectivity surrounding clauses 7a and 7d, both could be more clearly worded without, as I’ve stated, impinging on the TPVP’s overall intent. As such, I would hope LL will take the suggested re-wording of both to heart and update the clauses.

It would still be nice to see the TPVP more clearly focused on the development of such viewers, with anything relating to the use of the same moved to the ToS. This would not only make the TPVP more focused for both LL and TPV developers – it would ensure the limitations on the use of such viewers are placed where they have a chance of being read by the majority.