HPE Software is now Micro Focus
HPE Software is now Micro Focus
Software Solutions

Use Oracle’s UPL, Abandon Your Intellectual Property

Use Oracle’s UPL, Abandon Your Intellectual Property


Guest post by Martin Fink, EVP and HP CTO


HP has historically taken a strong stand against the proliferation of open source licenses.  We’ve never proposed our own open source license. I started speaking out against license proliferation as early as 2005, pointing to the interoperability and compatibility issues raised by having a large number of open source licenses.  Many members of the open source community have also embraced the concept of non-proliferation. The reaction to any new license tends to center around whether a new license addresses an unmet need. That’s why I am concerned about a new license proposed by Oracle.


Recently, Oracle submitted the new Universal Permissive License (UPL) for approval to the Open Source Initiative (OSI).  The OSI is the well-respected steward of the Open Source Definition (OSD) and reviews and approves open source licenses which conform to the OSD and do not create proliferation issues.  Oracle claimed to address the non-proliferation issue by stating it viewed UPL as filling the need for a permissive, MIT-style open source license with explicit patent grants.


Oracle drafted the UPL to address concerns it had with proposed changes to the Java Community Process (JCP), specifically with regard to license rights in others’ reference implementation technology of Java specifications.  Oracle expressed concerns with using other open source licenses for reference implementation technology due to its need to license this technology under both proprietary licenses (with patent grants) and the GPLv2. 


Regardless of what OSI and the JCP EC decide with regard to UPL in their independent review processes, I have the following concerns.


At a high level, the UPL copyright and patent licenses are overly broad. They extend to current and future versions of both the UPL-licensed code as well as any software/hardware identified in a file included with the UPL-licensed code.  There is no requirement that the UPL-licensed code be associated in any way with the software/hardware included in the file in order to use the license to that software/hardware. This is a very expansive license. 


There is no defensive termination clause under the UPL, which would allow a licensor to terminate part or all of its license if the licensee sues the licensor for patent infringement. This means a licensee can get very broad rights in the licensor’s technology, sue the licensor for intellectual property (IP) infringement, and not have to worry about losing its license to technology licensed under the UPL.  As you can imagine, this is very attractive to those entities who frequently engage in litigation.


What does use of the UPL mean for companies? 


Say Company X makes some code available under UPL.  At a minimum, Company X has just granted very broad copyright and patent licenses in the licensed software and any piece of software or hardware identified in an accompanying text file. 


Since this is open source, others can view the code and make changes to it.  What can happen here?  By making a bug fix available under the UPL, a company could inadvertently grant a broad copyright and patent license to various technologies.  For example, an employee of Company Y may make a one-line bug fix to some code licensed under UPL by Company X and make the fix available under UPL, using the same accompanying text file with the UPL which was used by Company X.  This text file identifies several pieces of software and hardware and, per the terms of the UPL, Company Y is now granting a broad copyright and patent license to those technologies. By making the bug fix available under the UPL, the Company Y employee has (inadvertently) granted a broad license under Company Y’s copyrights and patents to the software identified in the accompanying text file.


Given these issues, it’s hard to see why any company with IP interests would use the UPL unless it were compelled to do so (for instance, it wanted to participate in the JCP and could do so only under the terms of the UPL).

The most troubling part of all of this is that Oracle has no intention at this time to make any of its own technology available under the UPL, and intends to use it only so it can get rights to make others’ technology available under another open source or proprietary license.   


While there may be a need for a permissive, MIT-like license with an explicit patent grant, the UPL is not that license.  Its grants are too broad, and Oracle has admitted it does not intend at this time to license its technology under the UPL.

From a non-proliferation standpoint, I have concerns that this license may make approval and adoption of another, more narrowly-scoped permissive license with explicit patent license grants more difficult in the future.


What can be done? 


If Oracle views the UPL as the answer to its concerns about potential changes to the JCP, I suggest they revise the UPL to be more narrowly scoped than its current form.


Alternately, if Oracle feels reference implementations of Java specifications need to be made available to it under a permissive open source license with an explicit patent license, why not use the Apache 2 license and relicense Java under the Apache 2 license?  To the extent Oracle does not possess all the rights in certain technology to relicense Java, it could call on the community to relicense that technology.


Either of the suggestions above would solve Oracle’s stated concerns, without creating a new, unnecessary open source license tailored to the interests of only one member of the open source community.


I view UPL as a cynical use of open source to get broad rights in others’ technology. I would challenge Oracle to make its technology and IP portfolio available under the same terms it wishes to receive technology and IP rights from others.  Open source is about community and collaboration; proposing a license you’re not willing to apply to your own technology is counter to these values. 


  • Software Solutions
About the Author


This account is for guest bloggers. The blog post will identify the blogger.


When I try to understand the whole of it, it is clear that UPL  license is tailored to the interests of only one member -- the one who submitted the new Universal Permissive License (UPL) for approval to the Open Source Initiative (OSI).


Even with the current and future battles over the JCP being set aside, I agree that this Oracle proposal is far too broad and potentially damaging to the fundamental value of the open source development community. The impact would be a slow and insidious withdrawal from the open source development community as they collectively found out that they passively, accidentally lost all future IP to a separate party. 

UPL would make open software maintenance too risky, legally, for any of the submitters. Initially, there would be ignorance, litigation, then eventually, suspension of open engagement. This is counter to the whole premise of open source -- especially when compared to most of the existing open license agreements. 

For others who are interested, the interesting discussion on this is at: 


..where the defenses made to the value/usefulness of this proposal appear to be weak and self-fulfilling. 


I agree with Mr. Fink regarding this point. This is a bad idea and, frankly, appears to be a semi-transparent grab for free "magnetic IP" (especially when considering the possible future likelihood that it will be the mechanism for even more extreme JCP control).  Support of open source software should not induce passive theft of IP. The alternative MIT license clearly and openly exposes a reliquishment of some of these future rights, whereas this UPL license proposal seems to do this passively/implicitly. Even using the "LARGER WORKS" mechanism does not address this issue adequately, in my opinion. 








I feel that Oracle acquires open source solution to destroy them. MySQL and Java are maximum exponents of this idea. For many years HP has worked thinking that Oracle is our friend and it was past, right now is our stronger competitor in many areas. Our advantage is that we have our HP delivery team experience using our solutions (and reusing), and Oracle advantage is that they will use "any" delivery system integrator but rarely Oracle team do the integration on real world and take advantage in other customers.