---
title: "Delayed Open Source Publication:\\\\A Survey of Past and Current Practices"
date: TBD Nov 2023
draft: true
---

%% extends "report.ltx"

\BLOCK{block preamble}
\BLOCK{endblock}

\BLOCK{block body}

\begin{center}
  Seth Schoen, Karl Fogel, James Vasile
\end{center}

\renewcommand*{\contentsname}{} % Get rid of "Contents" from top of TOC
\tableofcontents
\addtocontents{toc}{\protect\thispagestyle{empty}} % no page numbers

\setcounter{page}{1}

\newpage

\numberedsection{Executive Summary}\label{executive-summary}

\otsfirstterm{Delayed Open Source Publication} (DOSP) is the practice
of distributing or publicly deploying software under a proprietary
license at first, then subsequently and in a planned fashion
publishing that software's source code under an open source
license.\footnote{Note that this definition deliberately does not
  include \foreignphrase{ad hoc} or improvisatory open source releases
  of formerly proprietary code.  For example, the 1998 release of the
  Netscape Navigator source code, which through further development
  eventually became Mozilla Firefox, is \emph{not} an example of DOSP.
  This report is examines the history and effects of DOSP practiced as
  a conscious strategy; the effect of unplanned and unpredicted open
  source publication is also an interesting topic, but a separate
  one.}

Software producers have practiced DOSP throughout the history of free
and open source software.\footnote{We use the terms ``free software''
  and ``open source software'' synonymously throughout this report.}
However, surveying this phenomenon at a high level, from its
beginnings through today, shows some clear trends:

\emph{TBD: Everything below is tentative, draft, still a
  work-in-progress, etc.  Feel free to read and comment, but please do
  not consider anything from this point on to reflect the settled
  opinions of the authors nor of any organizations.}

\begin{itemize}

  \item The rise of the Business Source License (BUSL).

    Use of BUSL is really taking off.

    Deserves its own section --- see Section \ref{busl}.

  \item  Delayed unconditional release.

    Planned OSS releases with just a pre-defined time delay.

  \item Delayed event-driven regular release.

    OSS publication happens regularly, but is driven each time by some
    regular event (e.g., the publication of the latest proprietary
    version, which prompts the previous version to now be open
    sourced).

  \item Delayed conditional release.

    "We'll publish this as open source as soon as we get funding" or
    "as soon as we find the right non-profit home for it", etc.
    Probably includes bounty mechanisms, but only if these were
    intended --- that is, not ``buy-outs".

\end{itemize}

There are also post-hoc or unscheduled releases, where the authors
didn't originally plan to release the software as open source but
eventually decide to do so.  These aren't technically in scope, but we
should give some examples somewhere --- maybe in a footnote or
appendix --- just to make it clear that it's something that happens.

\numberedsection{Motivations}\label{motivations}

DOSP is usually described as protecting commercial interests of a software
developer by maintaining a window of time during which some users might be
incentivized to pay for licenses that they might not need if the software
were released as open source.

% Fit into discussions about incentive/funding models

We've also seen one-time delays for new projects whose developers state
a concrete intention to convert those projects to an open source license.
They may have non-economic reasons for those delays, such as shame about
poor code quality, concern about security issues that may be apparent in
unaudited source code, a need to procure permissions from other copyright
holders, a desire to establish a community or governance structure, or
a plan to incorporate a legal entity.


\numberedsection{Scheduled Relicensing}\label{scheduled}

\subsection{Early History}

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.  I found references to sendmail having
% a "traditional" dual license but so far have not found references to a
% scheduled relicensing practice.

% TrollTech story is complicated...
% https://tinf2.vub.ac.be/~dvermeir/manual/KDE20Development-html/ch19lev1sec4.html
% and more

\subsection{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\footnote{See \otsurl{https://north-road.com/slyr/}.},
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}

This strategy was also used by the OPSI project, which created a bounty-like ``co-funding" mechanism, which is still alluded to on the associated company's web site. Under this model, customers could sponsor the development of particular features, which would initially be available to sponsors and later to the public. However, this mechanism appears to have fallen out of use, as there are no recent co-funding opportunities, and the project currently appears to follow an open core model with paid subscriptions for proprietary extensions.

\subsection{The Business Source License (BUSL)}\label{busl}

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
used for MaxScale 2.1.0.\footnote{See
\otsurl{https://mariadb.com/resources/blog/releasing-bsl-1-1/}.}

BUSL requires a licensor to specify a ``Change Date" and a ``Change License".

MariaDB's Change Date for MaxScale is four years after the release of a
specific version, and its Change License is GPLv2.
% example: https://github.com/mariadb-corporation/MaxScale/blob/23.08/LICENSE2308.TXT

The Linux Foundation noted (\otsurl{https://www.linuxfoundation.org/blog/how-open-source-foundations-protect-the-licensing-integrity-of-open-source-projects})
that several prominent projects switched away from open-source licenses
from 2018 to 2023. Not all of these adopted DOSP licenses, but those that did
so adopted BUSL.
These included CockroachDB, Couchbase, Terraform, and ArangoDB. The most
prominent of these BUSL adopters was HashiCorp, which wrote

\begin{quote}
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}

This change applied to almost all of the company's software, including popular
software like Terraform, Vagrant, and HashiCorp Vault.

Although HashiCorp's license change attracted the most attention and
commentary, it's interesting to note that BUSL was originally written by
a database company and that the majority of the projects we've identified
that relicensed under BUSL are database systems. Some of the project
developers wrote that they wanted to discourage other companies from
competing directly with the developers' hosted database services, and that
they doubted whether an open source license would manage to accomplish
this. It's also possible that there was a degree of ``social contagion"
as database developers observed several of their peers relicensing away
from open source at roughly the same time, either to BUSL or to other
licenses that restrict licensees from operating commercial services.

Several licensors add an Additional Use Grant (AUG) under the BUSL to
allow for ``production" uses other than those that are considered to
compete with the developer's commercial services. For example,
ArcticDB provides the following Additional Use Grant\footnote{This same
text is also used by several other projects, and we have not determined
which project originated it. There are also other variants with similar
effect.}:

\begin{quote}
You may make use of the Licensed Work under the terms of this License,
provided that you may not use the Licensed Work for a Database Service.

A ``Database Service" is a commercial offering that allows third parties
(other than your employees and contractors) to access the functionality
of the Licensed Work by creating tables whose schemas are controlled by
such third parties.
\end{quote}

It appears that the project thus intends to immediately allow
\emph{commercial} uses, including for public services, as long as these
don't entail charging money for hosting databases in particular. Several
other BUSL adopters have analogous grants.

The AUG mechanism---including optional free-form text that exempts certain
uses from BUSL's ``production use" restrictions---complicates direct
comparison of uses of the BUSL; we have not yet devised a taxonomy
for making these comparisons.

% TODO Sort this table by date of BUSL adoption? ("BUSL date")
\begin{table}[]
\begin{tabular}{lllll}
\textbf{Project} & \textbf{BUSL date} & \textbf{Change Date} & \textbf{Change License} & \textbf{Reference} \\

Akka & 2022-09-07 & rel. +3 years & Apache v2 & \otsurl{https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka} \\

ArangoDB & 2023-10-11 & rel. +4 years & Apache v2 & \otsurl{https://arangodb.com/2023/10/evolving-arangodbs-licensing-model-for-a-sustainable-future/} \\

ArcticDB & [always] & rel. +2 years & Apache v2 & [no ref] \\
% https://github.com/man-group/ArcticDB/blob/master/LICENSE.txt

CockroachDB & 2019-06-04 & rel. +3 years & Apache v2 & \otsurl{https://www.cockroachlabs.com/docs/stable/licensing-faqs\#bsl} \\

CodeCov & 2023-08-02 & rel. +3 years & Apache v2 & \otsurl{https://about.codecov.io/blog/codecov-is-now-open-source/} \\

CouchBase & 2021-03-26 & rel. +4 years & Apache v2 & \otsurl{https://www.couchbase.com/blog/couchbase-adopts-bsl-license/} \\

DragonflyDB & 2022-05-29 & +5 years & Apache v2 & REF \\
% https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.md

evitaDB & [always] & 4th cal. year & Apache v2 & [no ref] \\
% https://github.com/FgForrest/evitaDB/blob/dev/LICENSE

Materialize\footnote{Not to be confused with the Materialize CSS project, which is released under the MIT license.} & 2020-02-07 & daily +4 years\footnote{Differently from other BUSL-licensed projects, Materialize uses a bot to update the Change Date every day (not just on the occasion of release events), so that it always reflects a date exactly four years after the present date.} & Apache v2 & REF \\

MaxScale & 2017-02-14 & rel. +4 years & GPL v2 & \otsurl{https://mariadb.com/resources/blog/releasing-bsl-1-1/} \\

Memgraph & 2021-10-03 & rel. +4 years & Apache v2 & REF \\
% https://github.com/memgraph/memgraph/blob/master/licenses/BSL.txt

ReadySet & 2022-08-03 & rel. +4 years & Apache v2 & REF \\
% https://github.com/readysettech/readyset/blob/main/LICENSE

Sentry & 2019-11-06 & rel. +3 years & Apache v2 & REF \\

SurrealDB & 2021-12-14 & rel. +4 years & Apache v2 & REF \\
% https://github.com/surrealdb/surrealdb/blob/main/LICENSE

Terraform (etc.) & 2023-08-10 & rel. +4 years & MPL 2.0 & REF \\
% TODO Maybe we should list each individual HashiCorp product to which
%      this relicensing applied, instead of the umbrella "etc."

ZeroTier & 2019-08-28 & 5th cal. year & Apache v2 & REF \\
\end{tabular}
\end{table}
% TODO: Do footnotes from a table not render properly?

\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.

\subsection{Consequences/Impacts?}

Projects that change from an open-source license to a delayed open-source
license have attracted criticism, with some people pledging to
switch to other projects or even to maintain competitive forks of the
prior open-source versions.  The most consequential such effort
appears to be OpenTofu, a fork of HashiCorp's Terraform announced soon
after Terraform was relicensed under BUSL.\footnote{See
\otsurl{https://opentofu.org/}.}
OpenTofu has announced several corporate sponsorships, apparently plans
to hire multiple full-time developers, and has organized itself as a
project of the Linux Foundation. The fork's creators complained that
the prior open source license of Terraform had encouraged people to
develop professional expertise with the software and to use it as a part
of their infrastructure.
% One could say much more about this both in terms of commercial strategy
% and also in terms of users' subjective feelings of betrayal.
They also noted concerns about whether Terraform users could be confident
about whether their individual uses were considered commercially
competitive with HashiCorp.

Most other forks of recently-relicensed software have not attracted the
same levels of attention, participation, or adoption.

% yes for Vagrant -> Viagrunt, although OpenTofu got vastly more support
% and activity

It could be harder for projects under non-open-source terms to receive
or accept outside contributions, both because people may be less motivated
to make them and because the licensing status of the resulting contributions
is more complicated. However, some projects that have switched to BUSL (or
other licenses) continue to accept outside contributions subject to a
contributor license agreement (``CLA"), which grants certain rights to the
original developer. HashiCorp, for example, has a CLA for its
projects\footnote{See, for example,
\otsurl{https://cla.hashicorp.com/hashicorp/terraform}.}, and a bot that
checks whether the authors of pull requests have signed it, so that their
contributions will not be incorporated into the codebase until and unless
they do so. The company does continue to receive some outside code
contributions to its BUSL-licensed projects, including Terraform.
% TODO: Has the rate measurably decreased?
%
% TODO: Did they have this requirement before relicensing? Some open source
%       projects do have comparable CLAs for outside contributions to
%       become part of their official upstream code bases. It's not only a
%       BUSL/DOSP/proprietary licensing phenomenon.

\subsection{Other}

The Child Mind Institute uses its Delayed Open Source Attribution License
(DOSA), which has a three-year period in which only noncommercial uses
are permitted, for its MindLogger software.
% https://github.com/ChildMindInstitute

The Poké Classic Framework
has a conditional license which limits uses of the code but which
converts to AGPL if the original developer ceases to operate a service
based on the code.\footnote{See
\otsurl{https://github.com/mm201/pkmn-classic-framework}.}

Sentry has released a draft of its ``Functional Source License" (FSL),
which it hopes to use for its own currently BUSL-licensed software, at
\otsurl{https://fsl.software/}.\footnote{Disclosure:
% TODO: What is the right phrasing for the disclosure here?
}
The FSL prohibits, during a period of one year, uses of covered software
to provide services that ``compete" with the original developer's commercial
service offerings.  Following this period, the software is licensed under
BSD or Apache terms, without the competition restriction.

Several cloud-oriented software projects that switched away from open
source licensing in the past few years also adopted license terms with
non-competition clauses. However, these generally were not time-limited.
% TODO: double-check whether any of them were time-limited

% TODO: This relates back to the AUG topic because so many of the database
%       companies added AUGs saying that you can do anything you want as
%       long as it isn't selling hosting of the software and/or doesn't
%       commercially compete with the developer. The non-time-limited
%       licenses do something very similar. And Sentry is also doing the
%       same thing with FSL, but putting it in the core license rather
%       than in a BUSL AUG.

% I think it's interesting that the AGPL doesn't seem to appeal to most
% companies that are pursuing this kind of thing. I don't know if any of
% them have commented on their views about it.

\numberedsection{Enforceability}\label{enforce}

Delayed open source licensing is less explored than immediate open source
licensing, and some observers have expressed concerns about its legal
enforceability. For example, if an author died before the announced license
transition date, would the author's heirs be required to honor the license
transition, or could they potentially cancel or withdraw it? What if a
company were acquired by a new owner which wanted to retroactively change
its licensing structure?

% XXX We obviously don't know yet because ...

The Creative Commons research on springing licenses expressed some concerns
about their enforceability. The Creative Commons organization itself
previously implemented a delayed licensing mechanism called Founders
Copyright; unlike other Creative Commons licenses, the Founders Copyright
involves a copyright assignment to the Creative Commons nonprofit
organization itself. The organization then commits to grant the original
author an exclusive license to the for the announced delay period, and
to license the work to the public afterward. It appears that this copyright
assignment mechanism was intended to minimize uncertainty about the
extent to which authors could bind themselves (or their successors) to
future licensing intentions, although it required direct involvement by
the nonprofit as copyright holder and licensor, a role it had otherwise
not seen fit to take on.

Kyle E. Mitchell distinguishes ``a present grant of a license" (with a
specified future start date) from ``a contractual promise to grant the
license later" and advocates using the former, although he does not
imply that the latter is invalid or unenforceable. Mitchell's concerns
focus on clarity and persistent documentation of specific license
grants to specific code and project versions.

\numberedsection{``Grace Period" Reciprocal Licensing}\label{grace}

One licensing practice often described as related to DOSP is implemented
in the Bootstrap Open Source License (BOSL), previously called the
Transitive Grace Period Public License (TGPPL).  This license was mainly
devised by Zooko Wilcox-O'Hearn.\footnote{It implements a strategy previously
proposed by Ted Ts'o, at \otsurl{https://thunk.org/tytso/TPL.html}.}

% https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2013-July/018428.html
% TGPPL was submitted for OSI review in 2009 (!) but was never approved.
% There are some discussions that seem to imply that people were reluctant
% to approve it from nascent concerns over license proliferation and some
% prudential concerns about whether this was the right approach to
% relicensing.

It is worth pointing out that the BOSL has no connection to the Bootstrap
web framework project, which is under the MIT license. Both projects
independently use the term ``bootstrap" to refer to the concept of
bootstrapping.

Instead of making an initially proprietary license grant that later
transforms into an open-source license, the BOSL makes an initially
permissive (BSD-style) license grant that later transforms into a
reciprocal (GPL-style) license. This is intended to allow downstream
code reuse in proprietary software projects, but only for a limited
time, something Zooko characterized as a compromise between
permissive and reciprocal open source licensing models.\footnote{See,
for example, the presentation at
\otsurl{https://tahoe-lafs.org/\textasciitilde{}zooko/tgppl.pdf}.}
% TODO: Get rid of the {} that shows up in the link target

Since both the start and end-state licenses of the BOSL are themselves
open source, we do not regard the BOSL as a form of delayed open-source
publication as defined by this report. Rather, it seems to be an
unconventional form of open source publication with time-varying open
source terms. While the BOSL has not been approved by the Open Source
Initiative, it appears to us to be compatible with the Open Source
Definition, and --- unlike BUSL, for instance --- is claimed by its
authors to be a form of open source licensing.

One way to view the distinction between delayed open-source licensing and
grace period reciprocal licensing is that the former aims to compromise
between proprietary and open source licensing, where the latter aims
to compromise between permissive and reciprocal licensing --- in both
cases by modifying the license terms after a delay.

\numberedsection{Other Terminology and Practices}\label{terminology}

We've encountered a number of other terms that can describe DOSP or
the licensing mechanisms used to implement it.

\begin{itemize}

   \item Eventual (open) source; scheduled licensing.

   Lawrence Rosen's book on open source licensing refers to ``eventual source"
   or ``eventually open source" software, giving the example of Aladdin
   GhostScript. He also calls this ``scheduled licensing".

   \item Springing licenses.

   A research report from Creative Commons refers to ``springing licenses"
   (licenses that grant additional permissions after a period of time, or
   when some other condition has been met). Creative Commons was mainly
   interested in the possibility of developing licenses that would grant
   additional permissions over time, after a period of greater exclusivity.

   \item Scheduled relicensing.

   Kyle E. Mitchell refers to ``scheduled relicensing".

\end{itemize}

One can also distinguish between a public pledge to relicense on a schedule
(as GhostScript did) and a license document whose text includes date or
other restrictions. In the former case, the delayed release is implemented
by human beings (actively making a new software release including new
license text); in the latter case, it is automatic.

We do not consider ``unplanned" open source releases to be examples of DOSP.
There are a number of high-profile cases of proprietary projects that were
retroactively relicensed as open source as a result of a one-off decision.
Where developers originally had no announced plan or intention to do this,
we think this is best considered a separate phenomenon, not a ``delayed"
release.

Many people also mentioned the custom among some video game developers of
releasing code (though usually not assets such as graphics and sound)
from proprietary video games that are no longer commercially important.
This is a relatively widespread practice, with Wikipedia identifying
dozens of instances.\footnote{Wikipedia lists these examples at
\otsurl{https://en.wikipedia.org/wiki/List\_of\_commercial\_video\_games\_with\_later\_released\_source\_code}.}

Some companies like id Software have made such releases for multiple video
game generations.
While many of these developers apparently had a general intention to make
their games open source, in whole or in part, at some point in the future,
there was usually no public commitment to do so on any particular
schedule or under any particular circumstances.  This practice is thus not
a core example of DOSP.

A ``delayed open access" model, applied to research articles, has become
popular for academic journals as a compromise between more restrictive
journal licensing and open-access publishing.\footnote{See
\otsurl{https://en.wikipedia.org/wiki/Delayed\_open-access\_journal}.}
As of November 2023, Wikipedia identifies by name 108 journals that
currently follow some form of this model, but cites a 2013 study that
reportedly reviewed 492 journals with such a policy. In this context,
journals may apply an ``embargo period" to create an incentive for some
journal users to pay for subscriptions or article access in order to
read recent research. The license terms applied at the expiration of these
embargo periods permit the public to read articles at no charge, but
may or may not be equivalent to open source licensing.

\numberedsection{Sources and References}\label{sources}

\begin{itemize}

\item \otscite{Creative Commons Final Report: On the Viability and
    Development of Springing Licenses}\\
  \otsurl{https://creativecommons.org/wp-content/uploads/2018/07/Springing-licenses-FINAL.pdf}

% https://writing.kemitchell.com/2023/10/24/Scheduled-Relicensing

  \item \otscite{Wikipedia: List of Commercial Video Games With Later Released Source Code}\\
	\otsurl{https://en.wikipedia.org/wiki/List\_of\_commercial\_video\_games\_with\_later\_released\_source\_code}

\end{itemize}

\numberedsection{Acknowledgements}\label{acknowledgements-sow}

TBD
% Two examples learned from https://blog.adamretter.org.uk/business-source-license-adoption/

\BLOCK{endblock}