Weeks after the OpenSSL debacle, the question still stands: Why did so few people show up to work on such widely-used and important code? Since the problem arose, funds have flowed in to fix it at the behest of corporate giants, but before the crises, few volunteers participated. One leading open source expert has suggested a reason: licensing.
An interesting comment from David A. Wheeler, an expert in government use of open source, asks whether the OpenSSL project's use of a rarely seen open source license was partly responsible for a lack of community engagement and oversight. In the context of a longer paper highlighting technical facets of addressing Heartbleed, Wheeler says:
I suspect that more code review and contributions would occur if OpenSSL used a standard widely used license ... this awkward licensing situation means that many people who prefer the GPL or LGPL will often not help develop or audit OpenSSL. Some of those who prefer less-restrictive licenses may also be less inclined to help, because again, it is not a standard license.
[ Heartbleed highlights on InfoWorld: Stop laying the blame for Heartbleed on open source | 5 no-bull facts you need to know about Heartbleed | Track trends in open source with InfoWorld's Technology: Open Source newsletter. ]
Of course, "standard" here is used in the sense of a de facto standard, arising from common use, rather than a de jure standard, arising from a formal process of standardization. All OSI-approved licenses are in a sense "standard," since they have been through a de jure community review process to evaluate them against the open source definition; indeed, OSI describes itself as a standards body of sorts.
Nonetheless, Wheeler points to a valuable insight. OSI approval helps us understand whether a license delivers the flexibility of the "four freedoms," allowing individuals to determine the outcomes of their own software and allowing communities to collaborate without needing to seek permission from an authority.
But there's another role for an open source license. Legal scholar Eben Moglen has described open source licenses as acting as "the constitution for the community." In other words, an open source license embodies the expectations and norms of groups of potential community members.
The choice of license thus indicates both the preferences of the individuals who started and sustain a project and the agreed norms. Rather than using a widely accepted license, the OpenSSL project uses its own license, which is both copyleft (so not miscible with other licenses) and incompatible with the GPL, according to the FSF. As a result, the norms expressed in the license differ from those preferred by the vast majority of developers. Work in their own projects will be conducted under a different worldview, leading to differences of outlook with OpenSSL developers, however slight.
It also won't be OK to cut and paste code from OpenSSL into their own projects if the license their project uses is not compatible. They will be cautious to ensure there's no suggestion this has happened. Furthermore, the OpenSSL license includes an advertising clause that discourages developers from other projects using code under this license. It says:
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. (http://www.openssl.org/)"
The license you choose matters. It's not a matter of "copyleft religion," as some maintain. Rather, the license communicates a set of norms and requirements, and when these differ from the norms expected by developers (especially if it raises inconvenient requirements) they may simply avoid the project or use it with as little interaction as possible.
That seems to be what's happened with OpenSSL. Developers would rather not deal with these issues; as such, they use the code as-is and do the least necessary to comply with the license. I believe Wheeler has hit on an important environmental factor here: Open source is about more than code and corporate use; it is also about communities. The license you pick for your project is a beacon of your expectations, and when it differs from the majority of other projects, you can expect to be isolated.
What does this mean for those working to redeem OpenSSL post-Heartbleed? Perhaps it's time for a relicensing effort, to pick another open source license that approximates to the project's norms but is more widely adopted. Without this, I fear all the energy currently being expended by outsiders will evaporate when the panic is over.
This article, "Heartbleed postmortem: OpenSSL's license discouraged scrutiny," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.