[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