[License-review] Submission of the Upstream Compatibility License v1.0 (UCL-1.0) for approval

Nigel T nigel.2048 at gmail.com
Wed Nov 30 06:03:32 UTC 2016


Richard,

Whatever other faults the license may have it's not hiding that the CLA is built in...it's the whole purpose of the license. :)

The asymmetric nature is also reflective of the greater code contribution of the upstream contributor.  I doubt anyone would adopt UCL in a greenfield project. It is primarily intended for releasing existing medium to large proprietary software products (100k+) as open source without needing to worry about CLAs, foundations, etc.  

Hence the submission as a special purpose license.

If it's a derivative work of your original release you get to fold those changes in without hassles.

The suggestion that all downstream changes must be Apache for everyone and not just the upstream developer while the original work remains UCL is okay too.

I can make that edit but then the changes will not have undergone legal review.

Nigel

> On Nov 29, 2016, at 8:34 PM, Richard Fontana <fontana at opensource.org> wrote:
> 
>> On Tue, Nov 29, 2016 at 12:13:43PM +0200, Henrik Ingo wrote:
>> The new contribution of this license seems to be that it tries to
>> capture within a single document both the open source license and the
>> upstream CLA (and I repeat, this is based on a superficial reading and
>> more to make a general point).
> 
> I think that is right and this actually explains some of the concern I
> have about this. The use of a CLA by a single-licensor copyleft
> project is going to be obvious to potential contributors. The UCL
> seems like it is taking the idea of a CLA but hiding it inside the
> license. Even someone who has no intention of contributing to the
> upstream project is doing the equivalent of signing a CLA merely by
> modifying the software and distributing the modifications to
> others. 
> 
> I agree somewhat with this argument you presented:
> 
>> - It could be argued that having a separate CLA, that contributors
>> must acknowledge by the act of signing it, is actually a preferable
>> process for asymmetric upstream contributions. It could very well be
>> undesirable to endorse a practice where a random contributor has given
>> away more rights than he himself gets by the mere act of sending a PR
>> to a github repo. IMO the established practice that you, for example,
>> agree to the GPL by way of contributing to a code base that is GPL, is
>> well justified because what you agree to give away is the same that
>> you received - and hypothetically understood to receive - by simply
>> using/copying the software. Even if you might not actually understand
>> the GPL, at least there's some fairness and balance that justifies
>> this process. OTOH it might be undesirable to create a situation where
>> developers contribute to some repository without understanding what
>> they are giving away, or even without understanding that there's an
>> asymmetric license in use. (For me personally this would be the
>> strongest, or only, argument against approval.)
> 
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review



More information about the License-review mailing list