<div dir="ltr"><div>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.</div><div><br></div><div>henrik<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2019 at 4:44 PM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Henrik,</div><div><br></div><div>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.</div><div><br></div><div>Thanks,<br></div><div>Van<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2019 at 3:31 AM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?</div><div><br></div><div>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.<br></div><div><br></div><div>henrik<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 19, 2019 at 11:17 PM Brendan Hickey <<a href="mailto:brendan.m.hickey@gmail.com" target="_blank">brendan.m.hickey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">Brendan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 19, 2019, 16:04 Josh Berkus <<a href="mailto:josh@berkus.org" target="_blank">josh@berkus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/16/19 2:10 PM, Brendan Hickey wrote:<br>
> <br>
> We should regard upgrade clauses skeptically, particularly when the<br>
> license steward is the only user of the license. This language could be<br>
> used to generate a proprietary fork if the steward saw fit. The GPL at<br>
> least claims that revisions will be in the spirit of the original, AGPL<br>
> linking clause notwithstanding.<br>
<br>
I don't think that's significantly different. "in the spirit" is<br>
subjectively interpretatable, and can mean whatever the issuing entity<br>
wants it to mean.<br>
<br>
One key to this license, though, is that it really doesn't make sense<br>
without a nonprofit foundation as the issuing entity. I think that's<br>
something we can assert for all updatability clauses, really. With<br>
NGOs, we can generally trust the original NGO to have the public<br>
interest at heart. With individuals & for-profit corporations, we<br>
really can't.<br>
<br>
Now, we can't enforce that except via notes on the license at<br>
<a href="http://opensource.org" rel="noreferrer noreferrer" target="_blank">opensource.org</a>, of course.<br>
<br>
-- <br>
Josh Berkus<br>
</blockquote></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_3441585146380815914gmail-m_3444283962701256146gmail_signature"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div>