Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • ots/dosp-research
  • gedankenstuecke/dosp-research
  • msw/dosp-research
  • chadwhitacre/dosp-research
4 results
Show changes
Commits on Source (97)
Hide whitespace changes
Inline Side-by-side
.gitignore
View file @ d50531bd
...@@ -7,6 +7,8 @@ ...@@ -7,6 +7,8 @@
*.pdf *.pdf
*.tex *.tex
*.toc *.toc
*.draft.ltx
*.rej
noun_Book_861143.svg noun_Book_861143.svg
noun_Book_861143_ltgreen.svg noun_Book_861143_ltgreen.svg
noun_Email_3027864.svg noun_Email_3027864.svg
...@@ -17,4 +19,4 @@ noun_Key_1785639_ltgreen.svg ...@@ -17,4 +19,4 @@ noun_Key_1785639_ltgreen.svg
noun_Telephone_2591756.svg noun_Telephone_2591756.svg
noun_Telephone_2591756_ltgreen.svg noun_Telephone_2591756_ltgreen.svg
svg-inkscape svg-inkscape
doc/kde
README.md
View file @ d50531bd
Research on *delayed open source publication* (DOSP): the practice of This repository is a collection of research, and a resultant
[whitepaper](https://opensource.org/delayed-open-source-publication),
about *delayed open source publication* (DOSP): the practice of
publishing a software release under a proprietary license initially, publishing a software release under a proprietary license initially,
then later (usually in a planned fashion) publishing that release's then later publishing that release's source code under an open source
source code under an open source license. license. (This is often, but not always, done in a predictable
fashion: e.g., when release N goes out under a proprietary license,
While delayed open source publication been somewhat rare, there are release N-1 is then (re)published under an open source license.)
some examples of it across the history of open source -- in fact, some
of the examples (e.g., Aladdin Ghostscript) predate the coining of the There are examples of DOSP across the history of open source -- in
term "open source". To the best of our knowledge, when software fact, some of the examples (e.g., Aladdin Ghostscript) predate the
authors have done this it has usually been in a fairly predictable coining of the term "open source". We looked at various instances of
way. For example, when release N goes out under a proprietary DOSP and examined how they are alike or different. We also analyzed
license, release N-1 is then (re)published under an open source the effects (if any) of DOSP on open source as a field. Our purpose
license. was to provide accurate historical description and objective analysis;
our work here represents no position on the desirability or
This repository is a collection of research, and eventually a undesirability of delayed open source publication.
whitepaper, about various examples of DOSP and show how they are alike
or different. We will also analyze the effects (if any) of this This research was supported by the [Open Source Initiative
practice generally on open source as a field. Our purpose is to (OSI)](https://opensource.org/). The report is now completed and
provide accurate historical description and objective analysis; our published at
work here represents no position on the desirability or undesirability [opensource.org/delayed-open-source-publication](https://opensource.org/delayed-open-source-publication).
of delayed open source publication.
## Contacting us
This research is supported by the [Open Source Initiative
(OSI)](https://opensource.org/).
## Terminology
We are not necessarily settled on the term "delayed open source
publication". If you can suggest a better term for the phenomenon,
please let us know.
## Contributing
You can email us at `dosp-research {_AT_} opensource.org` or [file a You can email us at `dosp-research {_AT_} opensource.org` or [file a
ticket](https://code.librehq.com/ots/dosp-research/-/issues/new) to ticket](https://code.librehq.com/ots/dosp-research/-/issues/new) to
contact us. contact us. While we occasionally indulge in light maintenance and
error correction in the LaTeX source, that's infrequent and done
entirely at our discretion. We may prepare an updated second edition
some day; if you're interested in being involved in that, please let
us know.
To build the whitepaper from LaTeX source, you will need to use ## Building the whitepaper PDF from LaTeX source
[OTS DocTools](https://code.librehq.com/ots/ots-doctools).
Just kidding -- the whitepaper doesn't exist yet. Instead, we have To build the whitepaper from LaTeX source, use [OTS
this free-form [notes file](notes.md). For now, that's the right DocTools](https://code.librehq.com/ots/ots-doctools).
landing place for contributions.
bin/dosh 0 → 100755
View file @ d50531bd
#!/usr/bin/env bash
# Downloader for agreement between Troll Tech and KDE Free Qt Foundation.
#
# KDE presents the agreement as a series of PNG files on their site,
# which is less convenient than assembling that into a PDF. But we
# don't have permission to distribute an assembled PDF, so instead we
# have this script, which lets a user take the PNG files and make
# their own PDF.
SCRIPTNAME=dosh
BASEDIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )/..
# Call the upstream dosh
watch(){ ${OTS_DOCTOOLS_DIR}/dosh ${FUNCNAME[0]} "$@"; }
verify_pdf_links(){ ${OTS_DOCTOOLS_DIR}/dosh ${FUNCNAME[0]} "$@"; }
_dload(){
if [ -f "$2" ]; then
return
fi
wget -O $2 $1
}
docs_kde() {
mkdir -p $BASEDIR/doc/kde/.cache
cd $BASEDIR/doc/kde/.cache
# Don't download if it already exists
if [ -f ../kdefreeqt.pdf ]; then
return
fi
_dload https://kde.org/community/whatiskde/images/kdefreeqt0.png kdefreeqt0.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt1.png kdefreeqt1.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt2.png kdefreeqt2.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt3.png kdefreeqt3.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt4.png kdefreeqt4.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt5.png kdefreeqt5.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt6.png kdefreeqt6.png
_dload https://kde.org/community/whatiskde/images/kdefreeqt7.png kdefreeqt7.png
convert kdefreeqt*.png ../kdefreeqt.pdf
}
docs() {
docs_kde
}
"$@" # <- execute the task
[ "$#" -gt 0 ] || printf "Usage:\n\t./${SCRIPTNAME} %s\n" "($(compgen -A function | grep '^[^_]' | paste -sd '|' -))"
doc/Makefile 0 → 100644
View file @ d50531bd
all:
@../bin/dosh docs
clean-cache:
@echo rm -rf kde/.cache
clean: clean-cache
rm -rf kde/kdefreeqt.pdf
dosp-survey.ltx
View file @ d50531bd
--- ---
title: "Delayed Open Source Publication:\\\\A Survey of Past and Current Practices" title: "Delayed Open Source Publication:\\\\A Survey of Historical and Current Practices"
date: TBD Nov 2023 date: TBD (after 2023-11-30 publication of v1)
draft: true
--- ---
%% extends "report.ltx" %% extends "report.ltx"
\BLOCK{block preamble} \BLOCK{block preamble}
\usepackage{longtable}
\BLOCK{endblock} \BLOCK{endblock}
\BLOCK{block body} \BLOCK{block body}
\begin{center} \begin{center}
Seth Schoen, Karl Fogel, James Vasile Seth Schoen, James Vasile, Karl Fogel
\end{center} \end{center}
\vspace{0.5em}
{\footnotesize \copyright\ 2023 Open Source Initiative}
{\tiny This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.\\
(CC-BY-SA, \otsurl{https://creativecommons.org/licenses/by-sa/4.0/})
}
\vspace{-3.5em}
\renewcommand*{\contentsname}{} % Get rid of "Contents" from top of TOC \renewcommand*{\contentsname}{} % Get rid of "Contents" from top of TOC
\tableofcontents \tableofcontents
\addtocontents{toc}{\protect\thispagestyle{empty}} % no page numbers \addtocontents{toc}{\protect\thispagestyle{empty}} % no page numbers
...@@ -28,425 +38,892 @@ draft: true ...@@ -28,425 +38,892 @@ draft: true
\otsfirstterm{Delayed Open Source Publication} (DOSP) is the practice \otsfirstterm{Delayed Open Source Publication} (DOSP) is the practice
of distributing or publicly deploying software under a proprietary of distributing or publicly deploying software under a proprietary
license at first, then subsequently and in a planned fashion license at first, then subsequently and in a planned fashion
publishing that software's source code under an open source publishing that software's source code under an Open
license.\footnote{Note that this definition deliberately does not Source\footnote{We use the term ``Open Source'' throughout for
include \foreignphrase{ad hoc} or improvisatory open source releases compatibility with the Open Source Initiative's style guide, as the
of formerly proprietary code. For example, the 1998 release of the OSI supported the production of this report. We mean by that term
Netscape Navigator source code, which through further development the same thing that people also use the terms ``free software'' or
eventually became Mozilla Firefox, is \emph{not} an example of DOSP. ``free and open source software'' to refer to. While we could use
This report is examines the history and effects of DOSP practiced as ``free software'' interchangeably with ``Open Source'' --- that too
a conscious strategy; the effect of unplanned and unpredicted open would be compatible with OSI's style guide --- for the sake of
source publication is also an interesting topic, but a separate consistency we have chosen to just use ``Open Source'' throughout.}
one.} license.\footnote{Note that this definition of DOSP deliberately does
not include \foreignphrase{ad hoc} or improvisatory Open Source
Software producers have practiced DOSP throughout the history of free releases of formerly proprietary code. For example, the 1998
and open source software.\footnote{We use the terms ``free software'' release of the Netscape Navigator source code, which through further
and ``open source software'' synonymously throughout this report.} development eventually became Mozilla Firefox, is \emph{not} an
However, surveying this phenomenon at a high level, from its example of DOSP. This report examines the history and effects of
beginnings through today, shows some clear trends: DOSP practiced as a conscious strategy; the effect of unplanned or
unpredicted Open Source publication is also an interesting topic,
\emph{TBD: Everything below is tentative, draft, still a but a separate one.}
work-in-progress, etc. Feel free to read and comment, but please do
not consider anything from this point on to reflect the settled Software producers have practiced DOSP throughout the history of Open
opinions of the authors nor of any organizations.} Source software. This document is a selective survey of that history.
It collects and categorizes some examples and tries to identify
patterns and trends.
Based on the samples we know of, we categorize DOSP into three
high-level types:
\begin{itemize} \begin{itemize}
\item The rise of the Business Source License (BUSL). \item \textbf{Unconditional scheduled relicensing.}
Use of BUSL is really taking off. Planned OSS releases with just a pre-defined time delay. See
Section \ref{scheduled}.
Deserves its own section --- see Section \ref{busl}. \item \textbf{Event-driven relicensing.}
\item Delayed unconditional release. 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. Forms of this seem to have been used --- albeit loosely
in some cases --- in the early history of DOSP (see Section
\ref{early-history}) but it appears to be much less common now,
with time-based scheduled relicensing being favored instead.
Planned OSS releases with just a pre-defined time delay. \item \textbf{Conditional relicensing.}
\item Delayed event-driven regular release. ``We'll publish this as Open Source as soon as we get funding'' or
``as soon as we find the right non-profit home for it'', etc.
This can include bounty mechanisms, but only if they were planned
--- that is, it does not include ``buy-outs''.
OSS publication happens regularly, but is driven each time by some This type is probably the weakest match for our working definition
regular event (e.g., the publication of the latest proprietary of DOSP, though it is technically a match. Unsurprisingly, stated
version, which prompts the previous version to now be open intentions to release under Open Source license do not always
sourced). 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 \textbf{The rise of the Business Source License (BUSL).}
\item Delayed conditional release. Use of BUSL is growing rapidly. See Section \ref{busl}.
"We'll publish this as open source as soon as we get funding" or \item \textbf{Anti-competition terms are becoming more common.}
"as soon as we find the right non-profit home for it", etc.
Probably includes bounty mechanisms, but only if these were Traditional DOSP was typically about monopolizing direct
intended --- that is, not ``buy-outs". 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 or service that
competes with certain specific types of software that are
strategically important to the licensor, independently of direct
revenue. See Section \ref{anti-competition}.
\end{itemize} \end{itemize}
There are also post-hoc or unscheduled releases, where the authors We emphasize that this document is at best an initial survey and a
didn't originally plan to release the software as open source but first-pass analysis. It uncovers various interesting questions that
eventually decide to do so. These aren't technically in scope, but we we must leave for future research. We list some of these in Section
should give some examples somewhere --- maybe in a footnote or \ref{future}; among the most important are:
appendix --- just to make it clear that it's something that happens.
\numberedsection{Motivations}\label{motivations} \begin{itemize}
DOSP is usually described as protecting commercial interests of a software \item Why do organizations so often choose a non-Open Source license
developer by maintaining a window of time during which some users might be (such as the BUSL) and a DOSP release arrangement when simply
incentivized to pay for licenses that they might not need if the software publishing under the AGPL\footnote{The Affero General Public
were released as open source. 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 might, in many cases, meet their goals well enough?
% Seth asks: How sure are we about that? I agree that it's a
% common view and that they may not have thought it through, but I
% don't know whether many projects have thought it through or
% what the results would be. (That's why I phrased the research
% question as asking about whether projects have *considered*
% AGPL, or why they haven't.)
%
% Karl answers: Mostly I'm asserting this from anecdata --- from
% prior conversations, not from research done specifically for
% this report. I've softened the assertion a bit (changing
% "would" to "might", basically), but I'd like to leave it in.
% I think it's a useful provocation to readers. I'd really like
% to see the follow-up research on this question happen, and I
% think the (softened) assertion is true enough to stand but
% tentative enough to point to the need for a deeper inquiry.
\item When do BUSL-licensed projects have different contribution
dynamics than truly Open Source projects, and when (if ever) do
they have similar dynamics?
\item When a previously Open Source project is converted to DOSP by
its licensor, under what circumstances does this tend to cause a
viable fork to occur?
% Fit into discussions about incentive/funding models \end{itemize}
We've also seen one-time delays for new projects whose developers state Just as Open Source gradually shook out into a handful of licenses
a concrete intention to convert those projects to an open source license. that are used by the vast majority of projects, we might now be seeing
They may have non-economic reasons for those delays, such as shame about a convergence toward a recognizable and relatively small set of DOSP
poor code quality, concern about security issues that may be apparent in licenses. It is too soon to know for sure if the current options will
unaudited source code, a need to procure permissions from other copyright settle in as the standard. The list of most-used Open Source licenses
holders, a desire to establish a community or governance structure, or has been quite stable for over a decade now, and there is little
a plan to incorporate a legal entity. 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.
% NOTE: Karl commented out the stuff below, in the interests of
% keeping the Executive Summary compact. There are some good ideas
% below, though; it would be nice to find a home for them.
%
% 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}\label{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{See, for example, \otsurl{https://web.archive.org/web/20070816214332/http://pages.cs.wisc.edu/$\sim$ghost/doc/AFPL/6.01/New-user.htm\#Overview}.}
GhostScript's author, L. Peter Deutsch, described this practice as
providing commercial exclusivity that would help fund continued
development of the project.\footnote{
Specifically, he wrote in the AFPL that this mechanism
\begin{quote}
attempts to ensure that those who
receive, redistribute, and contribute to the licensed Program according to
the Open Source and Free Software philosophies have the right to do so,
while retaining for the developer(s) of the Program the power to make those
who use the Program to enhance the value of commercial products pay for the
privilege of doing so.
\end{quote}
Larry Rosen also told us, based on his communications with Deutsch, that
\begin{quote}
Deutsch's expressed preference for [initial publication under]
the AFPL over the GPL arose from what he saw as a serious ``free rider''
issue for commercial distribution, initially
motivated by fax software vendors distributing Ghostscript executables with
their products and invoking them as black boxes through the equivalent of
`exec', which the GPL allows without bringing the entire product under the
GPL.
\end{quote}
}
This is a commonly cited motivation for adopting DOSP.
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{Although these events took place after Deutsch had
sold Artifex, Deutsch told Rosen that
\begin{quote}
Artifex eventually
abandoned the AFPL / GPL division, I believe because they found that it was
a bit of complexity that didn't affect their revenue from commercial
licensing. Instead, they simply offered the choice of either GPL or a
straight commercial license. In addition, I believe they offered
performance-enhancing replacements for certain modules that were only
available to commercial licensees. (The ones I remember hearing about were
things like halftoning or shading code that used processor-specific SIMD
capabilities.) At the same time, they put quite a bit of energy into
identifying and taking legal action against commercial users who were
violating the GPL, of which there were an astoundingly large number. For
the last several years this actually resulted in substantial revenue, from
retroactive commercial license payments and from new commercial license
agreements: some offenders started complying with the GPL, some obtained
commercial licenses, and some stopped using the code altogether.
\end{quote}
}
% 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'' or ``source available'': 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
more conventional proprietary relicensing, 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 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, although both are still under active development.
A more recent example is the Onivim 2 project, which had a proprietary license
and also maintained an 18-month-delayed MIT-licensed version.\footnote{See
\otsurl{https://github.com/onivim/oni2/issues/3771}, and see also
\otsurl{https://web.archive.org/web/20210929101337/https://github.com/onivim/oni2-mit}.} All development on the project ceased in 2021, and it was
relicensed under the MIT license at that time.
\numberedsection{Scheduled Relicensing}\label{scheduled} \numberedsection{Scheduled Relicensing}\label{scheduled}
\subsection{Early History} \subsection{Proprietary Ramp-up, Eventually Open Source (Pre-Open Source)}\label{motivations}
For many years, Aladdin GhostScript implemented a DOSP policy whereby DOSP is usually adopted as an ongoing commercial strategy. It
new versions were published under a proprietary license, and then regularly reserves a window of time for a company to sell the latest features
relicensed under the GNU GPL with a delay of one year. (It might be under proprietary license before they become available to all under
clearer to say that year-old versions were regularly republished under open license.
the GPL.)
In addition to this common form of DOSP, we find delayed publication
GhostScript author L. Peter Deutsch described this practice as providing occurs in another notable form. In this form, projects plan to
commercial exclusivity that would help fund continued development of the eventually be fully open but initially operate in a less open manner.
project. The plan for such projects is to become full-fledged Open Source
efforts once the project has matured or stabilized. This
Eventually, GhostScript adopted a simultaneous dual-licensing approach \textbf{one-time} delay at the start of a new project is, to us,
in which all releases were available under GPL and redistributors could different enough from other DOSP that maybe it should be placed in a
choose to pay for a proprietary license exempting them from GPL whole other category. Still, it is a common form of time-delay in the
obligations. Open Source world.
% TODO This is about Artifex rather than Aladdin - the change happened % Fit into discussions about incentive/funding models
% after the product was transferred to a new company!
Attorney and author Lawrence Rosen, who discussed GhostScript's model in These projects begin development in a proprietary mode. During this
his book on open source licensing, told us that Artifex eventually pre-open-source period, their practices might reflect just about any
concluded that the GPL was unpalatable enough to commercial embedded variation of non-Open Source software. They might not publish any
developers --- the entities that were typically already paying for code. Or release their code under non-Open Source license, including
proprietary licenses or that could be induced to pay for violations of by not explicitly specifying a license. They might only release
GhostScript's copyright --- that the delay in making GhostScript available binaries or release nothing. In short, these projects range from
under the GPL did not significantly change these companies' incentives to pay wholly, traditionally proprietary in nature to public collaborations
for licenses. that stop just short of an Open Source license.
% Sorry for the super-long sentence. I'm sure we'll break that up somehow.
Usually, these projects explain that they plan to become open, explain
% Rosen also says that sendmail may have had a dual license in the same why it hasn't happened yet, and describe (sometimes vaguely) the
% era or even before Ghostscript. I found references to sendmail having conditions that will trigger a relicensing toward Open Source.
% a "traditional" dual license but so far have not found references to a
% scheduled relicensing practice. There are many possible reasons why a project might start out with
some public visibility, whether of source or binaries, but not
% TrollTech story is complicated... initially ship Open Source code. The ones we have
% https://tinf2.vub.ac.be/~dvermeir/manual/KDE20Development-html/ch19lev1sec4.html observed:
% and more
% Would be nice to 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} \subsection{Bounty and Sponsorship Delays}\label{bounty}
Another model is making individual software features or enhancements Another model is making individual software features or enhancements
available to sponsors first, with a fixed time delay before making available to sponsors first, with a fixed time delay before making
them available to the general public. An example of this is the North 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/}.}, Road SLYR GIS software\footnote{See
which has a published feature roadmap and releases (and licenses) its \otsurl{https://north-road.com/slyr/}.}, which has a published
implementation of each feature to sponsors first: feature roadmap and releases (and licenses) its implementation of each
feature to sponsors first:
\begin{quote} \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. 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} \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. 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.\footnote{\otsurl{https://web.archive.org/web/20220216132657/https://www.uib.de/en/opsi-cofunding/cofunding/}}
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} \subsection{The Business Source License (BUSL)}\label{busl}
The Business Source License (BUSL; sometimes ``BSL"\footnote{Most adopters The Business Source License (BUSL; sometimes ``BSL''\footnote{Most
of this license refer to it as ``BSL", but adopters of this license refer to it as ``BSL'', but this acronym
this acronym was previously used for the Boost Software License. The was previously used for the Boost Software License. The SPDX
SPDX license identifier for the Business Source License is ``BUSL".}) license identifier for the Business Source License is ``BUSL'' (see
was originally written in 2016 by MariaDB for its MaxScale project. \otsurl{https://spdx.org/licenses/} for the full SPDX list).}) was
The current version of BUSL, 1.1, was released in 2017 and first originally written in 2016 by MariaDB for its MaxScale project. The
used for MaxScale 2.1.0.\footnote{See current version of BUSL, 1.1, was released in 2017 and first used for
\otsurl{https://mariadb.com/resources/blog/releasing-bsl-1-1/}.} 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". There is at least one earlier proposal of the concept: the ``Open
Source Eventually License'', described in 2016 (see
MariaDB's Change Date for MaxScale is four years after the release of a \otsurl{https://github.com/ftrotter/OSE/tree/a360875170b4a9818e3a4691beced81d7d5f13a8}).
specific version, and its Change License is GPLv2. It is fundamentally the same idea as BUSL, but precedes the BUSL by
at least a few months. A more tenuous antecedant comes from Richard
Stallman, in
\otsurl{https://www.gnu.org/philosophy/netscape-npl.html}, in the
section ``Not all users are equal'', which proposes that the harms
of asymmetrical licensing could be reduced by putting a time limit
on the asymmetry.}
BUSL requires a licensor to specify a ``Change Date'' and a ``Change
License''. On the Change Date, which is some time in the future, the
license of the covered artifact will change to the Change License,
which is an Open Source license.\footnote{Specifically, the Change
License must be either GPL 2.0 or else a license that is compatible
with GPL 2.0 or a later version.}
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 % 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}) The Linux Foundation noted\footnote{\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 that several prominent projects switched away from open-source
from 2018 to 2023. Not all of these adopted DOSP licenses, but those that did licenses from 2018 to 2023. Not all of these adopted DOSP licenses\footnote{The
so adopted BUSL. trend identified by the Linux Foundation began in late 2018, with two
These included CockroachDB, Couchbase, Terraform, and ArangoDB. The most major database projects, Redis and MongoDB, changing their licenses.
prominent of these BUSL adopters was HashiCorp, which wrote Both eventually ended up adopting the Server-Side
Public License (SSPL). SSPL was proposed as an Open Source license,
but was not ultimately accepted as Open Source by OSI's license review
process. Some proponents of this license continue to argue that it
meets criteria to be considered a form of free and open source
licensing.}, 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} \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. 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} \end{quote}
This change applied to almost all of the company's software, including popular This change applied to almost all of the company's software, including
software like Terraform, Vagrant, and HashiCorp Vault. popular software like HashiCorp Terraform, Vagrant, and Vault.
\subsubsection{Anti-competition as a Motivation}\label{anti-competition}
Although HashiCorp's license change attracted the most attention and Although HashiCorp's license change attracted the most attention and
commentary, it's interesting to note that BUSL was originally written by commentary, the BUSL was originally written by a database company.
a database company and that the majority of the projects we've identified Some of the project developers wrote that they wanted to discourage
that relicensed under BUSL are database systems. Some of the project other companies from competing directly with the developers' hosted
developers wrote that they wanted to discourage other companies from database services, and that they doubted whether an Open Source
competing directly with the developers' hosted database services, and that license would manage to accomplish this.\footnote{It's interesting to
they doubted whether an open source license would manage to accomplish note that the majority of the projects we've identified that
this. It's also possible that there was a degree of ``social contagion" relicensed under BUSL are database systems. It's possible that
as database developers observed several of their peers relicensing away there was a degree of ``social contagion'' as database developers
from open source at roughly the same time, either to BUSL or to other observed several of their peers relicensing away from Open Source at
licenses that restrict licensees from operating commercial services. roughly the same time, either to BUSL or to other licenses that
restrict licensees from operating commercial services. As noted
Several licensors add an Additional Use Grant (AUG) under the BUSL to above, database developers were also responsible for several other
allow for ``production" uses other than those that are considered to relicensing decisions starting in 2018.}
compete with the developer's commercial services. For example,
ArcticDB provides the following Additional Use Grant\footnote{This same By default, BUSL prohibits uses in ``production'' before the Change
text is also used by several other projects, and we have not determined Date. Licensors using the bare BUSL would thus expect commercial
which project originated it. There are also other variants with similar adopters to pay for a separate license permitting commercial use.
effect.}: However, several licensors add an Additional Use Grant (AUG) under the
BUSL to allow for ``production'' uses \emph{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} \begin{quote}
You may make use of the Licensed Work under the terms of this License, You may make use of the Licensed Work under the terms of this
provided that you may not use the Licensed Work for a Database Service. 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 A ``Database Service'' is a commercial offering that allows third
of the Licensed Work by creating tables whose schemas are controlled by parties (other than your employees and contractors) to access the
such third parties. functionality of the Licensed Work by creating tables whose schemas
are controlled by such third parties.
\end{quote} \end{quote}
It appears that the project thus intends to immediately allow It appears that the project thus intends to immediately allow
\emph{commercial} uses, including for public services, as long as these \emph{commercial} uses, including for public services, as long as
don't entail charging money for hosting databases in particular. Several these don't entail charging money for hosting databases in particular.
other BUSL adopters have analogous grants. 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.
The AUG mechanism---including optional free-form text that exempts certain Below is a table of sixteen well-known projects that now use BUSL,
uses from BUSL's ``production use" restrictions---complicates direct showing their Change Date and Change Licenses.
comparison of uses of the BUSL; we have not yet devised a taxonomy
for making these comparisons.
% TODO Sort this table by date of BUSL adoption? ("BUSL date") % This \newpage is necessary right now, otherwise the build hangs
\begin{table}[] % because of the big longtable below. There might be a better fix.
\begin{tabular}{lllll} \newpage
\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} \\ \begin{longtable}[l]{l l l l}
\textbf{Project} & \textbf{BUSL date} & \textbf{Change Date} & \textbf{Change License} \\
& & & \\
ArangoDB & 2023-10-11 & rel. +4 years & Apache v2 & \otsurl{https://arangodb.com/2023/10/evolving-arangodbs-licensing-model-for-a-sustainable-future/} \\ MaxScale & 2017-02-14 & release date + 4 years & GPL v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://mariadb.com/resources/blog/releasing-bsl-1-1})}} \vspace{0.2em} \\
ArcticDB & [always] & rel. +2 years & Apache v2 & [no ref] \\ CockroachDB & 2019-06-04 & release date + 3 years & Apache v2 \\
% https://github.com/man-group/ArcticDB/blob/master/LICENSE.txt & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://www.cockroachlabs.com/docs/stable/licensing-faqs\#bsl})}} \vspace{0.2em} \\
CockroachDB & 2019-06-04 & rel. +3 years & Apache v2 & \otsurl{https://www.cockroachlabs.com/docs/stable/licensing-faqs\#bsl} \\ ZeroTier & 2019-08-28 & 5th calendar year & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://www.zerotier.com/blog/on-the-gpl-to-bsl-transition})}} \vspace{0.2em} \\
CodeCov & 2023-08-02 & rel. +3 years & Apache v2 & \otsurl{https://about.codecov.io/blog/codecov-is-now-open-source/} \\ Sentry\footnote{Sentry subsequently relicensed under its own ``Functional Source License''; see below for further discussion.} & 2019-11-06 & release date + 3 years & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://blog.sentry.io/relicensing-sentry})}} \vspace{0.2em} \\
CouchBase & 2021-03-26 & rel. +4 years & Apache v2 & \otsurl{https://www.couchbase.com/blog/couchbase-adopts-bsl-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 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://materialize.com/docs/license})}} \vspace{0.2em} \\
% Is that actually ``always'' for Materialize?
DragonflyDB & 2022-05-29 & +5 years & Apache v2 & REF \\ CouchBase & 2021-03-26 & release date + 4 years & Apache v2 \\
% https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.md & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://www.couchbase.com/blog/couchbase-adopts-bsl-license})}} \vspace{0.2em} \\
evitaDB & [always] & 4th cal. year & Apache v2 & [no ref] \\ Memgraph & 2021-10-03~? & release date + 4 years & Apache v2 \\
% https://github.com/FgForrest/evitaDB/blob/dev/LICENSE & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://memgraph.com/blog/memgraph-2-0-release})}} \vspace{0.2em} \\
% Is that actually ``always'' for Memgraph? (was it binary-only before that?)
% https://github.com/memgraph/memgraph/blob/master/licenses/BSL.txt
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 \\ SurrealDB & 2021-12-14~? & release date + 4 years & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://github.com/surrealdb/surrealdb/blob/main/LICENSE})}} \vspace{0.2em} \\
% Is that actually ``always'' for SurrealDB?
MaxScale & 2017-02-14 & rel. +4 years & GPL v2 & \otsurl{https://mariadb.com/resources/blog/releasing-bsl-1-1/} \\ DragonflyDB & 2022-05-29 & release date + 5 years & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.md})}} \vspace{0.2em} \\
Memgraph & 2021-10-03 & rel. +4 years & Apache v2 & REF \\ ReadySet & 2022-08-03 & release date + 4 years & Apache v2 \\
% https://github.com/memgraph/memgraph/blob/master/licenses/BSL.txt & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://github.com/readysettech/readyset/blob/main/LICENSE})}} \vspace{0.2em} \\
ReadySet & 2022-08-03 & rel. +4 years & Apache v2 & REF \\ Akka & 2022-09-07 & release date + 3 years & Apache v2 \\
% https://github.com/readysettech/readyset/blob/main/LICENSE & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka})}} \vspace{0.2em} \\
Sentry & 2019-11-06 & rel. +3 years & Apache v2 & REF \\ Codecov & 2023-08-02 & release date + 3 years & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://about.codecov.io/blog/codecov-is-now-open-source})}} \vspace{0.2em} \\
SurrealDB & 2021-12-14 & rel. +4 years & Apache v2 & REF \\ 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 & release date + 4 years & MPL 2.0 \\
% https://github.com/surrealdb/surrealdb/blob/main/LICENSE & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license})}} \vspace{0.2em} \\
Terraform (etc.) & 2023-08-10 & rel. +4 years & MPL 2.0 & REF \\ ArangoDB & 2023-10-11 & release date + 4 years & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://arangodb.com/2023/10/evolving-arangodbs-licensing-model-for-a-sustainable-future})}} \vspace{0.2em} \\
ZeroTier & 2019-08-28 & 5th cal. year & Apache v2 & REF \\ ArcticDB & always & release date + 2 years & Apache v2 \\
\end{tabular} & \multicolumn{3}{l}{{\footnotesize (\otsurl{https://github.com/man-group/ArcticDB/blob/master/LICENSE.txt})}} \vspace{0.2em} \\
\end{table}
% TODO: Do footnotes from a table not render properly?
\subsection{Differences From Other Licensing Strategies}\label{differences} evitaDB & always & 4th calendar year & Apache v2 \\
& \multicolumn{3}{l}{{\footnotesize (\otsurl{https://github.com/FgForrest/evitaDB/blob/dev/LICENSE})}} \vspace{0.2em} \\
MariaDB (https://mariadb.com/bsl-faq-mariadb/): \end{longtable}
\begin{quote} BUSL is notionally designed to apply to specific software \emph{releases},
Q: How is the BSL different from Open Core? so that a Change Date applies to a particular version of a code base.
That means that, for a project with an ongoing DOSP practice, BUSL is meant
to be re-applied periodically with updated details. The majority of projects
we've seen have not yet demonstrated how they'll handle this process on
an ongoing basis. Most don't have a clearly-visible and systematic way to
apply BUSL updates to ongoing development, although one project (Materialize)
automatically updates its BUSL grant every day in order to keep the Change
Date at a fixed point in the future. For some projects, it is unclear at
first glance exactly which version or versions of the code base the BUSL
grant is meant to apply to. The Change Date concept may be complicated by
the fact that not all contemporary software projects have a reliable
schedule of discrete ``release'' events.
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. \subsubsection{Differences From Other Licensing Strategies}\label{differences}
Q: How is the BSL different from dual GPL/commercial licensing? MariaDB describes some of the differences between BUSL and other
commonly-used licensing strategies as follows:\footnote{The quotation
is from \otsurl{https://mariadb.com/bsl-faq-mariadb/}.}
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. \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} \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. This is echoed in statements by several BUSL adopters that they sought
a way to make downstream commercial users who did not redistribute
\subsection{Consequences/Impacts?} derived works pay for the use of their software (typically in cloud
environments), or wanted to prevent downstream commercial users from
Projects that change from an open-source license to a delayed open-source directly competing with the initial developer's own service offerings.
license have attracted criticism, with some people pledging to
switch to other projects or even to maintain competitive forks of the We do not know why MySQL's FAQ item mentions only GPL and not AGPL,
prior open-source versions. The most consequential such effort nor whether those other BUSL adopters considered AGPL.
appears to be OpenTofu, a fork of HashiCorp's Terraform announced soon
after Terraform was relicensed under BUSL.\footnote{See \subsection{Consequences}\label{consequences}
\otsurl{https://opentofu.org/}.}
OpenTofu has announced several corporate sponsorships, apparently plans Projects that change from an open-source license to a delayed
to hire multiple full-time developers, and has organized itself as a open-source license have attracted criticism, with some people
project of the Linux Foundation. The fork's creators complained that pledging to switch to other projects or even to maintain competitive
the prior open source license of Terraform had encouraged people to forks of the prior open-source versions.
develop professional expertise with the software and to use it as a part
of their infrastructure. The most consequential such effort appears to be OpenTofu, a fork of
% One could say much more about this both in terms of commercial strategy HashiCorp's Terraform announced soon after Terraform was relicensed
% and also in terms of users' subjective feelings of betrayal. under BUSL.\footnote{See \otsurl{https://opentofu.org/}.} OpenTofu
They also noted concerns about whether Terraform users could be confident has announced several corporate sponsorships, apparently plans to hire
about whether their individual uses were considered commercially multiple full-time developers, and has organized itself as a project
competitive with HashiCorp. of the Linux Foundation. The fork's creators complained that the
prior Open Source license of Terraform had encouraged people to
Most other forks of recently-relicensed software have not attracted the develop professional expertise with the software and to use it as a
same levels of attention, participation, or adoption. part of their infrastructure --- in essence, that HashiCorp performed
a bait-and-switch by moving from Open Source licensing to BUSL.
% yes for Vagrant -> Viagrunt, although OpenTofu got vastly more support % One could say much more about this both in terms of commercial
% and activity % strategy and also in terms of users' subjective feelings of
% betrayal.
It could be harder for projects under non-open-source terms to receive They also noted concerns about whether Terraform users could be
or accept outside contributions, both because people may be less motivated confident about whether their particular uses would be considered
to make them and because the licensing status of the resulting contributions commercially competitive with HashiCorp.
is more complicated. However, some projects that have switched to BUSL (or
other licenses) continue to accept outside contributions subject to a As far as we can tell, most other forks of recently-reproprietized
contributor license agreement (``CLA"), which grants certain rights to the software have not attracted the same levels of attention,
original developer. HashiCorp, for example, has a CLA for its participation, or adoption. However, we have not done an extensive
projects\footnote{See, for example, survey on this question and welcome further research.
\otsurl{https://cla.hashicorp.com/hashicorp/terraform}.}, and a bot that
that checks whether the authors of pull requests have signed it, so that % there's also a fork Vagrant -> Viagrunt, although OpenTofu got
their contributions will not be incorporated into the codebase until % vastly more support and activity
and unless they do so. The company does continue to receive some outside
code contributions to its BUSL-licensed projects, including Terraform. It could be harder for projects under non-Open Source terms to receive
% TODO: Has the rate measurably decreased? or accept outside contributions, both because people may be less
% motivated to make them and because the licensing status of the
% TODO: Did they have this requirement before relicensing? Some open source resulting contributions is more complicated. However, some projects
% projects do have comparable CLAs for outside contributions to that have switched to BUSL (or other licenses) continue to accept
% become part of their official upstream code bases. It's not only a outside contributions subject to a contributor license agreement
% BUSL/DOSP/proprietary licensing phenomenon. (``CLA''), which grants certain rights to the original developer.
HashiCorp, for example, has a CLA for its projects\footnote{See, for
\subsection{Other} example, \otsurl{https://cla.hashicorp.com/hashicorp/terraform}.
Note that HashiCorp did previously have a CLA in place for outside
The Child Mind Institute uses its Delayed Open Source Attribution License contributions, since at least 2019.},
(DOSA), which has a three-year period in which only noncommercial uses and a bot that checks whether the authors of pull requests have signed
are permitted, for its MindLogger software. it, so that their contributions will not be incorporated into the
% https://github.com/ChildMindInstitute codebase until and unless they do so. The company does continue to
receive some outside code contributions to its BUSL-licensed projects,
The Poké Classic Framework including Terraform. HashiCorp's CLA is ``non-exclusive''; an outside
has a conditional license which limits uses of the code but which contributor could conceivably continue to contribute the same patches
converts to AGPL if the original developer ceases to operate a service to a HashiCorp BUSL project and a non-HashiCorp fork of the same
based on the code.\footnote{See project, assuming that the codebases haven't diverged too far over
\otsurl{https://github.com/mm201/pkmn-classic-framework}.} time to make this practical.
Sentry has released a draft of its ``Functional Source License" (FSL), % Has the rate measurably decreased?
which it hopes to use for its own currently BUSL-licensed software, at % E.g. compare hashicorp vs. non-hashicorp addresses for contributions
\otsurl{https://fsl.software/}.\footnote{Disclosure: % but note limitations of this method
% TODO: What is the right phrasing for the disclosure here? % Also did bugtracker activity change?
}
The FSL prohibits, during a period of one year, uses of covered software \subsection{Other Examples}\label{other-examples}
to provide services that ``compete" with the original developer's commercial
service offerings. Following this period, the software is licensed under The Child Mind Institute created its own Delayed Open Source
BSD or Apache terms, without the competition restriction. Attribution License (DOSA), which has a three-year period during which
only noncommercial uses are permitted, for its MindLogger
Several cloud-oriented software projects that switched away from open software.\footnote{The developers even announced this in a journal
source licensing in the past few years also adopted license terms with article announcing the development of the software. See Arno Klein
non-competition clauses. However, these generally were not time-limited. \foreignphrase{et al.}, ``Remote Digital Psychiatry for Mobile
% TODO: double-check whether any of them were time-limited Mental Health Assessment and Therapy: MindLogger Platform
Development Study'' (2021), available at
% I think it's interesting that the AGPL doesn't seem to appeal to most \otsurl{https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8663601/}; for
% companies that are pursuing this kind of thing. I don't know if any of the license text, see
% them have commented on their views about it. \otsurl{https://github.com/ChildMindInstitute/DOSA-license}.}
However, as of 2023, MindLogger and other projects from the Child Mind
\numberedsection{Enforceability}\label{enforce} Institute are licensed under the CPAL Open Source license, with no
associated delay.
Delayed open source licensing is less explored than immediate open source
licensing, and some observers have expressed concerns about its legal The Poké Classic Framework has a conditional license which limits uses
enforceability. For example, if an author died before the announced license of the code but which converts to AGPL if the original developer
transition date, would the author's heirs be required to honor the license ceases to operate a service based on the code.\footnote{See
transition, or could they potentially cancel or withdraw it? What if a \otsurl{https://github.com/mm201/pkmn-classic-framework}.}
company were acquired by a new owner which wanted to retroactively change
its licensing structure? Roughly contemporaneously with MariaDB's development of BUSL, Ben
Boyter proposed a ``GPL time bomb'' (later renamed to simply
% XXX We obviously don't know yet because ... ``eventually open'') that is conceptually similar to BUSL with an AUG
specifying a limited number of users within an
The Creative Commons research on springing licenses expressed some concerns organization.\footnote{See
about their enforceability. The Creative Commons organization itself \otsurl{https://boyter.org/2016/08/gpl-time-bomb-interesting-approach-foss-licensing/}.}
previously implemented a delayed licensing mechanism called Founders This approach was used for Boyter's ``searchcode-server''
Copyright; unlike other Creative Commons licenses, the Founders Copyright project\footnote{See \otsurl{https://www.searchcode.com/}.}, but no
involves a copyright assignment to the Creative Commons nonprofit new development has taken place on this codebase since 2020, so the
organization itself. The organization then commits to grant the original whole project is apparently now licensed under GPL v3.
author an exclusive license to the for the announced delay period, and
to license the work to the public afterward. It appears that this copyright In November 2023, Sentry published its own ``Functional Source
assignment mechanism was intended to minimize uncertainty about the License'' (FSL),\footnote{\otsurl{https://fsl.software/}} and
extent to which authors could bind themselves (or their successors) to relicensed its
future licensing intentions, although it required direct involvement by own previously BUSL-licensed software under it.\footnote{See Sentry's
the nonprofit as copyright holder and licensor, a role it had otherwise announcement and discussion at
not seen fit to take on. \otsurl{https://blog.sentry.io/introduction-the-functional-source-license-freedom-without-free-riding/}.
\\
Kyle E. Mitchell distinguishes ``a present grant of a license" (with a Disclosure: Sentry.io donated to the Open Source Initiative to
specified future start date) from ``a contractual promise to grant the support the writing of this report. The authors have not been
license later" and advocates using the former, although he does not influenced by Sentry.io nor by the Open Source Initiative in our
imply that the latter is invalid or unenforceable. Mitchell's concerns choice of examples, our choice of questions, our analysis, or our
focus on clarity and persistent documentation of specific license conclusions.} The FSL prohibits, during a period of two years, uses
grants to specific code and project versions. of covered software to provide services that ``compete'' with the
original developer's commercial service offerings. Other uses are
\numberedsection{``Grace Period" Reciprocal Licensing}\label{grace} generally permitted. Following this two-year period, the software is
licensed under MIT or Apache terms, without the competition
One licensing practice often described as related to DOSP is implemented restriction.\footnote{FSL exists in exactly two variants, one which
in the Bootstrap Open Source License (BOSL), previously called the converts to the MIT license after two years, and one which converts
Transitive Grace Period Public License (TGPPL). This license was mainly to the Apache 2.0 license after two years.}
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}.} 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 permissions).
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.\footnote{A similar problem
of license proliferation was identified years ago among Open Source
licenses; see \otsurl{https://opensource.org/proliferation/} and
\otsurl{https://en.wikipedia.org/wiki/License\_proliferation} for
more context.}
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}
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 % 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. % TGPPL was submitted for OSI review in 2009 (!) but was never
% There are some discussions that seem to imply that people were reluctant % approved. There are some discussions that seem to imply that people
% to approve it from nascent concerns over license proliferation and some % were reluctant to approve it from nascent concerns over license
% prudential concerns about whether this was the right approach to % proliferation and some prudential concerns about whether this was
% relicensing. % the right approach to relicensing.
It is worth pointing out that the BOSL has no connection to the Bootstrap It is worth pointing out that the BOSL has no connection to the
web framework project, which is under the MIT license. Both projects Bootstrap web framework project, which is under the MIT license. Both
independently use the term ``bootstrap" to refer to the concept of projects independently use the term ``bootstrap'' to refer to the
bootstrapping. concept of bootstrapping.\footnote{Furthermore, neither has any
connection to the ``Boost'' project nor to the Boost Software
License, though when reading quickly it is easy to make a
transposition mistake. Not that this ever happened to any of this
report's authors.}
Instead of making an initially proprietary license grant that later Instead of making an initially proprietary license grant that later
transforms into an open-source license, the BOSL makes an initially transforms into an open-source license, the BOSL makes an initially
permissive (BSD-style) license grant that later transforms into a non-reciprocal (BSD-style) license grant that later transforms into a
reciprocal (GPL-style) license. This is intended to allow downstream reciprocal (GPL-style) license. This is intended to allow downstream
code reuse in proprietary software projects, but only for a limited code reuse in proprietary software projects, but only for a limited
time, something Zooko characterized as a compromise between time, something Wilcox-O'Hearn characterized as a compromise between
permissive and reciprocal open source licensing models.\footnote{See, non-copyleft and copyleft Open Source licensing models.\footnote{See,
for example, the presentation at for example, the presentation at
\otsurl{https://tahoe-lafs.org/\textasciitilde{}zooko/tgppl.pdf}.} \otsurl{https://tahoe-lafs.org/$\sim$zooko/tgppl.pdf}.}
% TODO: Get rid of the {} that shows up in the link target % We'd really like to know how to get 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 would browse to
% if you were toclick on the URL) 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 we're currently using, 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.
Since both the start and end-state licenses of the BOSL are themselves 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 Open Source, we do not regard the BOSL as a form of delayed
publication as defined by this report. Rather, it seems to be an open-source publication as defined by this report. Rather, it seems
unconventional form of open source publication with time-varying open to be an unconventional form of Open Source publication with
source terms. While the BOSL has not been approved by the Open Source time-varying Open Source terms. While the BOSL has not been approved
Initiative, it appears to us to be compatible with the Open Source by the Open Source Initiative, it appears to us to be compatible with
Definition, and --- unlike BUSL, for instance --- is claimed by its the Open Source Definition, and --- unlike BUSL, for instance --- is
authors to be a form of open source licensing. claimed by its authors to be a form of Open Source licensing.
One way to view the distinction between delayed open-source licensing and One way to view the distinction between delayed open-source licensing
grace period reciprocal licensing is that the former aims to compromise and grace period reciprocal licensing is that the former aims to
between proprietary and open source licensing, where the latter aims compromise between proprietary and Open Source licensing, where the
to compromise between permissive and reciprocal licensing --- in both latter aims to compromise between non-reciprocal and reciprocal
cases by modifying the license terms after a delay. licensing --- in both cases by modifying the license terms after a
delay.
\numberedsection{Other Terminology and Practices}\label{terminology} \numberedsection{Other Terminology and Practices}\label{terminology}
...@@ -457,83 +934,278 @@ the licensing mechanisms used to implement it. ...@@ -457,83 +934,278 @@ the licensing mechanisms used to implement it.
\item Eventual (open) source; scheduled licensing. \item Eventual (open) source; scheduled licensing.
Lawrence Rosen's book on open source licensing refers to ``eventual source" Lawrence Rosen's book \otscite{Open Source Licensing: Software
or ``eventually open source" software, giving the example of Aladdin Freedom and Intellectual Property Law} refers to ``eventual
GhostScript. He also calls this ``scheduled licensing". source'' or ``eventually open source'' software, giving the
example of Aladdin GhostScript. He also calls this ``scheduled
licensing''.
\item Springing licenses. \item Springing licenses.
A research report from Creative Commons refers to ``springing licenses" A research report from Creative Commons refers to ``springing
(licenses that grant additional permissions after a period of time, or licenses'' (licenses that grant additional permissions after a
when some other condition has been met). Creative Commons was mainly period of time, or when some other condition has been met).
interested in the possibility of developing licenses that would grant Creative Commons was mainly interested in the possibility of
additional permissions over time, after a period of greater exclusivity. developing licenses that would grant additional permissions over
time, after a period of greater
exclusivity.\footnote{\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}}
\item Scheduled relicensing. \item Scheduled relicensing.
Kyle E. Mitchell refers to ``scheduled relicensing". Kyle E. Mitchell refers to ``scheduled relicensing'' in
\otscite{A Short, Simple Template for Scheduled
Relicensing}.\footnote{\otsurl{https://writing.kemitchell.com/2023/10/24/Scheduled-Relicensing}}
\end{itemize} \end{itemize}
One can also distinguish between a public pledge to relicense on a schedule One can also distinguish between a public pledge to relicense on a
(as GhostScript did) and a license document whose text includes date or schedule (as GhostScript did) and a license document whose text
other restrictions. In the former case, the delayed release is implemented includes date or other restrictions. In the former case, the delayed
by human beings (actively making a new software release including new release is implemented by human beings (actively making a new software
license text); in the latter case, it is automatic. 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 We do not consider ``unplanned'' Open Source releases to be examples
retroactively relicensed as open source as a result of a one-off decision. of DOSP. There are a number of high-profile cases of proprietary
Where developers originally had no announced plan or intention to do this, projects that were retroactively relicensed as Open Source as a result
we think this is best considered a separate phenomenon, not a ``delayed" of a one-off decision. Where developers originally had no announced
release. 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) Many people also mentioned the custom among some video game developers
from proprietary video games that are no longer commercially important. of releasing code (though usually not assets such as graphics and
This is a relatively widespread practice, with Wikipedia identifying sound) from proprietary video games that are no longer commercially
dozens of instances.\footnote{Wikipedia lists these examples at important. This is a relatively widespread practice, with Wikipedia
\otsurl{https://en.wikipedia.org/wiki/List\_of\_commercial\_video\_games\_with\_later\_released\_source\_code}.} listing dozens of instances.\footnote{\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
Some companies like id Software have made such releases for multiple video Open Source license.
game generations.
While many of these developers apparently had a general intention to make Some companies like id Software have made such releases for multiple
their games open source, in whole or in part, at some point in the future, video game generations. While many of these developers apparently had
there was usually no public commitment to do so on any particular a general intention to make their games Open Source, in whole or in
schedule or under any particular circumstances. This practice is thus not part, at some point in the future, there was usually no public
a core example of DOSP. 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 A ``delayed open access'' model, applied to research articles, has
journal licensing and open-access publishing.\footnote{See become popular for academic journals as a compromise between more
\otsurl{https://en.wikipedia.org/wiki/Delayed\_open-access\_journal}.} 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 As of November 2023, Wikipedia identifies by name 108 journals that
currently follow some form of this model, but cites a 2013 study 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, reportedly reviewed 492 journals with such a policy. In this context,
journals may apply an ``embargo period" to create an incentive for some journals may apply an ``embargo period'' to create an incentive for
journal users to pay for subscriptions or article access in order to some journal users to pay for subscriptions or article access in order
read recent research. The license terms applied at the expiration of these to read recent research. The license terms applied at the expiration
embargo periods permit the public to read articles at no charge, but of these embargo periods permit the public to read articles at no
may or may not be equivalent to open source licensing. 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 attempting to keep as many of
the advantages of Open Source as they can. To what extent and in what
ways they succeed in this attempt is not yet entirely clear to us, and
some of the questions in Section \ref{future} are meant to elucidate
this. 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 our research for this report, and from our conversations with
Open Source projects and with our clients over the years, we see some
evidence that DOSP is most likely to achieve the licensor's goals for
fast-moving, cutting-edge software, where access to the latest
features is commercially significant. For software whose year-old
versions are, for the typical user, suitable replacements for the
latest proprietary versions, the market segmentation offered by DOSP
weakens or disappears. Those cases essentially collapse down to a
proprietary-licensing scheme with proprietary and A/GPL options.
By far the most important conclusion we draw from our research is that
there has been a \emph{lot} more experimentation and variety in DOSP
than we realized --- more projects have tried it than we knew, and
have tried it in far more varying ways than we knew. Although there
seems to be a slight trend towards convergence recently, at least in
terms of DOSP license texts, there is no guarantee that this trend
will continue, and in any case the same licensing terms will often
lead to different outcomes for different projects.
This report should be viewed as a starting point. We strongly hope
that qualified researchers will find opportunities to pursue some of
the questions suggested in Section \ref{future}, and that in doing so
they will discern patterns that lead them to even more important
questions that we haven't thought of.
\numberedsection{Sources and References}\label{sources} \newpage
\begin{itemize}
\item \otscite{Creative Commons Final Report: On the Viability and \numberedsection{Future Research Questions}\label{future}
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 \begin{itemize}
\item \otscite{Wikipedia: List of Commercial Video Games With Later Released Source Code}\\ \item \textbf{AGPL versus DOSP licensing.}
\otsurl{https://en.wikipedia.org/wiki/List\_of\_commercial\_video\_games\_with\_later\_released\_source\_code}
% 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 non-copyleft licenses.} However, the
proponents didn't agree about which license better responds to
this scenario; in at least some cases, that may imply a more
basic disagreement about values and whether Open Source licensing
is intrinsically preferable.
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.
%
% I put in a brief reference to MongoDB's relicensing above without
% entering into the question of the rationale or what AWS's
% competitive offering might have been.
\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?}
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? And can answers to these
questions about OpenTofu and Terraform be applied to other
projects that have undergone similar relicensing schisms?
\end{itemize} \end{itemize}
\numberedsection{Acknowledgements}\label{acknowledgements-sow} \numberedsection{Acknowledgements}\label{acknowledgements-sow}
TBD The authors are grateful to the Open Source Initiative for giving us
the opportunity to explore this topic and to make, we hope, a small
contribution to the future health of Open Source by analyzing industry
trends likely to affect it.
Many people responded to our call for examples. They always
accompanied their submissions with historical context, and often with
thoughtful analysis as well. We thank them all sincerely; this report
would not have been possible without their help. We list them here in
no particular order (in fact, in mechanically randomized order):
Matija Šuklje,
AntiCompositeNumber [sic],
Simon Phipps,
Damiano Verzulli,
Josh Berkus,
Marcin Koziej,
Alex Scammon,
Thomas Sandmann,
Royce Williams,
Ross Mounce,
Nick Vidal,
Stuart D. Gathman,
Mark Chapman,
Samuel Tardieu,
Chad Whitacre,
Johann Schöpfer,
Abby Kearns,
André Wolski,
Heather Meeker,
Neil Carpenter,
Sam Ramji,
Anthony Nowocien,
Stefano Maffulli,
and Jesse Bickel.
The authors are solely responsible for the contents of this report,
including but not limited to any errors.
% Two examples learned from https://blog.adamretter.org.uk/business-source-license-adoption/ % Two examples learned from https://blog.adamretter.org.uk/business-source-license-adoption/
\BLOCK{endblock} \BLOCK{endblock}
notes.md
View file @ d50531bd
...@@ -8,27 +8,9 @@ Databases licensed under BUSL: ...@@ -8,27 +8,9 @@ Databases licensed under BUSL:
https://dbdb.io/browse?license=business-source-license&q= https://dbdb.io/browse?license=business-source-license&q=
(those that we don't already have are ArcticDB, Dragonfly, Memgraph, evitaDB, ReadySet, and SurrealDB) Elastic License v2 - has hosting noncompete clause but no conversion to FOSS
Licenses indexed there that I'm not familiar with and that we should double-check for possible We can also do a search for particular SPDX values, like "BUSL" or "BUSL-1.1", in a SPDX line -- probably on GitHub!
DOSP-nature:
```
Code Project Open License
Commons Clause License
Elastic License v2
Fair Source License
Microsoft Reference Source License
Mulan PubL v2
OpenLDAP Public License
Open Software License 3.0
Parity Public License
Server Side Public License
VoltDB Proprietary License
```
We can also do a search for particular SPDX values, like "BUSL" or "BUSL-1.1", in a SPDX line --
probably on GitHub!
# Examples # Examples
...@@ -49,13 +31,13 @@ need followup. ...@@ -49,13 +31,13 @@ need followup.
(See also https://github.com/zooko/tgppl -- note that Richard (See also https://github.com/zooko/tgppl -- note that Richard
Fontana is in the commit history there.) Fontana is in the commit history there.)
* [Atom (text editor)](https://atom-editor.cc/blog/2014/05/06/atom-is-now-open-source/) * ONE-OFF [Atom (text editor)](https://atom-editor.cc/blog/2014/05/06/atom-is-now-open-source/)
(suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772) (suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772)
Probably not DOSP: Apparently had no license at all prior to this. Probably not DOSP: Apparently had no license at all prior to this.
* BerkeleyDB and Sleepycat? * NOT DOSP BerkeleyDB and Sleepycat?
Probably not DOSP: simultaneous dual license. Probably not DOSP: simultaneous dual license.
...@@ -63,13 +45,13 @@ need followup. ...@@ -63,13 +45,13 @@ need followup.
Have not found any reference to licensing so far. Have not found any reference to licensing so far.
* [Ghostty](https://mitchellh.com/ghostty) * ONE-OFF [Ghostty](https://mitchellh.com/ghostty)
(suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772) (suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772)
"A private project. I plan to open source it one day" "A private project. I plan to open source it one day"
* Modular/Mojo (a highly-anticipated project from Chris Lattner * ONE-OFF Modular/Mojo (a highly-anticipated project from Chris Lattner
(creator of LLVM, Swift, and XLA/TensorFlow). (creator of LLVM, Swift, and XLA/TensorFlow).
Possibly an example based on code quality and similar concerns, Possibly an example based on code quality and similar concerns,
...@@ -91,15 +73,10 @@ need followup. ...@@ -91,15 +73,10 @@ need followup.
their way of operating probably warrants mention in the Appendix, as their way of operating probably warrants mention in the Appendix, as
people interested in DOSP would also want to know about this. people interested in DOSP would also want to know about this.
* MkDocs * UNCLEAR MkDocs
I haven't found any delayed licensing information. I haven't found any delayed licensing information.
* Onivim 2 (was this unplanned?) [issue](https://github.com/onivim/oni2/issues/3771)
see also https://v2.onivim.io/early-access-portal and
https://github.com/onivim/oni2/issues/3811#issuecomment-910306404 for additional
history
* Android (Google's eventual publication of changes to AOSP) * Android (Google's eventual publication of changes to AOSP)
If Google has typically been pretty regular about releasing stuff to If Google has typically been pretty regular about releasing stuff to
...@@ -113,43 +90,28 @@ need followup. ...@@ -113,43 +90,28 @@ need followup.
Cf. the situation with video game development, as Seth noted. Cf. the situation with video game development, as Seth noted.
* OPSI ["co-funding"](https://www.opsi.org/de/dokumentation/opsi-lizenz-und-copyright) (see also [this forum link](https://forum.opsi.org/viewtopic.php?t=1193))
They have clearly used a form of delayed open source release in the past in
connection with a bounty-like co-funding mechanism, which is still alluded
to on the company's web site. However, it's not clear that this model is
actively used anymore for the majority of development (if at all), as most
of the code appears to be under an open core model with a subscription model
for proprietary extensions.
* [OTRS](https://www.znuny.org/en/blog/why) (open source -> delayed -> * [OTRS](https://www.znuny.org/en/blog/why) (open source -> delayed ->
proprietary), but one person said that the announced delayed open release proprietary), but one person said that the announced delayed open release
never actually happened. never actually happened.
* Pixelfed ["will be open sourced when we reach v1"](https://pixelfed.org/mobile-apps) * ONE-OFF Pixelfed ["will be open sourced when we reach v1"](https://pixelfed.org/mobile-apps)
* Qt (officially delayed releases in the past from Trolltech?) * Qt (officially delayed releases in the past from Trolltech?)
* "searchcode" server under an "eventually open license" according to the post * UNCLEAR [Zed](https://zed.dev/blog/open-sourcing-zed-on-zed)
[GPL Time-bomb an interesting approach to #FOSS licensing](https://boyter.org/2016/08/gpl-time-bomb-interesting-approach-foss-licensing/)
by Ben Boyter.
https://searchcodeserver.com/knowledge-base/eventually-open.html
* [Zed](https://zed.dev/blog/open-sourcing-zed-on-zed)
(suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772) (suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772)
# Not software * INAPPLICABLE Hudson->Jenkins
* Rockefeller University Press Journal of Cell Biology has a delayed Alex Scammon mentioned the Hudson->Jenkins transition to Karl. But
open access policy with delayed relicensing of academic journal articles on looking more closely into [the
(although the end license is a noncommercial Creative Commons license history](https://en.wikipedia.org/wiki/Jenkins_(software)), it looks
so it would not be considered open source) like this was not about licensing, but rather about community
influence vs corporate (Oracle) influence on shared project
* Maybe there are other examples of delayed open access in journals with decisions. ([This
formal relicensing that would be considered fully open source (if the article](https://www.infoworld.com/article/2624986/oracle-s-open-source-missteps-continue-with-hudson-project.html)
articles were software)? seems to give a good overview of what happened.)
# An annoying nomenclature problem # An annoying nomenclature problem
...@@ -186,17 +148,6 @@ suggesting some of these cases (which can be fairly famous, like Netscape ...@@ -186,17 +148,6 @@ suggesting some of these cases (which can be fairly famous, like Netscape
Navigator!), but I think these should be thought of as more of a one-time Navigator!), but I think these should be thought of as more of a one-time
"change" than a "delay". "change" than a "delay".
See also [Creative Commons Final Report: On the Viability and
Development of Springing
Licenses](https://creativecommons.org/wp-content/uploads/2018/07/Springing-licenses-FINAL.pdf).
Lawrence Rosen's book *Open Source Licensing: Software Freedom and Intellectual Property Law* uses the term "eventual source".
And Kyle Mitchell just published (as we were in the middle of doing
this research) the blog post [A Short, Simple Template for Scheduled
Relicensing](https://writing.kemitchell.com/2023/10/24/Scheduled-Relicensing),
that should probably at least be referenced from our report.
# Enforceability # Enforceability
The Creative Commons review seems to have been concerned that springing The Creative Commons review seems to have been concerned that springing
...@@ -223,7 +174,7 @@ more examples. Please add other threads here too. ...@@ -223,7 +174,7 @@ more examples. Please add other threads here too.
* https://twitter.com/kfogel/status/1699104095976423795 * https://twitter.com/kfogel/status/1699104095976423795
* https://chat.opentechstrategies.com/#narrow/stream/2-general/topic/DOSP/near/172793 * https://chat.opentechstrategies.com/#narrow/stream/2-general/topic/DOSP/near/172793
* https://news.ycombinator.com/item?id=37745772 * https://news.ycombinator.com/item?id=37745772
* http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2023-October/thread.html#22130 * http://lists.opensource.org/pipermail/license-discuss\_lists.opensource.org/2023-October/thread.html#22130
# Resources to check # Resources to check
...@@ -235,28 +186,3 @@ more examples. Please add other threads here too. ...@@ -235,28 +186,3 @@ more examples. Please add other threads here too.
a really good post, in Karl's opinion, not that anyone asked him, a really good post, in Karl's opinion, not that anyone asked him,
but hey, if you're editing the notes file then you get to insert but hey, if you're editing the notes file then you get to insert
your opinions.) your opinions.)
* Old games and libraries from [id Software](https://github.com/id-Software),
but was this planned or announced?
# More people to contact as we're gathering examples
If your name should be on the list below but isn't, please [let us
know](https://code.librehq.com/ots/dosp-research/-/issues/new)!
* Deb Bryant
* Danese Cooper
* L. Peter Deutsch
* Raph Levien
* Zooko
* Your Name Here...
# Sources / Acknowledgements
* Simon Phipps
* Stefano Maffulli
* Nick Vidal
* Bastian Greshake Tzovaras
* Sam Ramji
* Heather Meeker
* Abby Kearns
parkinglot.ltx 0 → 100644
View file @ d50531bd
\numberedsection{Enforceability}\label{enforce}
Delayed open source licensing is less explored than immediate open source
licensing, and some observers have expressed concerns about its legal
enforceability. For example, if an author died before the announced license
transition date, would the author's heirs be required to honor the license
transition, or could they potentially cancel or withdraw it? What if a
company were acquired by a new owner which wanted to retroactively change
its licensing structure?
% XXX We obviously don't know yet because ...
The Creative Commons research on springing licenses expressed some concerns
about their enforceability. The Creative Commons organization itself
previously implemented a delayed licensing mechanism called Founders
Copyright; unlike other Creative Commons licenses, the Founders Copyright
involves a copyright assignment to the Creative Commons nonprofit
organization itself. The organization then commits to grant the original
author an exclusive license to the for the announced delay period, and
to license the work to the public afterward. It appears that this copyright
assignment mechanism was intended to minimize uncertainty about the
extent to which authors could bind themselves (or their successors) to
future licensing intentions, although it required direct involvement by
the nonprofit as copyright holder and licensor, a role it had otherwise
not seen fit to take on.
Kyle E. Mitchell distinguishes ``a present grant of a license" (with a
specified future start date) from ``a contractual promise to grant the
license later" and advocates using the former, although he does not
imply that the latter is invalid or unenforceable. Mitchell's concerns
focus on clarity and persistent documentation of specific license
grants to specific code and project versions.
work.md
View file @ d50531bd
# 2023-11-07:
* (James+Karl) High-level organizing and writing in the report.
* (Seth) Did rate of outside contribution change after BUSL
relicensing of Terraform, and maybe same for some other project that
either didn't have a fork or that had a not-conspicuously-successful
fork. Not sure which project that latter would be, but it would be
great if we could identify one for comparison, since the Terraform
fork has so conspicuously successful so far.
* (Seth) Similar investigation using bug tracker data instead of
commits.
* (Seth) Figure out what other DOSP licenses there are:
See "Licenses indexed there that I'm not familiar with and that we
should double-check for possible DOSP-nature" in notes.md.
* (Seth) Remaining todo items from 2023-11-03 entry below.
* (James+Karl, for now at least) We should raise (but not try to
answer) the question of why some BUSL-relicensed projects stimulate
flourishing FOSS forks while others do not. Even within Hashicorp's
projects there are pretty dramatic contrasts.
# 2023-11-03: # 2023-11-03:
* Mark items in notes.md so we know what remains to be investigated in there. * Mark items in notes.md so we know what remains to be investigated in there.
......