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

[Jim Wright]

Most of this is commentary rather than anything I should probably address, but a few responses inline.

 Regards,
  Jim


On Apr 16, 2014, at 2:06 PM, Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:

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



> 
> *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.)


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

On changed product naming, I would argue that the intent of the authors to license the product in question is what matters here, not the name, but someone could no doubt argue differently.  Luckily I think I am safe from Starbucks for now.  :-) 


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

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.



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

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.  



> 
> 
> 
> 
> 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
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review