The open source world has recently seen a few high-profile projects with unusual terms. They call themselves “open source” and “free for research and commercial use,” and some pundits (including Matt Asay in InfoWorld) argue that the question of whether something is open source “doesn’t really matter.” We’d argue that’s untrue: These projects certainly feel it’s important that the average developer views them as open source. Their halfway licenses capitalize on the goodwill of open source software. Let’s start calling this pretend open source software what it really is, partially between open and closed: ajar source software.
- IBM announced that it would no longer make its Red Hat source code publicly available. Linux is distributed under the GNU Public License (GPL) with a syscall exception. IBM must provide source code changes when requested by customers who receive Red Hat binaries. However, IBM is under no obligation to continue a relationship with you after the terms of your current contract expire. The implication: You can ask for source code changes once, but if you do, you might never see another Red Hat release. Strictly speaking, this conforms to an open source license. In spirit, though, it’s not what the developer community means when they say “open source.”
- Meta released its Llama 2 model with conditions for large companies. Meta distributes Llama 2 under the “Llama 2 Community License Agreement.” This looks like a standard open source license agreement, but unlike the open source licenses you’ll find at the Open Source Initiative (OSI), it contains a clause addressing “Additional Commercial Terms.” In short: If you want to use Llama 2, you can. However, if you have more than “700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion.” We wonder what Meta would do if that restriction applied to its Linux servers.
- HashiCorp abandoned the Mozilla Public License (MPL). HashiCorp (maker of Terraform) changed its licensing from MPL to the Business Source License (BSL). The upshot of this change is that you can’t use HashiCorp products to create software that provides “a competitive offering to HashiCorp.” If you build software using HashiCorp’s products under the BSL, you can’t embed or host the software in an offering competitive to HashiCorp. You must buy a commercial license the moment you’re competing – or stop using the source code altogether if HashiCorp refuses to sell you a commercial license.
Encumbrances != Open Source
According to the OSI, open source software is more than access to the source code. It also requires no restriction on one’s ability to sell software that uses the source code. Indeed, the creators of the BSL note: “The Business Source License (this document, or the ‘License’) is not an Open Source license.” HashiCorp must not have read that part since it used the term “open source” to describe the BSL. These software products aren’t open source, but they aren’t quite closed source either: They’re ajar source.
When an open source project changes its license to something the community finds unacceptable, we’ll often see a group of developers fork the source from the old license. XFree86 originally had an MIT license, but its developers changed that in 2004 with its 4.4.0 release. In response, X.Org forked XFree86 4.4 RC2 under the old license terms. That’s why your X Window Server on Intel architectures is X.Org and not XFree86. At least for Terraform, it appears that HashiCorp will see a similar fate.
Understand Licenses Carefully Before Use
Know who owns a software copyright and understand that impact. If it’s owned by a for-profit company, the license can change to satisfy the company’s shareholders, not yours. Pay close attention to the terms of the license. For quite some time, we’ve had an open source world where licenses have been relatively comprehensible. We are now entering into a phase of more confusion. Licensing is again a concern to developers and architects. Whether a license is acceptable depends on your organization’s goals. Don’t assume that just because something says it’s “open” that it’s fit for your purpose or that it’s even a truthful claim. It might just be ajar.