[License-review] Submission of the Upstream Compatibility License v1.0 (UCL-1.0) for approval
Nigel T
nigel.2048 at gmail.com
Fri Mar 31 15:10:11 UTC 2017
Oh, I forgot to say that I also wouldn't approval to be based on a
misunderstanding of the intent...
On Fri, Mar 31, 2017 at 11:05 AM, Nigel T <nigel.2048 at gmail.com> wrote:
> 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/8c26e42e/attachment.html>
More information about the License-review
mailing list