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 (43)
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,
then later (usually in a planned fashion) publishing that release's
source code under an open source license.
While delayed open source publication been somewhat rare, there are
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
term "open source". To the best of our knowledge, when software
authors have done this it has usually been in a fairly predictable
way. For example, when release N goes out under a proprietary
license, release N-1 is then (re)published under an open source
license.
This repository is a collection of research, and eventually a
whitepaper, about various examples of DOSP and show how they are alike
or different. We will also analyze the effects (if any) of this
practice generally on open source as a field. Our purpose is to
provide accurate historical description and objective analysis; our
work here represents no position on the desirability or undesirability
of delayed open source publication.
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
then later publishing that release's source code under an open source
license. (This is often, but not always, done in a predictable
fashion: e.g., when release N goes out under a proprietary license,
release N-1 is then (re)published under an open source license.)
There are examples of DOSP across the history of open source -- in
fact, some of the examples (e.g., Aladdin Ghostscript) predate the
coining of the term "open source". We looked at various instances of
DOSP and examined how they are alike or different. We also analyzed
the effects (if any) of DOSP on open source as a field. Our purpose
was to provide accurate historical description and objective analysis;
our work here represents no position on the desirability or
undesirability of delayed open source publication.
This research was supported by the [Open Source Initiative
(OSI)](https://opensource.org/). The report is now completed and
published at
[opensource.org/delayed-open-source-publication](https://opensource.org/delayed-open-source-publication).
## Contacting us
You can email us at `dosp-research {_AT_} opensource.org` or [file a
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.
## Building the whitepaper PDF from LaTeX source
To build the whitepaper from LaTeX source, you will need to use [OTS
DocTools](https://code.librehq.com/ots/ots-doctools). ***Note that
the whitepaper is still a work in progress. Please do not cite the
draft nor quote from it in public forums yet.*** We'll remove
this notice when the paper is ready for publication.
To build the whitepaper from LaTeX source, use [OTS
DocTools](https://code.librehq.com/ots/ots-doctools).
\begin{longtable}[l]{l l l l l}
\textbf{Project} & \textbf{BUSL date} & \textbf{Change Date} & \textbf{Change License} & \textbf{Reference} \\
Akka & 2022-09-07 & rel. +3 years & Apache v2 & \otsurl{https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka} \\
ArangoDB & 2023-10-11 & rel. +4 years & Apache v2 & \otsurl{https://arangodb.com/2023/10/evolving-arangodbs-licensing-model-for-a-sustainable-future/} \\
ArcticDB & [always] & rel. +2 years & Apache v2 & [no ref] \\
% https://github.com/man-group/ArcticDB/blob/master/LICENSE.txt
CockroachDB & 2019-06-04 & rel. +3 years & Apache v2 & \otsurl{https://www.cockroachlabs.com/docs/stable/licensing-faqs\#bsl} \\
CodeCov & 2023-08-02 & rel. +3 years & Apache v2 & \otsurl{https://about.codecov.io/blog/codecov-is-now-open-source/} \\
CouchBase & 2021-03-26 & rel. +4 years & Apache v2 & \otsurl{https://www.couchbase.com/blog/couchbase-adopts-bsl-license/} \\
DragonflyDB & 2022-05-29 & +5 years & Apache v2 & REF \\
% https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.md
evitaDB & [always] & 4th cal. year & Apache v2 & [no ref] \\
% https://github.com/FgForrest/evitaDB/blob/dev/LICENSE
Materialize\footnote{Not to be confused with the Materialize CSS project, which is released under the MIT license.} & 2020-02-07 & daily +4 years\footnote{Differently from other BUSL-licensed projects, Materialize uses a bot to update the Change Date every day (not just on the occasion of release events), so that it always reflects a date exactly four years after the present date.} & Apache v2 & REF \\
MaxScale & 2017-02-14 & rel. +4 years & GPL v2 & \otsurl{https://mariadb.com/resources/blog/releasing-bsl-1-1/} \\
Memgraph & 2021-10-03 & rel. +4 years & Apache v2 & REF \\
% https://github.com/memgraph/memgraph/blob/master/licenses/BSL.txt
ReadySet & 2022-08-03 & rel. +4 years & Apache v2 & REF \\
% https://github.com/readysettech/readyset/blob/main/LICENSE
Sentry\footnote{Sentry subsequently relicensed under its own ``Functional Source
License''; see below for further discussion.} & 2019-11-06 & rel. +3 years & Apache v2 & REF \\
SurrealDB & 2021-12-14 & rel. +4 years & Apache v2 & REF \\
% https://github.com/surrealdb/surrealdb/blob/main/LICENSE
Terraform (etc.)\footnote{``HashiCorp Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, and Vagrant" are identified as relicensed by \otsurl{https://www.hashicorp.com/license-faq}.} & 2023-08-10 & rel. +4 years & MPL 2.0 & REF \\
ZeroTier & 2019-08-28 & 5th cal. year & Apache v2 & REF \\
\end{longtable}
This diff is collapsed.
......@@ -77,16 +77,6 @@ need followup.
I haven't found any delayed licensing information.
* ONE-OFF Onivim 2 [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
There was an early-access sponsorship system but there was never a
public commitment to relicense the code under an open source license.
The developer later stopped working on the project and then relicensed
it as MIT in its entirety.
* Android (Google's eventual publication of changes to AOSP)
If Google has typically been pretty regular about releasing stuff to
......@@ -158,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
"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
The Creative Commons review seems to have been concerned that springing
......@@ -207,26 +186,3 @@ more examples. Please add other threads here too.
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
your opinions.)
# 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
* Alex Scammon