LibreHQ will be offline for about 30 minutes Saturday, March 29, starting 9:00pm US Central Time, in order to apply an upgrade. Thank you for your patience.
For many years, Aladdin GhostScript implemented a DOSP policy whereby
new versions were published under a proprietary license, and then regularly
relicensed under the GNU GPL with a delay of one year. (It might be
clearer to say that year-old versions were regularly republished under
the GPL.)
GhostScript author L. Peter Deutsch described this practice as providing
commercial exclusivity that would help fund continued development of the
project.
Eventually, GhostScript adopted a simultaneous dual-licensing approach
in which all releases were available under GPL and redistributors could
choose to pay for a proprietary license exempting them from GPL
obligations.
% TODO This is about Artifex rather than Aladdin - the change happened
% after the product was transferred to a new company!
Attorney and author Lawrence Rosen, who discussed GhostScript's model in
his book on open source licensing, told us that Artifex eventually
concluded that the GPL was unpalatable enough to commercial embedded
developers --- the entities that were typically already paying for
proprietary licenses or that could be induced to pay for violations of
GhostScript's copyright --- that the delay in making GhostScript available
under the GPL did not significantly change these companies' incentives to pay
for licenses.
% Sorry for the super-long sentence. I'm sure we'll break that up somehow.
% Rosen also says that sendmail may have had a dual license in the same
% era or even before Ghostscript.
\numberedsection{Bounty and Sponsorship Delays}\label{bounty}
Another model is making individual software features or enhancements
available to sponsors first, with a fixed time delay before making
them available to the general public. An example of this is the North
Road SLYR GIS software, which has a published feature roadmap and releases
(and licenses) its implementation of each feature to sponsors first:
\begin{quote}
While we fully intend to make the full SLYR plugin open source and freely publish the style/LYR/MXD conversion tools, we also require financial backing in order to support the significant time required to completely reverse engineer these file formats and develop quality tools supporting their use outside of the ESRI software ecosystem. Accordingly, the specifications and file parsing library will initially be closed source and available to SLYR license holders only. Exactly six months after we hit the pledged sponsorship levels for each stage of the project (check the progress below for each stage), we will open-source that component of the code and update the community version of the plugin.
\end{quote}
% https://north-road.com/slyr/
\numberedsection{The Business Source License (BUSL)}\label{busl}
TBD Include BUSL's precursors here, e.g., TGPPL, maybe others?
The Business Source License (BUSL; sometimes ``BSL"\footnote{Most adopters
of this license refer to it as ``BSL", but
this acronym was previously used for the Boost Software License. The
SPDX license identifier for the Business Source License is ``BUSL".})
was originally written in 2016 by MariaDB for its MaxScale project.
The current version of BUSL, 1.1, was released in 2017 and first
BSL 1.1 is a source-available license that allows copying, modification, redistribution, non-commercial use, and commercial use under specific conditions. With this change we are following a path similar to other companies in recent years. These companies include Couchbase, Cockroach Labs, Sentry, and MariaDB, which developed this license in 2013. Companies including Confluent, MongoDB, Elastic, Redis Labs, and others have also adopted alternative licenses that include restrictions on commercial usage. In all these cases, the license enables the commercial sponsor to have more control around commercialization.
\end{quote}
TBD
This change applied to almost all of the company's software, including popular
software like Terraform, Vagrant, and Hashicorp Vault.
\subsection{Differences From Other Licensing Strategies}\label{differences}
MariaDB (https://mariadb.com/bsl-faq-mariadb/):
\begin{quote}
Q: How is the BSL different from Open Core?
A: Open core offers some code under Open Source terms, but non-core code is not under Open Source terms, is not available in source form, cannot be modified and compiled, cannot be contributed to, and will never be Open Source. By using Open Core software, like with closed source code, you are locked to one vendor. With BSL, as compared to Open Core, the source code is available from the start, can be modified and compiled, contributions are encouraged, the product will become fully Open Source after a period of time and remains free for non-production use. The importance of the eventual Open Source is that users are free from vendor lock-in. If the vendor decides to stop contributing to the code, users have open access and can modify, update and extend as needed.
Q: How is the BSL different from dual GPL/commercial licensing?
A: When using dual licensing with GPL, companies must pay for a commercial license to use the software with their closed source code. With BSL, the companies are only paying for the software if they want to make production use of the software. From a vendor perspective, GPL dual licensing only works for infrastructure products that other companies want to deeply embed in their product. BSL works for any kind of software product.
\end{quote}
This is echoed in statements by several BUSL adopters that they sought a way to make downstream commercial users who did not redistribute derived works pay for the use of their software (typically in cloud environments), or wanted to prevent downstream commercial users from directly competing with the initial developer's own service offerings.
