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

Tue Apr 22 07:09:33 UTC 2014

On Fri, Apr 18, 2014 at 3:16 PM, Jim Wright <jim.wright at oracle.com> wrote:
> Most of this is commentary rather than anything I should probably address, but a few responses inline.

Indeed. As there is some novelty in your proposal, I tried to
"dry-run" how the license would work in some example scenarios,
without necessarily trying to look for reasons to support or oppose
it. But thanks for your answers to some of my observations.

>> 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 same would be true under any license for an employee making an unauthorized contribution, the only thing that's different is the scope of the license, and I think many of the lawyers here would tell you there may really be no license at all in that case.  (Not an easily solvable problem.)
>

Yes, but what is different is the surprise element. If an unwitting
developer contributes a patch to some code on Github, it's reasonable
to expect that he should be aware that there is an open source license
somewhere. (Well, apparently even that isn't true anymore, but in any
case it's reasonable to expect everyone should know copyright law is
somehow involved...) On the other hand it is not reasonable to expect
that the average developer thinks of checking a separate LARGER_WORKS
file. So the risk of neglect is much larger here.

Note that I'm less concerned about "who's fault" it is, ie whether the
developer just licensed away or his employers patents, or whether the
recipient (e.g. Oracle) failed to get a proper license. Either way the
license would not have worked as intended.

For now I'll just note that a more explicit LARGER WORKS file, such as
proposed by Josh Berkus, would eliminate this risk, as each
developer/organization would have to explicitly append to that file to
make the patent grant to the larger work. (But, as I noted earlier,
his suggestion may introduce other problems instead, at least from
some points of view.)

>> *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.)
>
> Keep in mind that the vast majority we've spoken to about it have not rejected the SCA/OCA as a contributor vehicle for MySQL, Java, or anything else - they sometimes have Qs and we talk to them about it, but a very large number of people and companies have signed it, including many competitors of Oracle and others who view us with suspicion.  The way this came up is that folks wanted to see if it was possible to get away from that for the JCP, and I am trying to facilitate this and introduce something broader that I think would be good for other communities at the same time.  Folks who don't actually know me may view this with suspicion because of my employer or otherwise, and there's not much I can do about that other than being transparent.  (Oh, and BTW, I get some requests to release stuff under, e.g., the BSD and MIT licenses, so I might very well start using it for some outbound stuff as well where a permissive license is appropriate.)
>

I don't know you, but I also have no apparent reason to distrust you.
I know many good open source people who have worked for Oracle for
many years, so who's to say you aren't one of them. In the above I was
mostly trying to anticipate various reactions, even if they aren't my
own.

I think it's expected that UPL could work well in communities where a
CLA process is already widely accepted, such as JCP. At the same time
it's unlikely that Google would participate in UPL code with MySQL as
the recipient/benefactor, just like they never signed the MySQL CLA
either. In this sense the UPL doesn't change much, but could
streamline an existing process.

>
>> *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?
>>
>
> On the scope and covering forks or related products with different names (e.g., OpenJDK as part of Java), I think that depends on what exactly you put in the larger works file in each case (you could say Oracle branded MySQL, or MySQL and forks, and Java SE, or All Oracle Java Products, or anything in between) - so of course, if you intend, e.g., MySQL forks to be covered, you can easily just say that.  But even if you *don't* say it, if you don't go out of your way to restrict the license from forks, I think some if not many would argue that patent exhaustion applies to the common code base, and thus that once someone gets covered code from Oracle, further downstream distribution, either with or without mods, does not eliminate that coverage.

I would expect that too. What I think would be great is if this would
be clearer. The way the UPL is written now, it focuses more on the
recipient project than the code base. For an uneducated mind it is not
clear that something that was licensed to MySQL is also licensed in
MariaDB. (...for the same code. I'm ignoring MariaDB specific
additions for now.)

> Now if you want the additional modifications that are only in the forks to be covered, then to be safe, I might tend to expressly license them as well.
>

Of course. In fact it would clearly be wrong for me to the OpenJDK
code, bundle it with my "Kitchen Sink" product and try to argue that
everything in my Kitchen Sink is now protected by the patent grants
that were given 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.
>>
>>
>
> Most other licenses do not have a vehicle for this either - if there's stuff under another license, it's still up to the developer to provide it, as they would have to if they mixed and matched code under BSD and MIT licenses.  I simply did not try to address this issue and don't see it as particularly problematic.
>

Yes, but it is good practice to include either the license or a
reference to it at the top of each source code file. This makes it
clear that this one file is MIT licensed even if it is embedded in
othwerwise GPL source code repository.

The UPL LARGER WORKS file is very detached from anything like that. In
particular, imagine two UPL licensed libraries with different contents
for the LARGER WORKS file, coming together in a larger open source
project. This means simply referencing the UPL at the top of a source
code file doesn't solve this problem.

There should be some similar best practice that makes it unambiguous
which patents were granted to whom. Maybe something like Josh'
proposal is the way to go.

>> 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.
>
> Unfortunately an even broader license would not be accepted by basically anyone with a patent portfolio - I can't unilaterally force patent peace on everyone, and few if any substantial patent holders are going to license their patents for all purposes, or they would not have bothered investing in getting them in the first place.  (E.g., IBM cannot be worried that by participating in the JCP they're going to license all of their patents for the Oracle DB, or the license would be rendered unusable.)  I totally see your point of view here, and the compromise I've tried to strike here is to allow everyone from the individual developer up to HP and SAP to contribute to a specific project without worrying that their entire portfolios would be subject to the license, while still making sure that the community in question is covered by all of its participants.

I hope one day someone will introduce such an open source license. GPL
wasn't acceptable to large copyright holders either, but here we are
using it as the most popular license :-)

But yes, I understand my examples here have a much broader scope than
what you're trying to achieve, and I think the UPL is still addressing
a valid use case too.

henrik

-- 
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