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

[Jim Wright]

Responses inline.

 Regards,
  Jim

On Apr 15, 2014, at 8:38 AM, Gervase Markham <gerv at mozilla.org> wrote:

> Hi Jim,
> 
> On 15/04/14 10:50, Jim Wright wrote:
>> 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.
> 
> Maybe I've not quite understood this.
> 
> Are you saying that if I contribute a one-line patch to a piece of UPL
> code, and that UPL code is used in the Java SDK and lists "Java SDK" in
> its LARGER_WORKS.TXT file, I have just freely licensed any patent I or
> my company owns that covers anything in the Java SDK?
> 
> That seems... broad.

Yes, indeed it is, and by design.  If you're contributing to a work using this as a contributor agreement via specification in the Larger Works file, your patents are being licensed for use in that work.  (And I wouldn't go nearly as far as Richard just did in his followup message, as most licensees here are unlikely to merge all of their products into the larger work, which is what would be required for this to be equivalent of licensing all patents for all purposes, but future versions of the same project, yes, those are intended to be covered and I think that's clear by virtue of expressly stating that future versions are covered.)


>> 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.
> 
> Sorry if I'm being dense, but I can't make head or tail of that :-((
> What has 3rd party GPLed code going into (or not going into) OpenJDK got
> to do with deciding whether the UPL is equivalent to, better than or
> worse than Apache+GPLv2-only-clause?

Because you licensing the code under both Apache and GPLv2-only means that what is going into my GPLed package is a piece of code licensed from you under the GPLv2, and subject to those rights and restrictions.  I can't then restore someone's rights if they breach the GPL for that package, as I'm not the only licensor under the GPL - only you can restore as to your own GPLed code.  Thus trying to fix compliance problems with anyone gets substantially more difficult and complicated.  (Remember that's not the only difference though, the Apache patent license is much narrower for this purpose, not licensing the work into which the code is to be incorporated.)


> 
>> 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.  :-)
> 
> Sure. But I'm not sure it's at all clear from the license how the
> LARGER_WORKS.TXT file is managed and added to, and how you explain which
> parts of the code different entries in the file apply to. Guidance on
> that point, with examples, may help.

I would suggest that trying to edit the file to be different as to later contributors, with differently scoped patent licenses for different contributors, is not the idea.  It is not ideal for anyone to be getting differently scoped licenses from different authors to the same piece of code to the extent this can be avoided, and I would discourage people from doing that.  But if someone really wants to expand the scope of the license as to themselves, they should just create a separate LARGER_WORKS.TXT file, and distribute it alongside the original noting that this one is from them and not the original authors, or perhaps craft their own additional permission.  Again, though, I think this is *not* a practice I would encourage or endorse, the idea was not to allow people to make multiple differently scoped grants using this vehicle.



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