dosp-survey.ltx

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

%% extends "report.ltx"

\BLOCK{block preamble}
\usepackage{longtable}
\BLOCK{endblock}

\BLOCK{block body}

\begin{center}
  Seth Schoen, James Vasile, Karl Fogel
\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\footnote{We use the term ``Open Source'' throughout for
  compatibility with the Open Source Initiative's style guide, as the
  OSI supported the production of this report.  We mean by that term
  the same thing that people also use the terms ``free software'' or
  ``free and open source software'' to refer to.  While we could use
  ``free software'' interchangeably with ``Open Source'' --- that too
  would be compatible with OSI's style guide --- for the sake of
  consistency we have chosen to just use ``Open Source'' throughout.}
license.\footnote{Note that this definition of DOSP 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 or
  unpredicted Open Source publication is also an interesting topic,
  but a separate one.}

Software producers have practiced DOSP throughout the history of Open
Source software.  This document is a selective survey of that history.
It collects and categorizes sample products and tries to identify some
patterns and trends.

Based on the examples we found, we categorize DOSP into three
high-level types:

\begin{itemize}

  \item Unconditional scheduled relicensing.

    Planned OSS releases with just a pre-defined time delay.  See
    Section \ref{scheduled}.

  \item Event-driven relicensing.

    OSS publication happens regularly, but is driven each time by some
    expected event, e.g., the publication of the latest proprietary
    version, which prompts the previous version to now be open
    sourced.  See Section \ref{TBD-event-driven}

  \item Conditional relicensing.

    ``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.
    This can include bounty mechanisms, but only if they were planned
    --- that is, it does not include ``buy-outs''.

    This type is probably the weakest match for our working definition
    of DOSP, though it is technically a match.  Unsurprisingly, stated
    intentions to release under Open Source license do not always
    result in that actually happening.  Still, when it does happen,
    it is an instance of DOSP.

\end{itemize}

We saw two trends that seem significant:

\begin{itemize}

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

    Use of BUSL is growing rapidly.  See Section \ref{busl}.

  \item Anti-competitive terms are becoming more common.

    Traditional DOSP was typically about monopolizing direct
    commercial revenue: the license would grant most of the
    permissions necessary for Open Source but, crucially, withold
    permission to use the software commercially\footnote{This causes
      the license to fail clause 6, ``No Discrimination Against Fields
      of Endeavor'', in the Open Source Definition (see
      \otsurl{https://opensource.org/definition-annotated/}).} --- a
    restriction that would apply to all downstream licensees, i.e., to
    users, not merely to developers.

    More recently, however, some DOSP licenses are about preventing
    any licensee from using the software in a product that competes
    with certain specific types of software that are strategically
    important to the licensor, regardless of revenue.  See Section
    \ref{TBD-competition}.

\end{itemize}

This is just an initial survey and a first-pass analysis.  It uncovers
many interesting questions that we must leave for future research,
some of which are listed in Section \ref{future}.  Among the most
important of these are:

\begin{itemize}

  \item Why do organizations so often choose a non-Open Source license
    (such as the BUSL) and a DOSP release arrangement when simply
    publishing under the AGPL\footnote{The Affero General Public
      License --- an Open Source license specifically designed to
      ensure freedom from monopoly in network-based application
      service provision as well as in traditional file-based
      distribution.  See
      \otsurl{https://en.wikipedia.org/wiki/Affero\_General\_Public\_License}.}
    from the start would presumably meet their goals just as well?

  \item When BUSL-licensed projects have different contribution
    dynamics than truly Open Source projects, and when (if ever) do
    they have similar dynamics?

  \item When DOSP is introduced into a previously fully Open Source
    project, by the majority copyright holder, under what
    circumstances does this tend to cause a viable fork occur?
    % [ref:091db178]

\end{itemize}

Just as Open Source gradually shook out into a handful of licenses
that are used by the vast majority of projects, we might be seeing a
convergence toward a recognizable and relatively small set of DOSP
licenses.  It is too soon to know for sure if the current options will
settle in as the standard.  The list of most-used Open Source licenses
has been quite stable for over a decade now, and there is little
reason to think it will change any time soon.  With DOSP licenses,
though, it is possible we are still in a period of
experimentation. Today's handful of commonly-used licenses may just be
a precursor to tomorrow's recognized standard.

% TODO: Karl commented the stuff below out of the draft version that
% we sent on 2023-11-22:
%
% 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.
%
% [...]
%
% DOSP approaches belong to a class of approaches and licenses that
% sit somewhere between traditional proprietary approaches and
% full-fledged Open Source licenses.  These models of software
% release, which we might call ``public collaboration'' models, are
% often quite similar (or even based on) traditionally recognized Open
% Source practices.  They are designed to foster public collaboration
% and distributed development, just like Open Source.  But unlike
% traditional Open Source, they tend to apply some additional
% restrictions that restrict collaboration.
% 
% These restrictions vary based on the business or social goals of the
% software effort.  In some cases, as here, we see time delays (mostly
% used to provide a period of exclusive commercial exploitation) and
% in others, we see field-of-use restrictions.  FOU restrictions may
% also be used to protect commercial interests, but are also commonly
% designed for social goals.\footnote{See the Organization For Ethical
% Source at \otsurl{https://ethicalsource.dev/licenses/} and the
% Anti-996 License at
% \otsurl{https://github.com/996icu/996.ICU/blob/master/LICENSE} for
% two contemporary efforts that use public collaboration licenses to
% exclude what they see as socially harmful usage of collective
% labor.}  In either case, though, the intended effect is market
% segmentation.  DOSP segments the market into a group of public, Open
% Source particpants and a set of companies willing to pay for the
% latest features and proprietary use.  Ethics-focused FOU licenses
% segment the software's audience into a group of Open Source-like,
% public collaborators and a set of actors who do not meet the social
% standards of the software creators.  In both cases, the aim of the
% public collaboration license is exclusive exploitation to advantage
% one group and not the other.

\numberedsection{Early History}

The earliest notable use of DOSP we found is Aladdin GhostScript,
which was a relicensing (by its original author) around 1998 of the
originally GPL-licensed GhostScript project under the ``Aladdin Free
Public License''.  Aladdin's practice was to publish all new versions
of the software under this license, which did not permit commercial
redistribution.  Aladdin also published versions of its software under
GPL once they were older than about a year, initially as ``GNU
Ghostscript'' and later as ``GPL Ghostscript''.\footnote{CITE}

GhostScript's author, L. Peter Deutsch, described this practice as
providing commercial exclusivity that would help fund continued
development of the project.\footnote{CITE} This is a commonly cited
motivation for adopting DOSP.
% Sort of described in https://web.archive.org/web/20070816214332/http://pages.cs.wisc.edu/~ghost/doc/AFPL/6.01/New-user.htm#Commercial_use which mentions
% the availability of paid proprietary licenses, but this doesn't
% explicitly say that the revenue is going to be used to promote continued
% development.

Interestingly, GhostScript's makers eventually dropped the delay in
favor of straight-up proprietary-relicensing.\footnote{This practice
  is sometimes also called ``dual-licensing''.  That term can be
  ambiguous, however, having historically also referred to releasing
  Open Source software under two or more Open Source licenses
  simultaneously.  Bradley Kuhn pointed this out long ago to one of
  the authors (Karl Fogel) and suggested the more accurate term
  ``proprietary relicensing''; we thank him again for it.}  With this
approach, they simultaneously release GhostScript under both a
proprietary license and GPL.\footnote{This change was made in 2006.
  See
  \otsurl{https://web.archive.org/web/20161003082642/http://ghostscript.com/News.html}.}
They continue to use this model today, though they have since replaced
GPL with AGPL.\footnote{See
  \otsurl{https://ghostscript.com/licensing/index.html}.} They
determined that their market of commercial, embedded developers were
paying to avoid the GPL and AGPL, and that the time-delay did not
significantly change these companies' incentives to pay for
licenses.\footnote{CITE to Rosen's book?}

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

Another early example of DOSP is KDE's Qt library, which committed to
a form of DOSP as a minimum guarantee.  KDE is a desktop environment
built using the Qt GUI library.  Over the years, the company that
produces Qt, Trolltech, has experimented with a variety of public
collaboration approaches that includes a mix of Open Source and
non-Open Source approaches.\footnote{Some of them might be called
  ``visible source'': the source code was, as far as we can tell,
  always available, just not always with all the freedoms guaranteed
  by the Open Source Definition.}

When KDE adopted Qt as its GUI toolkit, ``lock-in'' concerns about
reliance on a codebase owned by a commercial company led to a series
of agreements between a KDE nonprofit and Trolltech.  The original
license allowed the KDE Free Qt Foundation to release a version of Qt
under BSD license if Trolltech substantially stopped Qt development
for more than a year.\footnote{See
  \otsurl{https://kde.org/community/whatiskde/kdefreeqtfoundation}.}
Moreover, a series of contracts between KDE's nonprofit and successive
Qt copyright holders include commitments to release Qt versions under
specific Open Source license terms ``within a timeframe of not more
than 12 months'' relative to any proprietary release.\footnote{See
  \textit{id.}, which includes the exact language of the licensors'
  contractual commitments; a portion of the historical context is also
  described in
  \otsurl{https://tinf2.vub.ac.be/$\sim$dvermeir/manual/KDE20Development-html/ch19lev1sec4.html}.}

The Qt licensors did maintain separate ``Qt Commercial Edition'' and
``Qt Open Source Edition'' releases for some time; the latter complied
with the licensors' commitments under the agreements. We haven't
identified evidence of a significant gap in time or functionality
between these releases, although such gaps may have existed.  The
agreements established minimal standards for the protection of KDE,
but Qt's various copyright holders appear to have generally exceeded
those standards in any case.  DOSP ended up being a fall-back scenario
for two different conditions that didn't arise in practice
(unreasonably delayed Open Source releases, or complete
discontinuation of upstream development).  It appears that Qt
licensors usually understood their commercial strategy as akin to a
more conventional dual license, where proprietary adopters would pay
for the Commercial Edition in order not to incur copyleft
obligations. Making generalizations about this strategy is
complicated, as several different commercial entities acquired Qt over
time and may have had somewhat different understandings.

Today, all of Qt is released simultaneously under LGPL/GPL and
proprietary dual licenses.\footnote{The Qt Group states that there is
  currently one exception where it doesn't have the right to grant a
  proprietary license for a specific module, the Qt WebEngine, which
  is only available under LGPL v2.1.  See
  \otsurl{https://www.qt.io/download-open-source}.}

GhostScript and Qt are the two earliest projects we found making
documented use of DOSP.  They used them in different ways, but both
related in a broad sense to attempts to protect a licensor's
commercial interests.  As we will see from later projects, this is the
most common use of DOSP.  However, neither of these projects actively
practices DOSP today.

\numberedsection{Scheduled Relicensing}\label{scheduled}

\subsection{Proprietary Ramp-up, Eventually Open Source (Pre-Open Source)}\label{motivations}

DOSP is usually adopted as an ongoing commercial strategy.  It
reserves a window of time for a company to sell the latest features
under proprietary license before they become available to all under
open license.

In addition to this common form of DOSP, we find delayed publication
occurs in another notable form.  In this form, projects plan to
eventually be fully open but initially operate in a less open manner.
The plan for such projects is to become full-fledged Open Source
efforts once the project has matured or stabilized. This
\textbf{one-time} delay at the start of a new project is, to us,
different enough from other DOSP that maybe it should be placed in a
whole other category.  Either way, it is a notable form of time-delay
in the Open Source world.

% Fit into discussions about incentive/funding models

These projects begin development in a proprietary mode.  During this
pre-open-source period, their practices might reflect just about any
variation of non-open-source software. They might not publish any
code.  Or release their code under non-Open Source license, including
by not explicitly specifying a license.  They might only release
binaries or release nothing. In short, these projects range from
wholly, traditionally proprietary in nature to public collaborations
that stop just short of a Open Source license.

Usually, these projects explain that they plan to become open, explain
why it hasn't happened yet, and describe (sometimes vaguely) the
conditions that will trigger a re-licensing toward Open Source.

There are many possible reasons why a project might start out with
some public visibility, whether of source or binaries, but not
initially ship Open Source code.  The ones we have
observed:\footnote{CITE everything in this list}

\begin{itemize}
  \item shame about poor code quality
  \item concern about security issues that may be apparent in
    unaudited source code
  \item initial uncertainty about which license to choose
  \item a need to procure permissions from other copyright holders
  \item a desire to establish a community, governance, or a legal
    entity
\end{itemize}

Although these scenarios involve an intent to publish something as
Open Source in the future, they are also rather different from the
DOSP cases we focus on in the rest of this document.  They differ, for
example with regard to whether the delay is \emph{desired} by the
authors, whether it's \emph{predictable} to users, and whether it's
expected to \emph{recur}.  Projects that start out proprietary with a
stated plan to go open eventually are not practicing DOSP as a
business model. While one might usefully consider the question of when
to deviate from the principle of ``be open from day
one'',\footnote{See
  \otsurl{http://archive.civiccommons.org/2011/01/be-open-from-day-one/index.html}
  for more about this principle.} the commercially interesting
tradeoffs are mostly found in projects that opt for an ongoing DOSP
strategy.

% The BUSL AUGs also seem to show (especially among database
% developers?)  a desire to prohibit direct competition with the
% original developer's own business. A significant number of BUSL AUGs
% explicitly allow commercial production use if it doesn't compete
% commercially with the original developer. Are there particular
% stories about how this has happened? Has it happened repeatedly? Is
% it something investors are especially concerned about?

% Some people say Amazon hosted a MongoDB-as-a-service product which
% prompted MongoDB's relicensing from AGPL to SSPL in 2018. (Then in
% 2019 Amazon announced DocumentDB, a reimplementation of portions of
% the MongoDB API, which Amazon provides exclusively as a service
% within AWS -- no source code.)  So far I haven't found any
% documentation of what AWS had in terms of MongoDB-as-a-service prior
% to 2019. Most search results relate to the announcement of
% DocumentDB in 2019, but that seems to be Amazon's reaction to the
% SSPL relicensing. What, if anything, was AWS doing before 2019 that
% may have prompted that relicensing?
%
% People also mentioned Elasticsearch and OpenSearch - I haven't
% looked into that.

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

By default, BUSL prohibits uses in ``production'' before the Change
Date.  Licensors using the bare BUSL would thus expect commercial
adopters to pay for a separate license permitting commercial
use. However, 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 own 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: This \newpage is necessary right now, otherwise the builm
% hangs because of the big longtable below.  There might be a better
% fix, and if I have time I'll look for it.
\newpage

% TODO: This table builds, but it goes off the right edge of the page.
% Karl thinks Seth should go ahead and fill in all the REF markers
% below, and then afterwards Karl will worry about how to format this
% (various solutions are available).
\begin{longtable}[l]{l l l l l}
\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\footnote{Sentry subsequently relicensed under its own ``Functional Source
License''; see below for further discussion.} & 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.)\footnote{``HashiCorp Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, and Vagrant'' are identified as relicensed by \otsurl{https://www.hashicorp.com/license-faq}.} & 2023-08-10 & rel. +4 years & MPL 2.0 & REF \\

ZeroTier & 2019-08-28 & 5th cal. year & Apache v2 & REF \\
\end{longtable}

\subsection{Differences From Other Licensing Strategies}\label{differences}

MariaDB describes some of these differences as follows:\footnote{The
  quotation is from \otsurl{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.

% there's also a fork 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.  HashiCorp's CLA is ``non-exclusive''; an outside
contributor could conceivably continue to contribute the same patches
to a HashiCorp BUSL project and a non-HashiCorp fork of the same
project, assuming that the codebases haven't diverged too far over
time to make this practical.

% TODO: Has the rate measurably decreased?
% TODO: E.g. compare hashicorp vs. non-hashicorp addresses for contributions
%       but note limitations of this method
%       Also did bugtracker activity change?
%
% 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 created its own Delayed Open Source
Attribution License (DOSA), which has a three-year period in which
only noncommercial uses are permitted, for its MindLogger
software.\footnote{The developers even announced this in a journal
  article announcing the development of the software. See Arno Klein
  \foreignphrase{et al.}, ``Remote Digital Psychiatry for Mobile
  Mental Health Assessment and Therapy: MindLogger Platform
  Development Study'' (2021), available at
  \otsurl{https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8663601/}; for
  the license text, see
  \otsurl{https://github.com/ChildMindInstitute/DOSA-license}.}
However, as of 2023, MindLogger and other projects from the Child Mind
Institute are licensed under the CPAL Open Source license, with no
associated delay.

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

Roughly contemporaneously with MariaDB's development of BUSL, Ben
Boyter proposed a ``GPL time bomb'' (later renamed to simply
``eventually open'') that is conceptually similar to BUSL with an AUG
specifying a limited number of users within an
organization.\footnote{See
  \otsurl{https://boyter.org/2016/08/gpl-time-bomb-interesting-approach-foss-licensing/}.}
This approach was used for Boyter's ``searchcode-server''
project\footnote{See \otsurl{https://www.searchcode.com/}.}, but no
new development has taken place on this codebase since 2020, so the
whole project is apparently now licensed under GPL v3.

In November 2023, Sentry published its own ``Functional Source
License'' (FSL), at \otsurl{https://fsl.software/}, and relicensed its
own previously BUSL-licensed software under it.\footnote{See Sentry's
  announcement and discussion at
  \otsurl{https://blog.sentry.io/introduction-the-functional-source-license-freedom-without-free-riding/}.
  Disclosure:
  % TODO: What is the right phrasing for the disclosure here?
} The FSL prohibits, during a period of two years, uses of covered
software to provide services that ``compete'' with the original
developer's commercial service offerings. Other uses are generally
permitted. Following this two-year period, the software is licensed
under MIT or Apache terms, without the competition
restriction.\footnote{FSL exists in exactly two variants, one which
  converts to the MIT license after two years, and one which converts
  to the Apache 2.0 license after two years.}

BUSL expressly permits certain parameters to be set by each individual
adopter (including arbitrary free-form license text in AUGs, so long
as that text grants additional permissions rather than removing them).
Sentry disapproved of the resulting proliferation of variant terms and
differently-phrased AUGs; it stated that, from the licensee's point of
view, each BUSL instance is actually a substantively different
license.  Accordingly, the FSL roughly follows the BUSL's approach,
while freezing a particular set of terms.

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 (but permanently, without any time limits).
Conversely, several projects that adopted BUSL included AUGs that
allow commercial uses so long as these aren't charging third parties
for the service of hosting instances of the software, or so long as
they don't otherwise compete with the original developer's own service
offerings.  The FSL codifies a version of this policy in the main
license itself, rather than adding it as an optional additional
permission.

\numberedsection{``Grace Period'' Reciprocal Licensing}\label{grace}
% TODO: This can go as a subsection of the ``differences from other
% licensing strategies'' section?

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 Wilcox-O'Hearn characterized as a compromise between
permissive and reciprocal Open Source licensing models.\footnote{See,
  for example, the presentation at
  \otsurl{https://tahoe-lafs.org/$\sim$zooko/tgppl.pdf}.}
% TODO: Karl is working on getting a fully functioning tilde here.
% 
% The problems with \textasciitilde are that it a) looks bad (too
% high), and b) in the underlying URL (i.e., what you browse to if you
% click on the URL in the text in the PDF) doesn't have a "~" there
% but instead has the raw LaTeX code.  I've tried playing around with
% the definition of \otsurl in ots-doctools/latex/ots.sty, but so far
% that hasn't led to a solution.
%
% Note that the wrong-URL problem also happens with the math-mode
% "$\sim$" solution currently in place, but at least the tilde looks
% good in the PDF.  So that's something.
%
% I tried "\texttildelow" too (with "\usepackage{textcomp}" up in the
% preamble), but that just errored -- even though the command is
% well-documented on the Net.  So there's another mystery.
% 
% Some days you win, some days LaTeX wins.  But really, most days
% LaTeX wins.
%
% Still working on this.

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}.}
The released game code is most often licensed under an established
Open Source license.

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{Conclusions}\label{conclusions}

DOSP has been in use since the early days of Open
Source.\footnote{Some of that period occurred before the term ``Open
  Source'' was coined in the context of software licensing; the term
  ``free software'' was the most commonly used term for this kind of
  licensing then.}  Companies (it's always companies) tend to use it
to preserve commercial advantage while still taking advantage of Open
Source dynamics.  We suspect that as the delay increases, the benefits
of Open Source decrease. Exploring the tradeoff between those benefits
and the period of exclusive exploitation might merit future research.

From this research and in conversation with OTS's clients, we see some
evidence that DOSP works best for fast-moving, cutting-edge software,
where access to the latest features is commercially significant.  For
software whose year-old versions are suitable replacements for the
latest proprietary versions, the market segmentation offered by DOSP
disappears.  Those cases essentially collapse down to a
proprietary-licensing scheme with proprietary and A/GPL options.

\numberedsection{Future Research Questions}\label{future}

\begin{itemize}

  \item \textbf{AGPL versus DOSP licensing.}

    TODO: rewrite to say more directly that many, and sometimes all,
    of the goals that people have when they choose BUSL could be
    achieved by using AGPL instead.  So why are they not choosing
    AGPL?

    % Sample discussion at
    % https://news.ycombinator.com/item?id=38162275 but it isn't the
    % only one. But we plausibly don't necessarily need to point to
    % specific discussions.

    The GNU Affero General Public License (AGPL)\footnote{See
      \otsurl{https://www.gnu.org/licenses/agpl-3.0.html}.} arguably
    aims to address some of the same concerns as the BUSL or the FSL
    --- particularly concerns about some forms of free-riding by
    downstream adopters. Instead of forbidding commercial (or
    competitive) uses, the AGPL imposes a copyleft-like requirement to
    publicly disclose and publicly license the source code of
    modifications, whenever those modifications are used to operate
    publicly-accessible services.

    The authors of this report have observed debates about the
    relative merits of the AGPL and BUSL. Interestingly, proponents of
    each license often agreed that both licenses might, in principle,
    address similar concerns about companies adopting an Open Source
    code base --- sometimes in direct competition with the original
    developer's services --- without rewarding its original developer
    either with money or with code contributions.\footnote{Critics of
      both licenses have similarly argued that it might be hard to
      tell exactly which activities related to online service
      provision are meant to be ``caught'', in comparison to more
      permissive licenses.} However, the proponents didn't agree about
    which license better responds to this scenario.

    Did any BUSL adopters seriously consider adopting AGPL? If not,
    why not?  If so, why did they end up preferring BUSL's approach?

    % MongoDB was previously licensed under AGPL and then switched to
    % SSPL, which it has maintained should be considered an Open
    % Source license.  The OSI review process didn't agree, although
    % it was controversial.  Apparently from MongoDB's point of view,
    % it was just trying to shift from one Open Source license to
    % another (that would disincentivize some competitive behavior
    % that the developers found unfair or undesirable).  But from the
    % outside world's perspective, since SSPL isn't uniformly accepted
    % as Open Source, this was a switch from Open Source to
    % proprietary (and also not DOSP because there is no time period
    % after which the code reverts to a conventional license).
    % 
    % I haven't managed to find out whether it's correct that AWS was
    % offering MongoDB-as-a-service before the relicensing in 2018.

  \item \textbf{Effects on outside contributions.}

    How much are outside contributions affected by using (or switching
    to) a DOSP model rather than an Open Source license?  Can any
    contribution trends be clearly and confidently attributed to
    relicensing?

  \item \textbf{Taxonomy of BUSL Additional Use Grants.}

    The BUSL default is to prohibit production use, but most adopters
    of BUSL have used AUG clauses that grant permission for production
    use that doesn't compete commercially with the software
    developers' own business, or concretely that doesn't involve
    charging for access to a hosted instance of the software.

    How similar are the different formulations of this notion? Are
    there any other permissions that appear in practice in BUSL AUG
    clauses beyond the notion of not competing with services run by or
    licensed by the upstream developer? Is there a significant
    minority of BUSL adopters that aim to restrict (and sell licenses
    for) ``production'' use more generally?

  \item \textbf{Relicensing after initial Open Source publication.}

    Is it a conscious strategy --- or at least a conspicuous option
    --- to start out a new project under a purely Open Source license
    in order to garner interest and mindshare, and then subsequently
    relicense under a DOSP license? Some of HashiCorp's critics noted
    that the company had given adopters incentives to become expert
    in, or otherwise reliant upon, the company's software while it was
    under an Open Source license, and then tried to benefit from that
    familiarity and adoption by changing the license terms in the
    future.

    If some of the most popular DOSP-relicensed projects had started
    out under DOSP rather than Open Source terms from the outset,
    would they have attracted the same level of interest and adoption?

  \item \textbf{Why has a fork of Terraform attracted so many
      contributions and so much interest compared to forks of other
      projects?} % TODO: See ref:091db178 -- maybe this question
                 % should be recast.

    It's too early to say whether the OpenTofu project will broadly
    outcompete Terraform among various audiences, but it's clear that
    this fork started off with a bang, immediately garnering
    substantial interest, sponsorships and financial commitments, and
    endorsements from various companies and developers. However, Open
    Source forks of other HashiCorp projects are comparatively
    stagnant and underpublicized. Similarly, other BUSL relicensing
    events did not seem to result in highly active forks (although
    some may have increased interest in existing Open Source
    competitors to the relicensed projects).

    What's special about the OpenTofu effort, or about Terraform or
    its community, that could account for these differences? Did
    Terraform's market share in its niche play a large role? Was
    Terraform particularly indispensable for its users in comparison
    to some other relicensed projects?