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

Wed Apr 16 21:06:03 UTC 2014

Hi Jim

I'm starting fresh on a new sub-thread to highlight some issues, now
that I understand the intent of this license. Some of these have
already been touched by others, I'm trying to list everything on my
mind:

*clarification needed*

Probably the current text is accurate from a legal point of view, but
given the novel approach of this license it clearly needs to be more
clear than now. I'm not proposing any specific text, but note that
Simon Phipps made one proposal. Maybe the LARGER WORKS part should be
highlighted even more by breaking it into a completely separate
section. I haven't spent much time thinking on style issues yet.

*patent license is very broad*

Someone said that by making a single line patch to Java, I would have
licensed all of my patents to Java. In fact, based on my example
question #3, it seems to be even broader than that: I have licensed
all of my patents to Java even if my actual patch was rejected and I
have contributed zero lines of code to Java.

Personally I don't have a problem with a broad patent license. I wish
more open source licenses had even broader patent licenses than this.
(For example, a copyleft license could include a cross license of all
of your patents licensed for use in any software under the same
license. But I digress...) That is indeed in the spirit of open
source.

However, there seems to be a large risk for this broad patent license
to happen inadvertently. Imagine an existing library that is UPL
licensed.  Then imagine a single developer in a small company (without
due diligence processes for outbound open source contributions)
submitting a single line bug fix to this library. He doesn't look at
the contents of the LARGER_WORKS file at all. He has now licensed all
of his employers patents to whatever listed in the LARGER_WORKS file.

*the LARGER_WORKS license is asymmetric*

...in practice this seems to only be relevant wrt patents, as
copyrights naturally follow the code wherever it is copied into.

Richard Fontana pointed out that this is the first time someone is
proposing a license they intend to be used with themselves as
recipient of software, and we may (or may not) want to look at this
with a different mindset than when it is the future licensor
submitting a new license. What I'm pointing out here is a bit in that
spirit:

Clearly use of the UPL as a kind of CLA is a patent bonanza for the
recipient of UPL licensed code. For example in the case of Java or
MySQL, Oracle would be the recipient of a broad patent license from
all of its contributors. At the same time Oracle would not be using
the UPL in their outbound distribution of this software. (Otoh they
are likely to use a license that includes a patent license for the
whole of Java or MySQL, so maybe this is not such a big deal in
practice.)

The counter argument of course is that whatever CLA is currently in
use, that the UPL would replace, probably already includes similar
asymmetric grants. Clearly, using the UPL will still be preferable to
using such a CLA, since with a CLA it is only the recipient
organization (Oracle, Eclipse, Apache Foundation, etc...) who recieves
the broad rights, whereas sharing code under the UPL at least gives
most of the permissive rights to everyone, with the exception of the
additional patent grants in LARGER_WORKS which are exclusive.

Last, while the above "rational reasoning" is in favor of the UPL,
there will probably still be some community members who would be
against this. And yes, particularly because Oracle is the organization
submitting the license, but not only that. Other reasons to oppose
this could be people who are opposed to CLA's in general and wouldn't
want OSI to "bless" such arrangements. Basically what I'm trying to
highlight is a potential political angle, and community reaction to
that angle, to consider when approving this license.

Btw, at least in the MySQL world it seems the major contributors would
reject this kind of asymmetric patent grant for the same reasons
they've originally rejected the MySQL CLA. Otoh in communities where
CLA's are routinely used, I don't see why someone wouldn't prefer this
license instead. (Maybe a due diligence task for someone would be to
review some commonly used CLA's to verify that the UPL isn't somehow
extending what is already common practice in the major CLA using
communities, particularly JCP of course.)

*how are forks handled*

The authors of the license seem to have mostly considered the scenario
where a well defined author contributes a block of code to a recipient
project, and that's it. This raises a number of questions, such as...

What about forks? Say that this license is used for contributions into
MySQL and "MySQL" is listed in the LARGER_WORKS file. But I use
MariaDB, which is 99% the same code as MySQL. Am I still protected by
the same patent grant (for those 99%)?

What if Starbucks sues Oracle for patent infringement on the word
"Java" and wins, forcing Oracle to change the name of Java. What
happens to the patent grants now, if the LARGER WORKS file says
"Java"? It's still the same Oracle, it's still the same code, but the
name is no longer "Java".

If I write "Java" in the LARGER WORKS file, does the patent grant also
extend to OpenJDK? Why?

I'm not saying it is a requirement for OSD compliance, but as a
general rule I think it's within the spirit of open source that a
grant to a project (MySQL) should also be a valid grant for a fork of
that project (MariaDB, WebScaleSQL). A fork here is basically the same
code base distributed under another name/trademark by another
distributor. Come to think of it, Linux distributions should be
considered here too, for example as distributors of OpenJDK. The
patent grant should not depend on the name of the software in cases
when the code is an almost exact copy and it's just the name that has
changed.

*current proposal fails to cope with the richness of contemporary open
source development*

This is basically what has already been discussed by Josh Berkus and
some others.

Josh made a proposal for a more verbose LARGER WORKS file. I don't
think it is a very elegant solution, but I do think it is a solution
that reflects the real world of open source code and it's lifecycle.
I'm also not sure if a more elegant solution is possible. This in turn
should make us reflect whether this is a good idea to begin with.
(Again, I'm not arguing against this, just saying this is a good thing
to reflect over.)

Reflecting upon it now, I think Josh' proposal fails to achieve what
has been an original design goal of this license for Jim/Oracle. I
imagine for the recipient of this "UPL used as a CLA" it would be
convenient to just consume a large library and know that all authors,
however many, have granted a patent license to all of Java, as is
required by the JCP. However this would not be the case in Josh'
example, where one author granted a license to Java, another to
Android, and a third to Hypesomething. But all authors of the code
that is in the code base did not grant a license to Java.

*No mechanism for highlighting parts that are not UPL licensed*

What if I develop a component for Java that is UPL licensed, but
incorporates some files that are MIT licensed? This is ok as both are
permissively licensed code. However, it might not be obvious that the
author of the MIT licensed code did never grant a broad license to the
LARGER WORKS.

It seems like Josh' proposal would also make this clearer, as it would
specifically list who granted what and where.

*The LARGER WORKS grant is actually orthogonal to the code base it
comes attached with*

As my example #3 showed, the (patent) license grants that come with
the LARGER WORKS file are actually independent of whether the code it
is attached to has ever been part of the "Larger Work". I understand
for CLA-like usage it is convenient to say I wrote this library and in
order to contribute it to Java I hereby also grant this additional
patent license to comply with the JCP process.

But let's imagine then Java rejects my contribution while at the same
time it is copied into Android. We would now have the bizarre outcome
that I have given Java a broad patent license even if I'm not
contributor to Java, and I have not given Android the broad patent
license even if I'm a contributor to Android.

Note that if the above happens inside a larger code base with many
pre-existing authors, I also cannot edit the LARGER WORKS file to
include Android.

This section is at least a weak argument against approving UPL on
grounds that it is not natural to combine the current LARGER WORKS
mechanism with the rest of the license. (I realize there is an
argument for it too...) I can think of other broad patent grants that
would be more natural from a "code flow" point of view, for example:
 - grant of rights to any larger work that decides to incorporate this software
 - grant of rights to any larger work incorporating this software
provided it remains under this same license (ie copyleft style patent
grant)
 - grant of rights to all other software licensed under this same
license, even when not including this specific code (a true patent
commons...)

I do realize any of the above alternatives might not be in Oracle's or
many other large patent holders interest. I'm just saying those would
be more natural licenses to me as an open source developer.

Hmm... I think my brain is empty for now :-)

henrik

On Fri, Apr 11, 2014 at 3:39 AM, Jim Wright <jim.wright at oracle.com> wrote:
> Members of the OSI License Review Community,
>
> Below, please find a copy of the proposed Universal Permissive License (UPL) for license review, with the supporting information categories listed at http://opensource.org/approval.
>
> Legal Review
>
> This license was authored by a lawyer (myself) and was also reviewed and enhanced by other lawyers both inside and outside of Oracle.
>
> License Proliferation Category
>
> I believe it falls into the Other/Miscellaneous category, and the rationale for the license is as follows.
>
> Rationale & Comparison to Similar Licenses
>
> Many commercial developers require the ability to use code licensed from other parties in both commercial offerings and copyleft licensed FOSS projects.  They also generally prefer inbound licenses to include an express patent license.  This has resulted, among other things, in the widespread use of contributor agreements containing the desired patent license grants, as neither the BSD nor MIT licenses contain an express patent license or address the concept of contribution to a larger work, and the Apache license is not compatible with the GPLv2.
>
> The proposed license solves this problem with copyright and patent licenses covering both the Software distributed under the license and a Larger Work in the event the license is used for contributions.  It also expressly permits relicensing to facilitate use with both copyleft and commercial licenses, and is GPL compatible.
>
> In addition to performing a non-duplicative function, I aimed for the license to be short, clear, and usable in multiple contexts, and I hope you will agree it is.  Thank you for your consideration.
>
>  Regards,
>   Jim Wright
>
>
>
> The Universal Permissive License (UPL)
>
> Copyright (c) <year> <copyright holders>
>
> Subject to the condition set forth below, permission is hereby granted, free of charge and under any and all patent and copyright rights owned or freely licensable by each licensor hereunder, whether an original author or another licensor, to any person obtaining a copy of this software, associated documentation and/or data (collectively the "Software"), to deal in current and future versions of both
>
> (a) the Software, and
> (b) any piece of software and/or hardware listed in the LARGER_WORKS.TXT file included with the Software (each a “Larger Work” to which the Software is contributed by such licensors),
>
> without restriction, including without limitation the rights to make, use, sell, offer for sale, import, export, have made, have sold, copy, create derivative works of, display, perform, distribute, and sublicense the Software and the Larger Work(s) on either these or other terms.
>
> This license is subject to the following condition:
>
> The above copyright notice and either this complete permission notice or at a minimum a reference to the UPL shall be included in all copies or substantial portions of the Software.
>
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7