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

Richard Fontana fontana at sharpeleven.org
Mon Apr 14 02:09:23 UTC 2014


On Thu, 10 Apr 2014 17:39:42 -0700
Jim Wright <jim.wright at oracle.com> wrote:

> License Proliferation Category
> 
> I believe it falls into the Other/Miscellaneous category

This issue itself is interesting to me, even if we should regard it as
a mere detail of OSI license submission procedure. 

These license proliferation categories, created in (I believe) 2005,
are set forth here:
http://opensource.org/proliferation-report
 
So does the UPL more properly fall into one of the other license
proliferation categories? It's obviously not 'superseded' or
'voluntarily retired'. It is not 'non-reusable'. It is not 'special
purpose'. It is obviously not 'popular and widely used or with strong
communities'. 

That leaves "Licenses that are redundant with more popular licenses". 
The UPL is probably not appropriately considered "redundant with" the
MIT license even though it is based on it; the inclusion of an express
patent license alone makes that clear (cf. the noisy discussion of CC0
on this list some time ago). 

A case *can* be made that the UPL is "redundant with" the Apache License
2.0, much as the AFL was considered redundant with it in 2005. Both are
noncopyleft licenses with express patent license grants.  

It's useful therefore to think about how the UPL is different from the
Apache License 2.0 (as that justifies regarding it as "nonredundant",
which is important not only because OSI procedure requires this
classification step but also because of the OSI's policy since 2005
against license proliferation [with a tendency to favor "popular"
licenses which category includes the Apache License 2.0]). There are a
number of substantive and nonsubstantive differences; a few substantive
ones stand out to me:

1) The Apache License 2.0 patent license grant is more precisely
scoped, while what we have in the UPL is what we might expect
the author of the MIT license to have drafted had that author decided
to address patents explicitly (to be clear, this is not a criticism of
any of those three licenses, just an important observation :)

2) The Apache License 2.0 has a patent termination clause triggered by
initiation of patent litigation under some circumstances; the UPL makes
no reference to patent termination

3) The Apache License 2.0 has an upstream indemnification clause; the
UPL has nothing like this

Jim did not note those explicitly, but he did assert one difference:
the Apache License 2.0 is incompatible with GPLv2. (Jim declares this
as a fact, which most other people who address that topic do as well,
and I suppose there's no point in this context in arguing over that
issue.) The UPL is said by Jim to be GPL compatible, which must include
compatibility with GPLv2 since the asserted incompatibility of the
Apache License 2.0 with GPLv2 is noted by Jim as a drawback of that
license. 

GPLv2 compatibility is thus important here because it is something that
(if present) makes the UPL nonredundant with respect to the Apache
License 2.0 - although, as Gerv's comment indicated, one can easily
make the Apache License 2.0 compatible with GPLv2 by appending a
sentence or so to it. This fact might call into question the value of
built-in GPLv2 compatibility, but then again developers most often use
open source licenses as fixed forms.[1]

Tom Marble raises a question about whether UPL is indeed compatible
with GPLv2. But I annot see how it could be considered incompatible if
GPL compatibility is more than a meaningless doctrine. Whatever
differences the UPL has from the MIT license, its ancestor, are all
'additional permission', to use the GPLv3 concept. 

None of what I've said here goes to the merits of the license, of
course.

 - RF

[1] I am just noting in a footnote that even if we buy into the notion
of Apache-GPLv2 incompatibility, I cannot see how the Apache License
2.0 is incompatible with GPLv2-or-later, which is a far more prevalent
form of GPL licensing than "GPLv2 only". Thus the drawback of the
incompatibility of the Apache License with GPLv2 is arguably
overstated. The problem with this view is that the only people who seem
willing to accept (other than merely by conduct) what is obvious to me,
that Apache-GPLv2+ compatibility logically follows from Apache-GPLv3
compatibility, are me, Chris Aniszczyk, and legions of Red Hat
developers whom I have persuaded as to this point over the years.



More information about the License-review mailing list