[License-review] For Legacy Approval: OpenLDAP Public License

[Henrik Ingo]

The upgrade clause should of course be "at your option, a later version". A
user or fork needs to always have the choice of staying on the original
version for code that was released before the undesired change.

henrik

On Tue, Aug 20, 2019 at 4:44 PM VanL <van.lindberg at gmail.com> wrote:

> Hi Henrik,
>
> An upgrade clause allows a licensor who is the license steward to
> arbitrarily change terms in the license - for example changing a BSDish
> license to a GPLish one. All licensees would automatically have "accepted"
> the applicability of the new terms.
>
> Thanks,
> Van
>
> On Tue, Aug 20, 2019 at 3:31 AM Henrik Ingo <henrik.ingo at avoinelama.fi>
> wrote:
>
>> I'm not quite following here... A BSD style license allows me to do
>> pretty much anything with downstream software anyway. How can an upgrade
>> clause be an issue?
>>
>> With copyleft licenses there's a clear need to trust that rules and
>> requirements stay the same for all parties - that requirements aren't
>> removed. What is the problem for a BSD-style license? There's nothing to
>> remove, and adding limitations is not a problem, because you can just use
>> the old license.
>>
>> henrik
>>
>> On Mon, Aug 19, 2019 at 11:17 PM Brendan Hickey <
>> brendan.m.hickey at gmail.com> wrote:
>>
>>> The OpenLDAP Foundation is a non-profit. Still, I think we need to draw
>>> a distinction between narrowly and broadly focused groups. With reasonable
>>> certainty we can say that the FSF isn't going to write the GPLv4 to demand
>>> royalty payments to the SCO (even if they did decide to co-opt the works of
>>> GPLv2+ users for the benefit of the AGPL). A single user license is
>>> inherently more susceptible to the whims of a sponsor.  With someone else
>>> in the driver's seat the AGPLv3 probably would've transformed seamlessly
>>> into the SSPL.
>>>
>>> Brendan
>>>
>>> On Mon, Aug 19, 2019, 16:04 Josh Berkus <josh at berkus.org> wrote:
>>>
>>>> On 8/16/19 2:10 PM, Brendan Hickey wrote:
>>>> >
>>>> > We should regard upgrade clauses skeptically, particularly when the
>>>> > license steward is the only user of the license. This language could
>>>> be
>>>> > used to generate a proprietary fork if the steward saw fit. The GPL at
>>>> > least claims that revisions will be in the spirit of the original,
>>>> AGPL
>>>> > linking clause notwithstanding.
>>>>
>>>> I don't think that's significantly different. "in the spirit" is
>>>> subjectively interpretatable, and can mean whatever the issuing entity
>>>> wants it to mean.
>>>>
>>>> One key to this license, though, is that it really doesn't make sense
>>>> without a nonprofit foundation as the issuing entity.  I think that's
>>>> something we can assert for all updatability clauses, really.  With
>>>> NGOs, we can generally trust the original NGO to have the public
>>>> interest at heart.  With individuals & for-profit corporations, we
>>>> really can't.
>>>>
>>>> Now, we can't enforce that except via notes on the license at
>>>> opensource.org, of course.
>>>>
>>>> --
>>>> Josh Berkus
>>>>
>>> _______________________________________________
>>> License-review mailing list
>>> License-review at lists.opensource.org
>>>
>>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>>
>>
>>
>> --
>> henrik.ingo at avoinelama.fi
>> +358-40-5697354        skype: henrik.ingo            irc: hingo
>> www.openlife.cc
>>
>> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>
>

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190820/eb81a74e/attachment-0001.html>