<div dir="ltr">Josh,<div><br></div><div>I'll take a whack at changing the language to fit your suggestion.  </div><div><br></div><div>Do folks believe it's a better solution that still meets the requirements?</div><div><br></div><div>Regards,</div><div><br></div><div>Nigel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 1:29 PM, Josh berkus <span dir="ltr"><<a href="mailto:josh@postgresql.org" target="_blank">josh@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/25/2016 09:56 AM, Nigel T wrote:<br>
>  Then again, the copyright conditions are asymmetric, thus I<br>
> cannot get rid of that blinking red light on my dashboard.<br>
<br>
</span>But as Nigel points out, this is really no different than copyleft plus<br>
a CLA in its asymmetric effects.   While I'm hardly the biggest fan of<br>
dual-licensing (or copyleft), it's a reality for a lot of the software<br>
world right now.<br>
<br>
So, let's take my suggestion for simplifying the UPL.  That is, instead<br>
of its complicated contribute-back language, you have a license where:<br>
<br>
1. the original core code from the named party is licensed UPL, which is<br>
copyleft.<br>
<br>
2. any additions to this core code must be licensed Apache 2.0, and<br>
documented.<br>
<br>
While hardly ideal, from a *developer* perspective this is a big<br>
improvement over CLA+Dual, which is the common pattern.  I don't have to<br>
fill out a CLA (something which blocks contributors from many countries<br>
and employers).  I'm guaranteed that the collected work from public<br>
contributors will be available under a mix of Apache + UPL, even if the<br>
original company goes away.  And the company has more of an incentive to<br>
release everything it can under the UPL because of the limited risk in<br>
doing so.  Finally if I want to grab just one of the code additions<br>
without using the core code, it's Apache.<br>
<br>
There are basically two drawbacks I can see to the revised UPL as a<br>
developer:<br>
<br>
A. 15 years from now when the original company is gone or acquired and<br>
the code base has changed beyond recognition we'll still have funky<br>
composite licensing.<br>
<br>
B. The asymmetry is proof that this project is never going to be a<br>
community (which is also true of dual-licensing).<br>
<br>
Now, I can't speak to what's *legally* allowable; can one license<br>
require that additions to its copyrighted material be licensed under a<br>
different license?  I'm not an attorney.  But I don't see an inherent<br>
issue to a simplified version of this license.<br>
<br>
(I wouldn't support the license as-is because the language of it is<br>
baffling)<br>
<span class="HOEnZb"><font color="#888888"><br>
--Josh Berkus<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<wbr>_________________<br>
License-review mailing list<br>
<a href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review" rel="noreferrer" target="_blank">https://lists.opensource.org/<wbr>cgi-bin/mailman/listinfo/<wbr>license-review</a><br>
</div></div></blockquote></div><br></div>