Delayed Open Source Publication Emerges as Open Source Rival
A blend of proprietary and open source licensing is becoming more popular and is posing a threat to open source software.
In a notable shift within the software industry, Delayed Open Source Publication (DOSP) has emerged as a nuanced strategy blending proprietary and open source licensing. This approach involves initially releasing software under a proprietary license, followed by a planned transition to an open source license.
Often these programs are released first as open source software and then re-released with a promise of eventually reappearing as an open source program. The Open Source Initiative (OSI) has released a study delving into DOSP’s history, patterns, and evolving trends.
Another example is KDE’s Qt library, which incorporated DOSP as a safeguard against potential development discontinuation. Qt’s licensing history is complex, to say the least, and today it’s available under both commercial and open source GPL 2.0, GPL 3.0, and LGPL 3.0 licenses.
How Delayed Open Source Publication Is Used
The researchers found that there are three kinds of DOSP.
- Unconditional scheduled relicensing. This straightforward approach involves a pre-defined time delay before transitioning to open source licensing.
- Event-driven relicensing. Here, the open source publication is tied to specific events, such as the release of a new proprietary version, prompting the open sourcing of its predecessor. While this was once common, it’s now rarely used.
- Conditional relicensing. This type hinges on certain conditions, like securing funding or finding a suitable nonprofit home, before transitioning to open source. Needless to say, this promise may or may not be fulfilled
A related variation to DOSP is “visible source” or “source available.” In these models, the source code is usually available, but without the freedoms guaranteed by the Open Source Definition (OSD). The most recent, well-known example of this is Meta’s AI large language model Llama 2 Community License, where the code is available, but its commercial use is restricted.
In DOSP’s early days, the OSI researchers found DOSP was “typically about monopolizing direct commercial revenue: the license would grant most of the permissions necessary for open source but, crucially, withhold permission to use the software commercially.” This restriction would apply to all downstream licensees, including users, not just developers.
“More recently, however,” the researchers wrote, “some DOSP licenses are about preventing any licensee from using the software in a product or service that competes with certain specific types of software that are strategically important to the licensor, independently of direct revenue.”
For example, the BSL 1.1, which was written for MariaDB, doesn’t allow licensed code to be used in production unless the licensor uses the Additional Use Grant (AUG)” mechanism. AUGs are not spelled out in the license itself.
AUGs vary from company to company. MariaDB, for example, defines “commercial use” as being if your application uses the licensed work with over three server instances. In other words, you can’t use MariaDB without a commercial license if you’re going to use it as the basis for Software as a Service (SaaS) or production. HashiCorp’s BSL implementation AUG does allow for production use … except in products that are competitive with Hashicorp’s programs and services.
What this means in practice is that not all BSLs are created equal. Thanks to AUGs, each BSL instance is actually a substantively different license.
Open Sourcing Older Code: a Messy Process
In any case, under a BSL, older versions of the code will eventually be released under an open source license. The key word is “eventually.”
The BSL requires a licensor to specify a “Change Date” and a “Change License.” On the future Change Date, the license of the covered artifact will change to the Change License, which is an open source license.
MariaDB’s Change Date is four years after the release of a specific version, and its Change License is GPLv2. However, as the OSI researchers pointed out, “BSL is notionally designed to apply to specific software releases so that a Change Date applies to a particular version of a code base. That means that, for a project with an ongoing DOSP practice, BSL is meant to be re-applied periodically with updated details.
“The majority of projects we’ve seen have not yet demonstrated how they’ll handle this process on an ongoing basis. Most don’t have a clearly visible and systematic way to apply BSL updates to ongoing development, though. … For some projects, it is unclear at first glance exactly which version or versions of the code base the BUSL grant is meant to apply to. The Change Date concept may be complicated by the fact that not all contemporary software projects have a reliable schedule of discrete ‘release’ events.”
Messy, isn’t it?
The Rise of Business Source Licenses
HashiCorp’s move from the Mozilla Public License 2.0 to BSL 1.1 for Terraform is an example of two growing trends. The first is the rise of the BSL. Today, there are more than a dozen projects using BSL, including CouchBase, DragonflyDB, and ArangoDB.
In addition, recent DOSP licenses and their users are focusing more on preventing competition rather than monopolizing commercial revenue. Particularly BSL users are increasingly focused on preventing direct competition with the licensor’s strategic interests. This shift is evident in the additional use grants and specific terms added to these licenses.
Besides the DOSP licenses, several cloud-oriented software projects, such as MongoDB and Redis, have also dumped open source licenses in the past few years to adopt licenses with non-competition clauses. These licenses, such as the Server-Side Public License (SSPL), typically let you see the code, but cloud service providers can’t use it in SaaS. These are not DOSP-compatible licenses.
Announcing the report’s publication, OSI Executive Director Stefano Maffuli praises its important findings, not the least of which is “the complexities and compromises since the early days of the open source movement,” and for raising new questions that beg more dedicated research.”
Personally, I see DOSPs as an obnoxious compromise between open source and proprietary licensing. It seems to me that all too often, it’s used to take the work of open source programmers and then close the door behind their code once a project has achieved enough momentum for its owners to monetize it.