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

Nigel T nigel.2048 at gmail.com
Tue Oct 25 16:04:57 UTC 2016


On Tue, Oct 25, 2016 at 4:02 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 25/10/16 04:22, Nigel T wrote:
> > It's submitted as a special purpose license primarily because the
> > designed for use case is open sourcing an existing closed source
> > product.  The dual licensing with Apache for upstream gives that
> > developer the commercial safety of a strong copyleft release (commercial
> > competitors can't simply take their features and fold it into their own
> > product) without the hassle of herding a CLA process to keep
> > compatibility between the open and closed versions.
>
> And it's precisely this use (many would say "abuse") of copyleft to give
> special privileges to one particular party which is opposed by many in
> the free software world. The fact that it's a hassle to do does not mean
> the OSI needs to make it easier.
>

I was under the impression that dual commercial license + copyleft was a
valid FOSS business model and not "abuse".

The least amount of hassle is simply to not open source.

I'm not forced to open source and I don't think there is any competitive
advantage to do so.  So I'm thinking of open sourcing this moderately sized
codebase (about 100K worth of Java code) because it's a good thing to do.

But my requirements are:

   1. Folks can't take my work and make it closed source without purchasing
   a commercial license from me.
   2. I can use use extensions to my code if I do turn it into a product.
   I don't want to get locked out of improvements to my own code.

1 is met with OSL.
2 is met with Apache.

Mozilla has a policy of not signing CLAs with commercial entities where
> the software concerned is under a copyleft license, because we don't
> believe it's right to give away special privileges to one entity like
> this.



> If this license were approved, we would have to change our general
> "OK to use" licensing policy from "anything OSI-approved" to "anything
> OSI-approved apart from the Upstream Compatibility License".
>
> Gerv


You require committers to provide code under MPL 2.0.  How would UCL change
this?  From a use perspective I don't see how UCL restricts users rights.

The original author of any copyleft codebase, even under MPL, has the
ability to create a completely closed source fork.  No one else can.
Whether you believe this is a feature or a bug is a matter of opinion but
it seems to me an accepted part of the open source community. MySQL AB used
this to good effect, as did Netscape for a little while.  Mozilla decided
that NPL was bad but the FSF still acknowledges NPL as a Free License even
if one not recommended by them.

My opinion is that the OSI should be more inclusive of differing opinions
within the FOSS community.  That includes licenses that are more friendly
for commercial entities to maintain a business model that supports both
open and closed source.

I don't follow Firefox extensions much but I do recall that Mozilla decided
to make it impossible for users to install unsigned extensions for Firefox
48+ Release and Beta.  Mozilla can do this because it controls the Firefox
ecosystem and thereby has "special privileges" over other developers within
the ecosystem.  That's neither good nor bad.  It just is.  Extension
developers can accept this policy or not develop for the Firefox platform.

I don't see new projects using UCL a whole lot.  If there is no original
contribution of merit why would you want to?

I can see companies of all sizes releasing their proprietary code under
UCL...especially smaller ones (like say a 1 person shop) without the
bandwidth for managing an open source foundation and CLAs.  Reference
implementations might or might not find value in using UCL.

Hence special purpose.

Nigel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20161025/49f9eb8e/attachment.html>


More information about the License-review mailing list