Blog
April 26, 2017
OpenSSL licenses are used by many teams. In this blog, we look at how OpenSSL licensing works, and how the recent OpenSSL license change will impact users and contributors.
- Is OpenSSL Free to Use?
- OpenSSL License Change Overview
- What's Driving the Change?
- How Does the Change Impact Users?
- How Does the Change Impact Contributors?
- Final Thoughts
Is OpenSSL Free to Use?
OpenSSL is licensed under Apache and free to get and use.
OpenSSL License Change Overview
OpenSSL recently announced it's changing its licensing to Apache License v2.0 for their popular open source package. While it’s generally a welcome change for many users of OpenSSL, some groups are not happy about the new licensing, or the process being used to change it.
Currently, the OpenSLL project is conjunctively dual licensed, meaning both OpenSSL License and the SSLeay License apply whenever OpenSSL is used in distributed software.
What’s Driving the OpenSSL License Change?
“This re-licensing activity will make OpenSSL, already the world's most widely-used FOSS encryption software, more convenient to incorporate in the widest possible range of free and open source software," said Mishi Choudhary, Legal Director of Software Freedom Law Center (SFLC) and counsel to OpenSSL, as explained in this recent announcement.
Incompatible Clauses in OpenSSL Licenses
More specifically, the OpenSSL License contains clauses which are incompatible with GPLv2 clauses, meaning the conflict occurs if an organization is distributing its application under GPLv2 and it also contains OpenSSL. This type of licensing conflict is not uncommon for users of open source software.
Mark McLoughlin detailed the specific incompatible license clauses in his blog:
“…the OpenSSL license contains the following two clauses:
3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (www.openssl.org)"
6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (www.openssl.org)" These clauses impose restrictions on people wishing to distribute your program. If your program is licensed under the GPLv2, these restrictions conflict with the following clause in the GPLv2: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.”
He goes on to conclude that if users “want to use OpenSSL with a GPL program you should consider whether an OpenSSL exemption to the license is viable - i.e. do all the copyright holders for the affected code agree? Failing that, you could distribute the GPL program using OpenSSL but you are effectively trusting that the copyright holders for that program don't care. A much safer option is to use either the GNU TLS or Mozilla NSS library.”
Effectively, he is saying the easiest solution was to simply NOT use OpenSSL at all, and instead use alternative software that provides more permissive licensing.
So, this explains why OpenSSL has finally decided to make the change to Apache License v2.0, and they have created a site to facilitate the process of gathering agreements from past contributors, necessary to complete the change.
How Does The OpenSSL License Change Impact Users?
From a user’s perspective, it’s summed up nicely here by Josh Triplet: “This is a huge win. The incompatibility between OpenSSL and the GPL has been one of the most notable license incompatibilities regularly encountered in practice. With this change, OpenSSL will become compatible with GPLv3, which also makes it compatible with software licensed 'version 2 or later'. People will no longer need to choose and port to another crypto library for license reasons.”
You may be familiar with OpenSSL only because of the infamous Heartbleed vulnerability that has made a lot of news, and as Thomas Clayborn from The Register points out in his recent blog post: “For years, OpenSSL went largely unappreciated, until the Heartbleed vulnerability surfaced in 2014 and shamed the large companies that depend on the software for online security to contribute funds and code. The planned licensing change comes with the endorsement of Intel and Oracle, among the companies that pledged $3.9 million to the Linux Foundation as atonement. A portion of that funding transformed OpenSSL into something more than the shoe-string operation it had been for years.”
He goes on to report, “… in the year before Heartbleed, two people were responsible for almost all of the changes being incorporated into OpenSSL. Now there are at least 150 contributing and making pull requests…”
How Does The OpenSSL Licensing Change Impact Contributors?
As part of the relicensing process, OpenSSL must attain approval from all past contributors, which is precisely why making such a change is a long and difficult process. If any contributors do not agree and accept the change, then their contributed code must be replaced.
According to Thomas Clayborn, Theo De Raadt, founder of OpenBSD, a contributor to OpenSSL, says OpenSSL is “failing to consult its community of authors.” Some are raising questions about the impact of OpenBSD to take patches from OpenSSL after re-licensing, an illustration of why some contributors may oppose the change. Others believe the choice of the Apache License is not permissive enough, and De Raadt stated he believes other contributors will not go along for this reason, and it will only serve to further divide the community.
Clayborn also says De Raadt has concerns with the way OpenSSL is handling the licensing change, saying OpenSSL has never had a contributor’s license agreement, and therefore he believes they do not own the right to make this licensing change. Additionally, he claims OpenSSL’s process is wrong by declaring that, when asking contributors for approval, "If we do not hear from you, we will assume that you have no objection." De Raadt suggests this may not meet legal requirements.
This illustrates why a Contributor License Agreement (CLA) is so important. As OSSWatch has explained, a CLA establishes that each “contributor needs to - at a minimum - grant … the right to sub-license. When granting rights, it is common to grant a very broad range of rights. This is in order to avoid the need to return to the contributor for authorization to take the desired action with their contribution, such as releasing under a different license.”
Final Thoughts
In summary, the story is a reminder of the value in the foresight we see missing here: selecting the right license for your open source projects, as well as creating a flexible CLA up front, or at least early in the project’s life, are crucial actions that may payoff later.
Get Guidance on OpenSSL Licensing
Have further questions? Connect with one of OpenLogic's experts.