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 (62)
......@@ -19,3 +19,4 @@ noun_Key_1785639_ltgreen.svg
noun_Telephone_2591756.svg
noun_Telephone_2591756_ltgreen.svg
svg-inkscape
doc/kde
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.
To build the whitepaper from LaTeX source, you will need to use
[OTS DocTools](https://code.librehq.com/ots/ots-doctools).
## Building the whitepaper PDF from LaTeX source
Just kidding -- the whitepaper doesn't exist yet. Instead, we have
this free-form [notes file](notes.md). For now, that's the right
landing place for contributions.
To build the whitepaper from LaTeX source, use [OTS
DocTools](https://code.librehq.com/ots/ots-doctools).
#!/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 )/..
......
This diff is collapsed.
......@@ -8,25 +8,9 @@ Databases licensed under BUSL:
https://dbdb.io/browse?license=business-source-license&q=
Licenses indexed there that I'm not familiar with and that we should double-check for possible
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!
Elastic License v2 - has hosting noncompete clause but no conversion to FOSS
We can also do a search for particular SPDX values, like "BUSL" or "BUSL-1.1", in a SPDX line -- probably on GitHub!
# Examples
......@@ -93,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
......@@ -174,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
......@@ -223,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
\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.