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

[Nigel T]

Josh,

I'll take a whack at changing the language to fit your suggestion.

Do folks believe it's a better solution that still meets the requirements?

Regards,

Nigel

On Tue, Oct 25, 2016 at 1:29 PM, Josh berkus <josh at postgresql.org> wrote:

> On 10/25/2016 09:56 AM, Nigel T wrote:
> >  Then again, the copyright conditions are asymmetric, thus I
> > cannot get rid of that blinking red light on my dashboard.
>
> But as Nigel points out, this is really no different than copyleft plus
> a CLA in its asymmetric effects.   While I'm hardly the biggest fan of
> dual-licensing (or copyleft), it's a reality for a lot of the software
> world right now.
>
> So, let's take my suggestion for simplifying the UPL.  That is, instead
> of its complicated contribute-back language, you have a license where:
>
> 1. the original core code from the named party is licensed UPL, which is
> copyleft.
>
> 2. any additions to this core code must be licensed Apache 2.0, and
> documented.
>
> While hardly ideal, from a *developer* perspective this is a big
> improvement over CLA+Dual, which is the common pattern.  I don't have to
> fill out a CLA (something which blocks contributors from many countries
> and employers).  I'm guaranteed that the collected work from public
> contributors will be available under a mix of Apache + UPL, even if the
> original company goes away.  And the company has more of an incentive to
> release everything it can under the UPL because of the limited risk in
> doing so.  Finally if I want to grab just one of the code additions
> without using the core code, it's Apache.
>
> There are basically two drawbacks I can see to the revised UPL as a
> developer:
>
> A. 15 years from now when the original company is gone or acquired and
> the code base has changed beyond recognition we'll still have funky
> composite licensing.
>
> B. The asymmetry is proof that this project is never going to be a
> community (which is also true of dual-licensing).
>
> Now, I can't speak to what's *legally* allowable; can one license
> require that additions to its copyrighted material be licensed under a
> different license?  I'm not an attorney.  But I don't see an inherent
> issue to a simplified version of this license.
>
> (I wouldn't support the license as-is because the language of it is
> baffling)
>
> --Josh Berkus
>
>
>
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20161025/d2860600/attachment.html>