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

\emph{TBD: Everything from this point on is tentative, still a work in
  progress, etc.  Please do not consider anything below to reflect the
  final opinions of the authors, and please do not quote from this
  draft in public forums.  While we prefer to work in the open, that
  doesn't mean we want to engage with strangers' comments on an
  incomplete analysis.}

The most important trends we found are:

\begin{itemize}

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

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

  \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
    regular event, e.g., the publication of the latest proprietary
    version, which prompts the previous version to now be open
    sourced.

  \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 probably includes bounty mechanisms, but only if they were
    intended --- that is, it does not include ``buy-outs''.

    \emph{James thinks this may not quite be DOSP in the sense we
      usually mean, although it's a category that quite a few people
      wrote in about.}

  \item TBD: Discussion of contribution/participation patterns in DOSP
    projects versus in Open-Source-from-the-start projects.

\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 
dual-licensing.\footnote{This change was made in 2006. 
See \otsurl{https://web.archive.org/web/20161003082642/http://ghostscript.com/News.html}.
}
With this approach, they
simultaneously release GhostScript under both a proprietary license and GPL.
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 not-quite Open Source, commercial approaches.

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 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 this
case, DOSP was 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 but not yet ship Open Source code.  The ones we have observed:\footnote{CITE everything in this list}

% TODO: Karl notes: the first two items in the list below would argue
% against source code visibility at all, not just against visibility
% under Open Source license.  We might want to make that clearer.

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


\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 Re-insert the BUSL table (busl-table.ltx)!

\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
% TODO Suggest further-research question

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{future}

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 dual-licensing scheme with proprietary and A/GPL options.

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

\begin{itemize}
	\item DOSP versus AGPL licensing.

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

% TODO I thought I saw something about MongoDB considering AGPL but
% deciding that its (non-DOSP) noncompete license model was preferable.

	\item 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 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 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 Why has a fork of Terraform attracted so many contributions and so much interest compared to forks of other projects?

 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?

\end{itemize}

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