Small correction here, according to the FAQ the commencement date of TPV is 30
April, so one more month from now on.
----- Original Message -----
From: Morgaine
To: opensource-dev@lists.secondlife.com
Cc: Boy Lane ; Ryan McDougall
Sent: Tuesday, March 30, 2010 10:36 AM
Subject: A note on preserving "NO WARRANTY" for SL TPV developers
In this note I'll identify 3 simple scenarios in which TPV developers can
retain some confidence that the "NO WARRANTY" clauses of their open licenses
remain intact. This is a technical reading of GPLv2 and similar licenses which
developers can verify for themselves, rather than a legal reading of the TPV
which Q Linden explained was beyond our ability to understand.
The 1st of April is approaching rapidly, and April Fool aside, this is also
the date on which the Linden TPV policy comes into effect.
That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 of GPLv2
as they apply to TPV developers, by imposing numerous conditions and
liabilities upon them. It is important that developers of TPVs realize the
possible personal dangers to themselves that may result from loss of "NO
WARRANTY" protection, so that they can make a personal decision about TPV
development on 1st April and thereafter. Boy Lane gave a well reasoned summary
of the situation here.
To address a small part of the uncertainty created by TPV, I'll make some
simple technical observations on how to preserve the "NO WARRANTY" protections
of your open sources licenses if you are a TPV developer whose viewers are used
in SL by others. No part of this note is legal advice (obviously), but under
the assumption that law occasionally tries to be logical, it may help
developers separate what is relatively certain from what is highly uncertain.
The most important point to appreciate is that LL has no power to void the
"NO WARRANTY" clause on any open source license not issued by them, or issued
by them prior to 1st April 2010.
This means that the following 3 developer scenarios seem quite safe from the
standpoint of their "NO WARRANTY" clauses surviving any attack:
a.. When a viewer project is licensed under BSD, Apache, MIT, GPLv3, LGPL,
or any other license other than GPLv2, this is clearly not the license granted
by LL and therefore its "NO WARRANTY" protections cannot be overridden by LL.
LL is not the licensor in this case.
a.. When a viewer project is an independent project licensed by the
project's developers under GPLv2 but does not use any Linden source code at
all, then the license (together with its "NO WARRANTY" freedom) is being
offered and granted by those developers, and it is clearly not being offered
and granted by LL. Consequently LL has no say over the "NO WARRANTY"
protections provided in a GPLv2 license that is granted by someone else in such
an independent project. LL is not the licensor in this case.
a.. When a project creates a TPV based on Linden sources released by LL
under GPLv2 prior to 1st April 2010, those sources are not encumbered by LL's
TPV document, but instead are licensed under the normal terms of a valid GPLv2
at the time that they were released. This is because GPL licenses are
non-revocable, and therefore the entire GPLv2 license (including its "NO
WARRANTY" clauses) which was valid upon release remains valid for all eternity.
As a result, TPV developers are protected by their GPLv2 "NO WARRANTY"
clauses, as long as they do not use any LL sources released on or after 1st
April 2010. LL is the licensor in this case, but the GPLv2 "NO WARRANTY"
protection was granted to you by Linden Lab themselves prior to the TPV
possibly affecting it, and that granted license cannot be revoked, ever.
In the above 3 cases, LL has no means of overriding the "NO WARRANTY"
protections in the respective licenses. (Read GPLv2 clauses 11-12 carefully
though, because they protect you only from certain types of liability, not
everything.)
In contrast, any other TPV scenarios are highly dependent on interpretation
of the ambiguous TPV document, and hence developer protection under those
conditions is very uncertain. It would have to be decided in court, and I
would not wish to second guess the outcome. Much caution is advised, and even
these purely technical observations should be examined carefully, and followed
at your own risk only if you think they are accurate.
I reiterate that the above is not legal advice, but only a technical analysis
given the very well known terms of the major open source licenses. The GPL is
particularly strong, and it has finally received testing in court in recent
years, so relying on its strength to provide "NO WARRANTY" protection for open
source developers is probably a reasonable idea. On 1st April, the situation
may change though.
Morgaine.
================================
On Thu, Mar 25, 2010 at 6:36 AM, Ryan McDougall <sempu...@gmail.com> wrote:
I think it's pretty clear LL will broach no more discussion on this
matter, as the only people complaining are "non contributors" -- as
clear a statement yet that realXtend and OpenSim are not considered
contributions to SL.
As far as I'm concerned, this is a complete FUD own-goal, and
realXtend now has a policy that developers cannot use our own viewer
to connect to SL for any reason -- to protect us from this
ill-conceived policy.
The only people who have nothing to fear from TPV are malicious
developers, as they were always operating outside various laws any
way.
Cheers,
On Wed, Mar 24, 2010 at 6:10 PM, Morgaine
<morgaine.din...@googlemail.com> wrote:
> On Wed, Mar 24, 2010 at 2:57 AM, Joe Linden <j...@lindenlab.com> wrote:
>>
>> There is no "catch 22" here. No "overstepping", and no rocket science.
>> The terms of the GPL are clear and well understood. The arguments around
>> clauses 11 and 12 of the GPL are completely baseless.
>
> Here are GPLv2 clauses 11 and 12, Joe. Which arguments around these
clauses
> are completely baseless?
>
> NO WARRANTY
>
> 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR
> THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
> OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
> PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
> OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO
> THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
> PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
> CORRECTION.
>
> 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
> WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
> REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
> INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING
> OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO
> LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
OR
> THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
> PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGES.
>
> The "NO WARRANTY" section of the GPL is one of the clearest and most
> understandable parts of the license. When software is developed under the
> GPL, these clauses are not optional, they are part of the license, and
they
> are also part of the license when those developers create viewers
expressly
> for use in SL.
>
> Developers who create viewers for use in SL are not second class GPL
> citizens. The entirety of the license applies to them too, including
clause
> 6 about "no further restrictions" and the two "NO WARRANTY" clauses.
>
> Failure to grant SL developers the "NO WARRANTY" of clauses 11-12 means
that
> you cannot license your software to them under GPL. It's as simple as
that.
>
>
> Morgaine.
>
>
>
>
>
> ====================================
>
> On Wed, Mar 24, 2010 at 2:57 AM, Joe Linden <j...@lindenlab.com> wrote:
>>
>> Let me take just one more crack at explaining the situation here, then
>> I'll let the TPV Policy document stand on it's own.
>>
>> First, the Linden Lab viewer source code is being made available to all
>> under the terms of the GPLv2 License. Nothing has changed that, and the
>> policy doesn't modify, enhance, or limit your rights or obligations under
>> the GPL.
>>
>> The TPV Policy is designed to set access conditions and terms for
>> developers and users of viewer binaries that connect to the Second Life
>> grid, whether produced from code licensed under the GPL or not. Note
that
>> the definition of TPV in that document stipulates that these are viewers
>> that actually connect to the SL grid, not those that may be capable of it
>> but are never used to log in.
>>
>> If a developer of a TPV never uses it to connect to SL, there is nothing
>> in that document that applies to them. Period. By the same token, if
that
>> viewer is designed and intended to be used to access the Second Life
grid(s)
>> there are responsibilities that follow, both for users of those viewers
and
>> for developers.
>>
>> Surely no one here is making an argument that a viewer that is designed
to
>> transmit user passwords (encrypted or otherwise) back to the author or
the
>> author's proxies should be allowed to the connect to the SL grid at will
and
>> without responsibility on the part of the author? Or that Linden Lab
should
>> just allow unbridled use of viewers that are designed to bring down
>> simulators through dos vectors, expressly designed to crash viewers
>> repeatedly, or bypass the intent and purpose of the in-world permission
>> system? Those aren't rhetorical questions.
>>
>> There is no "catch 22" here. No "overstepping", and no rocket science.
>> The terms of the GPL are clear and well understood. The arguments around
>> clauses 11 and 12 of the GPL are completely baseless.
>>
>> I've seen some very dramatic "exits" from the SL open source program here
>> in this thread by people who have never contributed. We're making a
number
>> of changes to the practice and policy of what we will permit to connect
to
>> our grid so we can invest in a richer conversation with the contributors
who
>> are interested in innovating in this space with us. The decision to
work
>> with us as we redouble our efforts to create a more meaningful program is
>> one each contributor will have to make. But, we're committed to moving
>> forward with those who are willing to accept a reasonable level of
>> responsibility for what they create. That's what the TPV Policy and
Viewer
>> Directory programs are about.
>>
>> The code is licensed under GPLv2 and that isn't going to change.
>>
>> This thread has become a zero sum game for all participants, so I look
>> forward to more generative conversation with those of you who are
sticking
>> around for the next one.
>>
>> -- joe
>>
>> p.s. I have a suspicion this reply will be parsed to the same degree all
>> other responses have been, but I'm not going to recurse on the subject,
and
>> I'm not going to make excuses. Please keep the conversation here civil
for
>> everyone.
>>
>>
>> On Tue, Mar 23, 2010 at 6:24 PM, Morgaine
<morgaine.din...@googlemail.com>
>> wrote:
>>>
>>> [CC Philip]
>>>
>>> Boy Lane's article is the clearest summary of the whole sorry situation
>>> so far.
>>>
>>> I hope that his very accurate analysis is handed to someone at high
level
>>> in LL, because it is clear that no Lindens on this list are able or
willing
>>> to engage in the matter. The lawyers behind the scenes at LL appear to
be
>>> truly out of control, and uncaring of the mammoth GPL non-compliance of
what
>>> they have written.
>>>
>>> I have CC'd this post to Philip Linden, because being at arm's length
>>> from the Lab nowadays, perhaps he can see more clearly than some how
far the
>>> situation has deteriorated from the original vision of an open client
and an
>>> ecosystem of GPL developers.
>>>
>>> Boy Lane's article is enclosed.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>>
>>> =================================
>>>
>>> On Tue, Mar 23, 2010 at 12:34 PM, Boy Lane <boy.l...@yahoo.com> wrote:
>>>>
>>>> I've put my summary about TVP on my blog
>>>>
http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>>>>
>>>>
>>>> Linden Lab's final 3rd Party Viewer Policy (TPV)
>>>> TUESDAY, 23. MARCH 2010, 19:15:03
>>>>
>>>> A lot of things are changing, I've voiced my opinion several times, and
>>>> I want to summarize here what I think about Linden Lab's 3rd Party
Viewer
>>>> Policy (TVP) that can be found here: Policy on Third-Party Viewers |
Second
>>>> Life
>>>>
>>>> Under assumption of common sense LL produced guidelines that should
>>>> regulate and control the way people can connect to their service, that
is
>>>> the SecondLife grid. Guidelines which would be correct under the
aspect of
>>>> common sense and I believe LL came from that perspective by initially
>>>> creating that guidelines in form of the 3rd Party Viewer Policy.
>>>>
>>>> What went wrong? They gave it in the hands of JohnDoe Linden lawyers
who
>>>> obviously missed the subject completley and overstepped ridiculously.
But
>>>> let's get down to the roots.
>>>>
>>>> Basically there are 2 core things very wrong with it. Initially LL
>>>> requires everyone to comply to the GPL licensing. Which is fine as
that sets
>>>> the context. The GPL clearly states a developer has no warranty or
liability
>>>> for the code whatsover, even if that means ones viewer starts a
nuclear war
>>>> against former Soviet Russia or China or both. That clause is included
in
>>>> every single file of sourcecode (not the part about the Russians or
Chinese
>>>> ). LL explicitely disclaims any liability themselves for the resulting
world
>>>> war but then puts exactly that liability back on the shoulders of
anyone
>>>> developing a viewer.
>>>>
>>>> Not only that, by complying to their TPV a developer would also accept
>>>> universal responsibility for all and everything "viewer". To be exact,
as a
>>>> developer "You assume all risks, expenses, and defects of any
Third-Party
>>>> Viewers that you use, develop, or distribute." A viewer does not even
need
>>>> to be able or connect to SL for that.
>>>>
>>>> In this regard it does not matter if a JohnDoe Linden comments on a
>>>> mailing list or if a legally not binding FAQ tells us that this would
be
>>>> only for usage by connecting to the SL grid. It is not. TPV in it's
current
>>>> form says "I'm responsible (read: guilty) for using, developing or
>>>> distributing any 3rd party viewer".
>>>>
>>>> Already by simply developing I'm assuming full responsibility for
>>>> everything. I could take the official LL sources and compile and
distribute
>>>> a sourcewise identical "official" viewer, without changing a single
line of
>>>> code; but with all the bugs and vulnerabilities *made by LL*. Guilty
by TPV.
>>>> It's really ridiculous.
>>>>
>>>> This is a clear violation of the in the first place by LL required GPL
>>>> licensing. It puts further restrictions on developers GPL explicitly
>>>> prohibits.
>>>>
>>>> Another point of concern, putting up the RL details (which is pointless
>>>> as LL has them already and require them by ToS) is required for a
listing in
>>>> the viewer directory. The details of the two guinea pigs who registered
>>>> (Kirsten's, Metabolt) were promptly published for a day before someone
in LL
>>>> pressed the emergency button. But that was not the first time that LL
>>>> distributed private details.
>>>>
>>>> In summary, the policy is legal-technical flawed and not acceptable by
>>>> any dev in their right mind. What it will achieve is the destruction
of any
>>>> *legal* 3rd party viewer; which probably is the (by some welcomed)
goal of
>>>> LL to close-source the viewer. It will not do anything to stop
malicious
>>>> clients to flourish, the Neils give a shit on policies or licenses.
>>>>
>>>> The consequence is that no 3rd party developer that uses LL's GPLed
>>>> sources (including already registered KLee or famed Emerald) can
produce a
>>>> legitimate viewer that is either compliant to GPL and/or violates TPV
(which
>>>> says it must be GPL compliant). Both are mutually exclusive and LL
created a
>>>> nice legal chicken and egg scenario.
>>>>
>>>> In my opinion there are only 3 possible solutions:
>>>> 1) use LL's code and violate TPV
>>>> 2) create a viewer from scratch using BSD or another license and comply
>>>> to TPV
>>>> 3) stop developing 3rd party viewers
>>>>
>>>> Linden Lab already said they do not plan to update their policy again.
>>>> Therefore only option 3 remains.
>>>>
>>>> Luv,
>>>> Boy
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Joe Linden
>>>> To: Ryan McDougall
>>>> Cc: Argent Stonecutter ; Boy Lane ; opensource-dev@lists.secondlife.com
>>>> Sent: Monday, March 22, 2010 3:53 AM
>>>> Subject: Re: [opensource-dev] Third party viewer policy: commencement
>>>> date
>>>> As I've stated repeatedly, the TPV policy governs viewers that connect
>>>> to the SL grid. The policy document as worded is explicit about the
>>>> requirements for developers and for users of TPVs that connect to the
SL
>>>> grid.
>>>>
>>>> That probably sums up what I have to say about it today, so I'm only
>>>> admitting that I'm going to use the rest of this Sunday to get some
fresh
>>>> air.
>>>>
>>>> Cheers,
>>>> -- joe
>>>>
>>>> On Sun, Mar 21, 2010 at 12:47 PM, Ryan McDougall <sempu...@gmail.com>
>>>> wrote:
>>>>>
>>>>> So for any malicious viewer developer, all he needs to do to avoid
>>>>> sanction under the TPV policy is claim his viewer has no intention of
>>>>> connecting to SL?
>>>>>
>>>>> Or are you admitting that you cannot create a terms of use/service
>>>>> policy that somehow obligates viewer developers to jump though your
>>>>> hoops?
>>>>>
>>>>> You should separate the obligations of users and developers, and make
>>>>> clear the punishments for non-compliance for each.
>>>>>
>>>>> As it is, one would be prudent to assume LL reserves the right to take
>>>>> direct legal action against developers, which is quite frankly scary
>>>>> for small open source developers.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> On Sun, Mar 21, 2010 at 9:19 PM, Joe Linden <j...@lindenlab.com>
wrote:
>>>>> > No, it only governs viewers that actually do connect to the SL grid,
>>>>> > not
>>>>> > those that are capable of doing so (but don't.)
>>>>> >
>>>>> > On Sun, Mar 21, 2010 at 11:59 AM, Ryan McDougall
<sempu...@gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> If so, in effect, the TPV policy governs all SL protocols?
>>>>> >>
>>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> Policies and (un)subscribe information available here:
>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>>> Please read the policies before posting to keep unmoderated posting
>>>> privileges
>>>
>>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
