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

Nigel T nigel.2048 at gmail.com
Mon Feb 27 22:03:06 UTC 2017


Henrik,

Nope :). Still the objective.

The Original Work is not dual licensed but exists only as UCL.  All
derivatives of the original work must be apache.  Should this be
explicitly spelled out in the license text itself or just the
supporting material?

If this doesn't apply to derivative works of derivative works then
that is an issue with this change.

We have built spectral signature software for the US government that I
would like to open source.  UCL provides that middle ground where I
can state to the stakeholders that any community built enhancements
would be able to be incorporated into the original work that would
remain closed source GOTS and potentially a commercially supported
product (which we don't do that very often).

Keeping the code for a commercial product closed source has been the
default option in the past.  There exists similar software, funded by
other governments (and their citizens), that is the basis for
expensive closed source products. I would like to change that.

There are pieces of the original work that won't be released under UCL
that is not freely distributed to entities outside the USG.  GPL isn't
a good alternative for the whole project as incorporating community
built GPL enhancements would require the distribution of the original
source code to anyone we give the binaries to that isn't part of the
federal government.

There are reasons the original sponsoring agency would not want to
distribute source.  The code is all unclassified but there are
portions that may be FOUO (For Official Use Only).  That requires that
the source is encrypted at rest and we can't distribute FOUO material
to foreign entities (at least under the guidelines we follow).
Compiled binaries can be decompiled but any FOUO comments in the
source won't appear.  How we do X isn't likely sensitive. Why we do X
may be.  So simple code obfuscation is good enough.

Under UCL though we can give the bulk of the code away under a
copyleft and any enhancements made in the commercial or academic world
can be folded back into the original GOTS system without licensing
concerns or need to manage a foundation or a CLA scheme.

I just don't want to convince my sponsor that open sourcing is a good
idea and then later on have to explain why we can't use stuff built on
what the government already paid for because the derivative work was
licensed under an incompatible (for his needs) license.

If all derivative works (including their derivatives) of the original
work must be apache then the original sponsor can use it.

Regards,

Nigel


Sent from my iPhone
> On Feb 24, 2017, at 3:18 AM, Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:
>
> Hi Nigel
>
> A couple questions about this revised UCL license:
>
> 1. Your original rationale for this submission was "To provide
> developers wishing to open source an existing closed source product
> with an Open Source license that is Copyleft for downstream developers
> and Permissive for upstream developers".
>
> Have you abandoned this goal? It seems to me this revised license is
> essentially Apache 2.0 for both upstream and downstream developers?
> (Recipients of derivative works could choose to drop UCL at any time,
> otoh it is not possible to drop the Apache license option, since it is
> hard coded into the UCL.)
>
> 2. Given this, why wouldn't a creator of an Original Work simply use
> Apache from the beginnng?
>
> 3. Sorry if this was already answered earlier, but: Are you working on
> behalf of someone that is looking to license some currently closed
> source software under this license? If yes, can you share who that is,
> and what the software in question is or could be?
>
> henrik



More information about the License-review mailing list