From cf922c27165264431c8af18173fc1cd1c83f4cc2 Mon Sep 17 00:00:00 2001
From: Seth Schoen <schoen@loyalty.org>
Date: Fri, 3 Nov 2023 09:06:02 -0700
Subject: [PATCH] Reorder report sections
---
dosp-survey.ltx | 144 +++++++++++++++++++++++++-----------------------
1 file changed, 74 insertions(+), 70 deletions(-)
diff --git a/dosp-survey.ltx b/dosp-survey.ltx
index 5f03e9b..76a84e1 100644
--- a/dosp-survey.ltx
+++ b/dosp-survey.ltx
@@ -84,61 +84,27 @@ eventually decide to do so. These aren't technically in scope, but we
should give some examples somewhere --- maybe in a footnote or
appendix --- just to make it clear that it's something that happens.
-\numberedsection{Other Terminology and Practices}\label{terminology}
-
-We've encountered a number of other terms that can describe DOSP or
-the licensing mechanisms used to implement it.
-
-\begin{itemize}
-
- \item Eventual (open) source; scheduled licensing.
-
- Lawrence Rosen's book on open source licensing refers to ``eventual source"
- or ``eventually open source" software, giving the example of Aladdin
- GhostScript. He also calls this ``scheduled licensing".
-
- \item Springing licenses.
-
- A research report from Creative Commons refers to ``springing licenses"
- (licenses that grant additional permissions after a period of time, or
- when some other condition has been met). Creative Commons was mainly
- interested in the possibility of developing licenses that would grant
- additional permissions over time, after a period of greater exclusivity.
-
- \item Scheduled relicensing.
+\numberedsection{Motivations}\label{motivations}
- Kyle E. Mitchell refers to ``scheduled relicensing".
+DOSP is usually described as protecting commercial interests of a software
+developer by maintaining a window of time during which some users might be
+incentivized to pay for licenses that they might not need if the software
+were released as open source.
-\end{itemize}
+% Fit into discussions about incentive/funding models
-One can also distinguish between a public pledge to relicense on a schedule
-(as GhostScript did) and a license document whose text includes date or
-other restrictions. In the former case, the delayed release is implemented
-by human beings (actively making a new software release including new
-license text); in the latter case, it is automatic.
+We've also seen one-time delays for new projects whose developers state
+a concrete intention to convert those projects to an open source license.
+They may have non-economic reasons for those delays, such as shame about
+poor code quality, concern about security issues that may be apparent in
+unaudited source code, a need to procure permissions from other copyright
+holders, a desire to establish a community or governance structure, or
+a plan to incorporate a legal entity.
-We do not consider ``unplanned" open source releases to be examples of DOSP.
-There are a number of high-profile cases of proprietary projects that were
-retroactively relicensed as open source as a result of a one-off decision.
-Where developers originally had no announced plan or intention to do this,
-we think this is best considered a separate phenomenon, not a ``delayed"
-release.
-Many people also mentioned the custom among some video game developers of
-releasing code (though usually not assets such as graphics and sound)
-from proprietary video games that are no longer commercially important.
-This is a relatively widespread practice, with Wikipedia identifying
-dozens of instances.
-% TODO \cite{Wikipedia}
-Some companies like id Software have made such releases for multiple video
-game generations.
-While many of these developers apparently had a general intention to make
-their games open source, in whole or in part, at some point in the future,
-there was usually no public commitment to do so on any particular
-schedule or under any particular circumstances. This practice is thus not
-a core example of DOSP.
+\numberedsection{Scheduled Relicensing}\label{scheduled}
-\numberedsection{Aladdin GhostScript Delayed Releases}\label{ghostscript}
+\subsection{Early History}
For many years, Aladdin GhostScript implemented a DOSP policy whereby
new versions were published under a proprietary license, and then regularly
@@ -170,7 +136,7 @@ for licenses.
% Rosen also says that sendmail may have had a dual license in the same
% era or even before Ghostscript.
-\numberedsection{Bounty and Sponsorship Delays}\label{bounty}
+\subsection{Bounty and Sponsorship Delays}\label{bounty}
Another model is making individual software features or enhancements
available to sponsors first, with a fixed time delay before making
@@ -184,7 +150,7 @@ While we fully intend to make the full SLYR plugin open source and freely publis
% https://north-road.com/slyr/
-\numberedsection{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
of this license refer to it as ``BSL", but
@@ -245,26 +211,9 @@ A: When using dual licensing with GPL, companies must pay for a commercial licen
This is echoed in statements by several BUSL adopters that they sought a way to make downstream commercial users who did not redistribute derived works pay for the use of their software (typically in cloud environments), or wanted to prevent downstream commercial users from directly competing with the initial developer's own service offerings.
-\subsection{Some Subsection}\label{some-subsection}
-
-TBD
-
-\numberedsection{Motivations}\label{motivations}
-
-DOSP is usually described as protecting commercial interests of a software
-developer by maintaining a window of time during which some users might be
-incentivized to pay for licenses that they might not need if the software
-were released as open source.
-
-% Fit into discussions about incentive/funding models
+\subsection{Other}
-We've also seen one-time delays for new projects whose developers state
-a concrete intention to convert those projects to an open source license.
-They may have non-economic reasons for those delays, such as shame about
-poor code quality, concern about security issues that may be apparent in
-unaudited source code, a need to procure permissions from other copyright
-holders, a desire to establish a community or governance structure, or
-a plan to incorporate a legal entity.
+We will mention FSL here.
\numberedsection{Enforceability}\label{enforce}
@@ -330,6 +279,61 @@ Initiative, it appears to us to be compatible with the Open Source
Definition, and --- unlike BUSL, for instance --- is claimed by its
authors to be a form of open source licensing.
+\numberedsection{Other Terminology and Practices}\label{terminology}
+
+We've encountered a number of other terms that can describe DOSP or
+the licensing mechanisms used to implement it.
+
+\begin{itemize}
+
+ \item Eventual (open) source; scheduled licensing.
+
+ Lawrence Rosen's book on open source licensing refers to ``eventual source"
+ or ``eventually open source" software, giving the example of Aladdin
+ GhostScript. He also calls this ``scheduled licensing".
+
+ \item Springing licenses.
+
+ A research report from Creative Commons refers to ``springing licenses"
+ (licenses that grant additional permissions after a period of time, or
+ when some other condition has been met). Creative Commons was mainly
+ interested in the possibility of developing licenses that would grant
+ additional permissions over time, after a period of greater exclusivity.
+
+ \item Scheduled relicensing.
+
+ Kyle E. Mitchell refers to ``scheduled relicensing".
+
+\end{itemize}
+
+One can also distinguish between a public pledge to relicense on a schedule
+(as GhostScript did) and a license document whose text includes date or
+other restrictions. In the former case, the delayed release is implemented
+by human beings (actively making a new software release including new
+license text); in the latter case, it is automatic.
+
+We do not consider ``unplanned" open source releases to be examples of DOSP.
+There are a number of high-profile cases of proprietary projects that were
+retroactively relicensed as open source as a result of a one-off decision.
+Where developers originally had no announced plan or intention to do this,
+we think this is best considered a separate phenomenon, not a ``delayed"
+release.
+
+Many people also mentioned the custom among some video game developers of
+releasing code (though usually not assets such as graphics and sound)
+from proprietary video games that are no longer commercially important.
+This is a relatively widespread practice, with Wikipedia identifying
+dozens of instances.
+% TODO \cite{Wikipedia}
+Some companies like id Software have made such releases for multiple video
+game generations.
+While many of these developers apparently had a general intention to make
+their games open source, in whole or in part, at some point in the future,
+there was usually no public commitment to do so on any particular
+schedule or under any particular circumstances. This practice is thus not
+a core example of DOSP.
+
+
\numberedsection{Sources and References}\label{sources}
\begin{itemize}
--
GitLab