Oz discusses TPV Policy changes

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.

Oz in conversation

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.

TPVP changes – Oz provides further explanation, Tateru gets answers

As concern over the latest TPVP changes continues, Oz has offered-up additional information on what section 2.k in particular means, and how it affects TPVs is terms of official Viewer releases, etc.

In a comment on the thread Questions about new TPV policy initiated by Cummere Mayo, Oz states:

Thanks for taking the time to pull your questions together, Cummere. I know a number of others have had similar questions, and I wanted to take a minute to address them here. I hope this will help clarify things.

1) What is meant by shared experience?

Making a simple statement that covers all possible cases is not easy … there is an unavoidable element of judgement in interpreting this rule; I’ll try to answer below, but that should not be taken as modifying the policy itself.  We will certainly help developers with proposals to understand whether or not a feature might fall under it.  It’s worth noting that the vast majority of all changes made by third-party viewers have certainly not been a problem.  The fact that there have been some problems in the past motivated our adding this rule so that in the future developers would work closely with us to prevent any more like them.

A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.  

This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.

2) What counts as the latest released Linden Lab viewer?  Do the Snowstorm and Beta viewers count as released?

The Release viewer is the benchmark, but the difference in time is normally quite small (a few weeks).  If the relative release schedules of our viewer and that of some TPV are causing a problem, then we will discuss making allowances for that if the stability of the feature makes that a reasonable thing to do.  The whole point of the Development and Beta viewer builds is to test things – which implies that those tests may reveal the need to modify the feature, potentially including changes that would not be compatible with the earlier version, so the likelihood of this kind of problem would have to be taken into consideration.

3) Does this mean systems like RLV and integrated AO’s are no longer allowed?


4) Does this mean that third-party viewers may no longer experiment with and help test new features?

No – if the feature would fall under the 2.k rule, then it is faster and easier for everyone if the primary development and testing of it be done based on the common upstream code we make available to everyone, but parallel work by developers in test versions (not the default downloads) of TPVs will usually be ok as long as everyone (including the users of those test viewers) understands that the feature may change in incompatible ways, or even in an extreme case be withdrawn (such as if it is found to be harmful in some unresolvable way).

5) Does this mean that text only viewers or “voice only” viewers would no longer be allowed?

No – failing to provide a common feature is not the same as adding a new feature.   Users who choose to use such viewers are making a choice that is up to them. 

In terms of impact on TPV, the core paragraphs are:

A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.  

This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.

These give unequivocal clarification to a misunderstanding I’ve seen posted on a number of blog commentaries: that UI changes developed by TPV are unaffected by the policy update. To be fair to Oz, he made this very clear in the meeting last week when the changes were announced – but some commentators still seem to have the wrong end of the stick when it comes to UI changes.

To put it simply: the policy changed doesn’t impact on things like revised Build floaters, additions to the Snapshot floater (to upload to Flickr, for example) and improved Camera control floaters, etc. Similarly, things like object derenders are well outside the scope of the policy, as is the ability to audio or visually mute others (which is a concern I’ve seen raised elsewhere, despite the fact it is LL themselves who are introducing Visual Auto-mute), so people have no reason to worry on these scores.

I still find “shared experience” as defined in the policy itself to be far too vague – Oz’s clarifications notwithstanding; and it is the policy that will be used as a yardstick, not additional comments in a forum which may well be lost in archives over time. As such, it would be useful if wording such as Oz gives in the two paragraphs above were cited within the policy as examples as to where the line is drawn.

Better yet, I’d like to see the Lab take-up Tateru Nino’s suggestion. Over on her blog, she publishes the answers she has had to date on the policy changes (and if you’ve not read them, I urge you to do so). In particular Tateru suggests:

A well-documented baseline feature-set, that content-creators could refer to with confidence, would make a lot of sense, and probably be of broad utility and benefit…

Which is an excellent suggestion. Such a baseline document doesn’t have to be within the TPVP itself. LL have a wiki, and it could be placed there as a part of resources for TPV developers or those wishing to get into TPV development – as long as the policy provides a link to the baseline,then the needs of the policy are served and people get a clearer understanding as to what is “allowed”, etc.

Tateru’s piece raises the spectre of enforcement – and Section 8 of the policy is somewhat vague to the point of unpredictability, as Tateru states. It was an issue back when the policy was first introduced, and these latest changes bring those concerns back into focus. Again, providing an outline set of exceptions (say, alongside the baseline feature-set mentioned above) would go some way to further focusing developer’s thoughts and people’s understanding.

That said, and in fairness to LL, where problems have occurred with TPVs over the past few years, they’ve made every effort to sit down and discuss issues with the developers concerned, and provided opportunity and time for ways to be mended rather than simply dropping the hammer. As such, I doubt that they are going to stop any such dialogue as a result of these policy changes which may be required in the future. Again, as I’ve said elsewhere, LL isn’t the malicious ogre as can sometimes be portrayed.

I still have concerns that section 2.k will have an adverse affect on broader Viewer innovation than perhaps the Lab anticipates – which is not so say I don’t understand the reasons for the Lab taking this step (which Oz also moved to clarify in part in a comment he made in reply to my original piece on the policy changes). Hence why I feel that were the Lab to take one or two additional steps in the matter and provide a baseline functionality document, together with some examples of  potential exceptions that might cause problems (with any required caveats about such a list not necessarily being  complete, etc.), would actually help the wider audience of concerned SL users understand what is happening and why, as well as providing TPV developers old and new with a more solid foundation for their work going forward.

Related Links

LL update their TPV Policy

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

TPV: a further re-wording

Following last week’s meeting between Joe (Miller) Linden and some third-party viewer devs, it appear that concerns have now been addressed.

At the heart of last week’s meeting were concerns over the wording of Clauses 7a and 7d, both of which related to liability, and which have now been re-worded, vis:

Clause 7a:

Original: You are responsible for all uses you make of Third-Party Viewers. If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute.

Update: You are responsible for all uses you make of Third-Party Viewers.

Clause 7d:

Original: You assume all risks, expenses, and defects of any Third-Party Viewers that you use, develop, or distribute. Linden Lab shall not be responsible or liable for any Third-Party Viewers.

Update: You assume all risks, expenses, and defects of any Third-Party Viewers that you use. Linden Lab shall not be responsible or liable for any Third-Party Viewers

Both re-wordings seem fair and concise and do not rob the TPVP of any teeth.

Elsewhere, LL has further reinforced their position that that are not in any way attempting to infringe upon the GPL (possibly for those who missed the various statements at the top of TPVP), by adding a new Clause 8f: Nothing in this Policy is intended to modify the terms of the GPL.

All of this should go a long way to reassuring TPV devs that Linden Lab isn’t out to “shut them down” as well as alleviating tensions. Doubtless, some still won’t be satisfied – but that is their choice rather than anything to do with LL trying to hound them out of the playground. The full TPVP can still be read here.

TPV: brown bag and changes?

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.

Third Party Viewer Policy – Further update

LL have quietly slipped out a revised Third Party Viewer (TPV) Policy.

While its heart was most definitely in the right place, the initial draft was flawed in several areas, as commented on by myself and others at the time.

Pretty much everything that appeared to run against common sense seems to have been fixed – with the passable exception that LL still insist of laying claim to the word “Life”. In particular Part 1h is gone from the document (good!) and Point 6a(ii) has been revised so that personal information such as rl name and address will not be published in the Viewer Directory. A minor niggle here is that it should be spelled out clearly in the Policy itself, but it is clarified in the accompanying FAQ.

Point 7a has been also  been cleaned-up. The original stated:

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 was a dangerously ambiguous statement and one that could be taken to read that the original developer will be held to account for each and every use their Viewer is put to – even if modified by others outside of their control. As such, this one statement, more than any other, served to potentially undermine the entire policy: who in their right mind would agree to such a clause when knowing full well anyone could maliciously seek to download, alter and use their code?

In the revised document Point 7a now reads:

You are responsible for all uses you make of Third-Party Viewers. If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute.

The difference is subtle, but it is there; The reference to features, functionality and code allow a distinction to be drawn between being a developer being held accountable for their “original” code and being responsible for modifications to said code made outside of their control. This should in theory be enough to allay fears in this direction.

Only it doesn’t. Many are still up in arms about the Policy, largely due to the manner in which Section 7 has been re-cut.

The problem here seems to be part technical and part social – and frankly, it is the Lab’s fault that the two issues have become confused inasmuch as they have chosen to draft a policy that intertwines the technical development of a Viewer and its means of distribution with its social use (Section 7, “Your Responsibility for Third Party Viewers” is actually now sub-titled “If You are a user or Developer of Third Party Viewers”).

The specific point that has upset some Viewer developers is Point 7d: You assume all risks, expenses, and defects of any Third-Party Viewers that you use, develop, or distribute (my emphasis).

The mixing of use with development and distribution of third-party Viewers creates an unfortunate ambiguity wherein this statement could be taken to mean that third-party Viewer developers could still be held accountable for the uses to which their code is put once it has passed beyond their control. This is clearly unfair.

While it could be argued that a user taking an established Viewer and tweaking it for malicious purposes could be regarded as “development” of the Viewer, the fact remains that such issues should really defined within the Terms of Service, which a) themselves relate to the use of both the Second Life service and the tools used to connect to it; and b) are actually likely to be read by users.

Both as a part of this blurring of use and development, and as a matter in its own right in terms of overall technical liability, several raising objections to Point 7d have done so specifically in terms of “GPL violations”. I have to admit, I don’t fully buy-in to their arguments, and I’m not absolutely certain any court would agree with their black/white view of the text of this Point because:

  • Linden Lab have sought to clarify the Policy with a FAQ, where the meaning of various clauses in the Policy are spelled out in lay terms. As a supporting document, complete with explanations given by Linden Lab themselves and presumably approved by their lawyers, the FAQ does have bearing in a court of law. As such, were Point 7d to result in a Viewer developer being held unduly to account for the use of their code, the FAQ could be used to counter any action
  • More importantly, no legal document stands in isolation. There is the established precedent of law and the forbearance of pre-existing agreements and understandings. As such, a court is unlikely to go against a Developer who has acted fully and completely both with the spirit of the GPL and this policy, simply on the basis of point 7d. In fact, in many respects, it is hard to see such a case reaching court
  • On the wider, more controversial front, many view GPL as automatically granting immunity under the terms of the agreement. This is actually not the case. Clause 16 of the GPL broadly absolves the developer from liability, it does so with the caveat of unless required by applicable law or agreed to in writing (my emphasis). Thus, and while some developers may howl and scream at me for saying so, LL are technically within their rights and within the spirit of the GPL to introduce whatever clauses they deem fit into their policy. While this is a cause for concern – as this is how LL are adding the onus of liability – it doesn’t prevent developers in turn limiting the extent of their exposure with an EULA that includes a mandatory agreement as a part of the Viewer installation process.

Thus, while there are problems with Section 7, I don’t actually believe they are insurmountable.

Ideally, the issue of confusing Viewer use with Viewer development would best be dealt with through Linden Lab simply redrafting the section to clearly differentiate between the responsibilities of the Developer and the responsibilities of the user (for example, have Point 7a list the responsibilities of the Developer as enumerated items (i, ii, iii, etc), followed by Point 7b giving a enumerated list of responsibilities for the user). Doing so would probably account for around 98% of the gnashing of teeth and wailing currently being evidenced.

That said, and failing any re-write of the TPV, developers still have recourse to the use of an EULA, as mentioned above. If I understand things correctly, doing so would not be in violation with the GPL. Such an agreement / licence statement would likely supersede  statements such as Point 7d in the TPV policy, given that by allowing such a Viewer to connect to the grid, Linden Lab are tacitly acknowledging the developer’s own Licence Agreement with their users.

One also wonders whether Linden Lab will actually be pro-active in blocking Viewers from accessing SL where the developers have not signed-up to the TPV.

That said, at the end of the day, the TPV seems less a matter of legal action and far more a matter of public perception. Take away the inadvertent ambiguity and the rest, and the Policy really hinges on two thing in order to “succeed” in its aim of reducing the risk of malicious Viewers connecting to the grid:

  • The unwillingness of people behind such Viewers to provide proof of identity to LL.
  • The unwillingness of users to go beyond the list of “compliant” third-party Viewers and use a Viewer which might be perceived as being malicious and result in their being banned from the system as a result.

As such, if both of these goals are achieved, or perceived to have been achieved, then the Policy can be regarded as a “success” – even if it does (sadly) come at the cost of some developers continuing with their efforts to provide better and more stable means for users to experience Second Life.