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

[Nigel T]

Henrik,

Oops, I did accidentally reply vs reply all.  Thanks!

You are correct that it may not be the common understanding and I almost
reverted to submitting the original version but I think my interpretation
is correct.  I sent a quick note to Larry to see if he would weigh in but I
would appreciate it if any other lawyers on this list provides general
comments on the two articles below on the general topic and not necessarily
provide any legal advice for this specific instance... :)

https://www.legalzoom.com/articles/what-are-derivative-
works-under-copyright-law

THE DERIVATIVE WORKS. IN PARTICULAR, THE SEQUEL OF A …
<http://www.cerdi.u-psud.fr/wp-content/uploads/2013/05/A-Castronovo.ppt>

As far as how most would read the license the intent is not to trick
anyone.  If it is sufficient that this be covered in a FAQ I will do that
or if folks prefer I can put in a pre-amble to the top of the license. That
would be quick and I could do that later today.

I would hope that any descriptive text either at the OSI or at FSF would
cover this unless it is actually an incorrect interpretation...

Nigel

On Fri, Mar 31, 2017 at 10:51 AM, Henrik Ingo <henrik.ingo at avoinelama.fi>
wrote:

> (Did you omit list on purpose? Feel free to add it back.)
>
> Ok, I see how you're thinking, but I don't think that's how most would
> read the license. IMO the common usage of those terms would be:
>
> Original Work = the unmodified upstream work
> (Your) Changes = changes I made to the Original Work
> Derivative Work = Original Work + Changes
>
> Therefore, I could make a trivial change to the Original Work, and
> after this, all of the Original Work (plus some trivial change) is
> licensed under Apache License.
>
> Note that I agree with your explanation of who owns copyright to which
> part. It's just that I don't think the common interpretation of
> Derivative Work is as you have intended.
>
> henrik
>
>
> On Fri, Mar 31, 2017 at 5:24 PM, Nigel T <nigel.2048 at gmail.com> wrote:
> > Henrik,
> >
> > I can't recall if I responded but I believe that this is incorrect.  The
> > author of the derivative work holds copyright to the new elements in the
> new
> > work but the original author retains copyright of the original.  To
> obtain a
> > copyright from the original author you must depend on the rights granted
> > under UCL and not under Apache.
> >
> > I base this opinion on the discussions of who owns the copyrights in
> movies
> > when a sequel is created.  For example when the Superman movie is created
> > based on the pre-existing Superman character the producers of the movie
> only
> > owns any new characters and elements created in that derivative.  For
> > someone to make Superman II the copyright owner of the original comic
> book
> > character must provide a license and the owners of the Superman movie
> must
> > provide a license to any new characters (paraphrased from legal zoom).
> >
> > https://www.legalzoom.com/articles/what-are-derivative-
> works-under-copyright-law
> >
> > THE DERIVATIVE WORKS. IN PARTICULAR, THE SEQUEL OF A …
> >
> > Regards,
> >
> > Nigel
> >
> >
> >
> >
> >
> > On Tue, Feb 28, 2017 at 6:00 AM, Henrik Ingo <henrik.ingo at avoinelama.fi>
> > wrote:
> >>
> >> Nigel
> >>
> >> Thank you for your extensive explanation of your motivations.
> >>
> >> It seems this license makes sense to you, and there could be some
> >> government sponsored code that could be open sourced under it. I also
> >> think it is trivially the case that this should be accepted by the
> >> open source community, since for the downstream users it is
> >> essentially Apache licensed and they could drop the UCL license if
> >> they choose to do so.
> >>
> >> Just for the sake of clarity: You do realize, that a recipient of UCL
> >> software could create a derivative work, drop the UCL license, and
> >> just use the Apache license. Another recipient of that derivative work
> >> could then take the entirety of the code, now licensed under Apache
> >> license, and add new features that would remain closed source. The
> >> Apache license allows this. So this second recipient of the code is no
> >> longer obligated to share his derivative work with the creator of the
> >> original work (you).
> >>
> >> henrik
> >>
> >>
> >>
> >> On Tue, Feb 28, 2017 at 12:03 AM, Nigel T <nigel.2048 at gmail.com> wrote:
> >> > 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
> >>
> >>
> >>
> >> --
> >> henrik.ingo at avoinelama.fi
> >> +358-40-5697354        skype: henrik.ingo            irc: hingo
> >> www.openlife.cc
> >>
> >> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
> >
> >
>
>
>
> --
> henrik.ingo at avoinelama.fi
> +358-40-5697354        skype: henrik.ingo            irc: hingo
> www.openlife.cc
>
> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20170331/8e4a5224/attachment.html>