[License-review] Request for Approval of Universal Permissive License (UPL)

Jim Wright jim.wright at oracle.com
Tue Apr 15 09:50:04 UTC 2014


Responses inline.

 Regards,
  Jim

On Apr 14, 2014, at 3:19 AM, Gervase Markham <gerv at mozilla.org> wrote:

> Hi Jim,
> 
> On 13/04/14 18:55, Jim Wright wrote:
>> On Apr 11, 2014, at 6:02 AM, Gervase Markham <gerv at mozilla.org>
>> wrote:
>>> Did you consider forking the Apache license with an additional 
>>> GPL-2-relicensing permissions grant clause?
>> 
>> Unfortunately this is much less clean - then you're distributing 3rd 
>> party GPL code, which has different implications for everyone
>> involved, and also the patent grant does not cover the entire work
>> you're contributing to if it's not licensed under the Apache license,
>> which in the case of proprietary code it usually isn't.
> 
> I don't quite understand your response. What do you mean by "then you're
> distributing 3rd party GPL code"?
> 
> Say you release some software under the UPL. The point of the UPL is
> that the code can be used anywhere (including in GPLed software). What
> would be different, and worse, if you instead chose the Apache license?
> Answer: no GPLv2-only compat. So what would be different, and worse, if
> you instead chose the Apache license with specific GPLv2-only compat?
> 
> Surely, apart from the GPL-compat question, any objections to my
> modified Apache idea would also be objections to straight Apache?


They're separate objections actually.  The patent license in the Apache license is materially narrower than the license here, so yes, that *is* an objection to straight Apache - in a case where you're contributing to a work under proprietary terms, the patent license only covers the contribution under the ASL and not the broader work.  

But there's also the issue of introducing 3rd party GPL code to products that may not have any - if I take a contribution under UPL, and someone violates the GPL on OpenJDK but not the UPL, I can freely work with that party to fix the situation.  If there's third party GPL code in there, once I've accused them of a GPL violation, some would certainly argue that I can't fully restore their GPL license because the termination for breach of the GPL applies to that third party GPL code as well and separately, and if I'm not the copyright holder in that code and cannot sublicense it because of the way the GPL works, their license cannot be fully restored without separately interacting with the copyright holder in that other code.



> 
> 
>>> Does hereunder mean "written further down in this file", or "under
>>> this license"?
>> 
>> Under this license.  (Apologies for legalese. :-)
> 
> Please do de-legalese that; I think it's confusing.
> 
>> It certainly doesn't stop anyone from dual licensing the doc under
>> some other license, CC or otherwise, which may not be a bad idea for
>> some applications, but yes, you're correct, the licensor is granting
>> all the same rights in the included documentation that they are in
>> the code, as we want to make sure that anyone using this as a
>> contribution agreement gets the full set of rights in the entire
>> contribution and doesn't have to try to sort out different licenses
>> to specs or other doc, data, etc. that are included with the
>> Software.
> 
> I see your point here; I agree that "code under license A; docs under
> license B" is a problem if you then want to copy code into docs, or docs
> into code.
> 
>>> Could you explain the rationale behind a specific list of larger
>>> works? The admin of such a list sounds like a pain.
>> 
>> The idea here is that the original authors of the Software 
> 
> So, before you go on... it seems to me that in both this answer and
> others in your thread, you have in mind a model of software where there
> are Original Authors, and then everyone else. The Original Authors set
> up how things are going to work, and everyone else runs with it.
> 
> Thing is, this way of thinking about software doesn't match the modern
> world, where things are cut, excerpted, remixed, recombined, forked and
> twisted into new shapes on a regular basis. If my codebase contains 500
> lines of your project's code spread across 6 different files, plus 5000
> lines of my code, plus 300 lines of someone else's... who are the
> Original Authors of the work? If one of the contributing bits of
> software has a LARGER_WORKS.TXT, does it carry over? What happens if two
> contributing bits have different LARGER_WORKS.txt files? I can't just
> make a unified file. But how can I keep them separate in any
> understandable way, particularly if code from the two different projects
> has ended up in the same files?
> 
> I understand that this is part of the additional permissions for
> patents, and if the mechanism broke down, you'd be simply back to
> something MIT-like. But the patent stuff is what this license has over
> the MIT license, so it needs to work well in practice.
> 

Unfortunately I think this problem is not easily solvable and I didn't want to boil the ocean here.  The same issue crops up if you have an MIT license to some code and mix and match it with Apache code - you can end up with different licenses to different pieces of the same component, some subject to an express patent license with particular terms and some not.  I can't fix *everything* here.  :-)  If someone alters the larger works file (or even if this concept was in the primary file rather than pushed out), you have a license of a different scope, just like you would if you added additional permissions to something under the GPLv3 - you would have to give the user each license including the larger works file and they would have to understand that they have different rights to the different pieces.





> Gerv
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review




More information about the License-review mailing list