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

Josh Berkus josh at postgresql.org
Mon Apr 14 14:25:25 UTC 2014


Jim,

I think you're now seeing why nobody has created a license like this
before; it's a bit of a challenge.


>> - What if a downstream fork modifies that file?
> 
> A downstream fork cannot modify the file and expect this to be
> legally effective any more than they could simply edit the license
> text - the authors of the Software are making a grant of specific
> scope, and a downstream recipient cannot expand that scope.

You're assuming here that the downstream recipient has no patents of
their own to grant usage to.  Let's give an example:

1. Oracle releases a new compression library under this license.  It
includes several Java things in LARGER_WORKS.txt.

2. The Google Android team decide to include that compression library
into Android OS.  At this point, they want to *add* Android to
LARGER_WORKS, covering any compression patents which Google owns.

So realistically, LARGER WORKS would need to be an append-only file to
which each downstream contributor adds their own covered works, or
possibly some kind of online registry. This provision is going to make
the license significantly more complicated.

>> - Can you give examples of what would go in such a file?
> 
> Sure, the first example that I can think of would be Oracle Java,
> where someone is developing a JSR reference implementation and this
> therefore allows us to ship that code in either OpenJDK or the
> proprietary licensed Java packages.  Another example from my own
> world would be MySQL, which likewise has versions shipping under both
> GPLv2 and proprietary licenses.

Presumably this would only be a concern for patents which only covered
UPL licensed technology plus larger work, and not either individually,
yes?  Sadly, I can imagine several such.

>> - What if a downstream distributor fails to include the
>> LARGER_WORKS.TXT file with the software?
>> 
> 
> That's a good one.  This is just another form of the downstream
> distributor choosing to sublicense the code on other terms (just like
> they could under GPL or Apache or a proprietary license), and would
> therefore mean the person receiving the Software would not get the
> broader patent grant from the downstream distributor.  They also
> might not know they could actually get a broader grant from the
> original authors without looking, but it doesn't mean they wouldn't
> benefit from the broader license, since the authors granted those
> rights when they distributed the Software originally.

That's a problem which would solve itself, I think.  What's a bigger
issue is that popular libraries licensed under the UPL would accumulate
multiple, conflicting LARGER_WORKS files.

I do not agree with the other developers on this list that the UPL
somehow violates the OSD.

--Josh Berkus




More information about the License-review mailing list