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.