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.