[License-discuss] upgrade clauses & mandatory relicensing (was Re: Approval: Server Side Public License, Version 2 (SSPL v2))

Bradley M. Kuhn bkuhn at ebb.org
Thu Nov 22 17:01:11 UTC 2018


[ I'm moving this thread to license-discuss as I think it's Brendan's
  questions may be off topic enough from evaluating MongoDB

Brendan Hickey wrote:
>    Apart from the GPLs are there any other OSI approved licenses with an
>    upgrade clause?

The GPL (all versions) has an *optional* upgrade clause such that each
licensor can optionally exercise (choosing between GPLvN-or-later or
GPLvN-only).  Most copyleft licenses have a *mandatory* upgrade clause [0].

Historically, my understanding of the FSF policy [1] was that "no one should
be required to de-facto trust the FSF" as GPL's steward.  That is a good
principle, but introduced the practical problem of limiting software sharing
between different versions of -only-licensed material.

The GPLv3 added the "Proxy" clause as a compromise between the two polices:
licensors can name a single individual/entity who is not the FSF to decide
about future -or-later relicensing, so that a change from -only to -or-later
need not require every copyright holder to agree (if a proxy is named).

> I'm generally skeptical of upgrade clauses.

You mostly criticize the FSF on this point in your post, but as explained
above, most copyleft license stewards, such as Oracle (CDDL), Mozilla (MPL)
and Eclipse (EPL) are much more aggressive with upgrade than other stewards.
Your post started with a question (quoted above), so I suspect you didn't
realize that that these other licenses had mandatory [0] upgrade clauses.
Now that I've explained, I'm curious to know what your view is on these
upgrade clauses, particularly mandatory vs. optional ones?

IMO, the question here is whether MongoDB is really experienced enough to be
a trusted license steward -- given that they've only been engaged in that
activity for 36 days.  I think if we trust the license steward, the upgrade
clause question is really just a matter of taste.  I have no problem with an
upgrade clause with a license steward who has earned the community's trust.


Meanwhile, Kyle Mitchell wrote:
>> Software developers, including companies that develop software, have the
>> right to license their own, original work on terms of their choice.

The "right to choose the license" is not a right, it's a privilege of power,
granted by a legal system that not everyone in the FLOSS community agrees
with.  I try not to link to external writings of my own in my posts here, but
I'll make an exception for this one (which is the only essay I ever co-wrote
with RMS) as it so on-point to what you said:
https://www.gnu.org/philosophy/freedom-or-power.en.html

(It was originally published in 2001 as a response to Tim O'Reilly's article
making the same argument you made above.)

In short, the "right for copyright holders to pick the license they want" is
not an inalienable right, nor should it be.

Kyle quoted Eliot saying:
>> Eliot mentioned very early on:
>>>  If it is not what all communities want, then is it enough that some do?

Right now, the only people I've found who are in the "community that wants
the SS Public License" are you personally and MongoDB.  One person and one
company don't make a community.  Users of MongoDB have widely been alarmed by
this change and critical of it.  You have argued that it's MongoDB's
prerogative as copyright holder to change the license capriciously if they'd
like, and it's true as far as it goes, but I don't think that's a salient
point to OSI's analysis of the license.

[0] By mandatory, I mean that the original licensor may not prohibit later
    downstream redistributors from distributing the copyrighted material
    under newer versions of the license published by the license steward.

[1] I do not speak for the FSF on this matter, that's just my understanding.

--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/



More information about the License-discuss mailing list