[opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers

[Morgaine]

Thanks Maya, and Boy!

I'm very glad to hear that there is still a month to go.

In that case one can still live in hope that LL might reconsider and rewrite
the policy into something reasonable and unambiguously GPL-compliant for SL
TPV developers.   There's still time.


Morgaine.




================================

On Tue, Mar 30, 2010 at 5:53 AM, Boy Lane <boy.lane at yahoo.com> wrote:

>  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 <morgaine.dinova at googlemail.com>
> *To:* opensource-dev at lists.secondlife.com
> *Cc:* Boy Lane <boy.lane at yahoo.com> ; Ryan McDougall <sempuki1 at gmail.com>
> *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<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001195.html>
> .
>
> 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<https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001263.html>
> .
>
> 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:
>
>
>    - 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.
>
>
>    - 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.
>
>
>    - 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 <sempuki1 at 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.dinova at googlemail.com> wrote:
>> > On Wed, Mar 24, 2010 at 2:57 AM, Joe Linden <joe at 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 <joe at 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.dinova at 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.lane at 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 at 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 <sempuki1 at 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 <joe at 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 <
>> sempuki1 at 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
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100330/7e47b9e6/attachment-0001.htm