You need to sign in or sign up before continuing.
Newer
Older
This file contains free-form notes. Anyone working on this project,
please feel free to reformat this (including to something other than
Markdown) if you want.
# Some additional license search methods
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!
# Examples
Note that some of these examples are still just pointers that will
need followup.
* Stuff about TGGPL:
The 2020 blog post [Introducing BOSL, a radically new type of
open-source
license](https://electriccoin.co/blog/introducing-tgppl-a-radically-new-type-of-open-source-license/)
discusses BOSL license and gives some examples of its use.
An earlier (2010) writeup about TGPPL from Ted T'so is
[The Transitive Grace Period Public Licence: good ideas come
around…](https://thunk.org/tytso/blog/2010/01/20/the-transitive-grace-period-public-licence-good-ideas-come-around/).
(See also https://github.com/zooko/tgppl -- note that Richard
Fontana is in the commit history there.)
* 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)
Probably not DOSP: Apparently had no license at all prior to this.
* NOT DOSP BerkeleyDB and Sleepycat?
* ONE-OFF [Ghostty](https://mitchellh.com/ghostty)
(suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772)
* ONE-OFF Modular/Mojo (a highly-anticipated project from Chris Lattner
(creator of LLVM, Swift, and XLA/TensorFlow).
Possibly an example based on code quality and similar concerns,
but no fixed schedule: https://docs.modular.com/mojo/faq.html#open-source
The situation with GitLab is interesting. They make some fairly
specific [public
commitments](https://handbook.gitlab.com/handbook/company/stewardship/#promises)
that are somewhat DOSP-adjacent but are not themselves DOSP
promises. They also say they [default to moving features
"down"ward](https://about.gitlab.com/company/pricing/#default-to-move-features-down),
which in their nomenclature means toward the FOSS product; while
that's not a binding commitment, they do seem in practice to be
sticking to it.
Overall, there does not appear to be an true DOSP activity here, but
their way of operating probably warrants mention in the Appendix, as
people interested in DOSP would also want to know about this.
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
Android Open Source Project, even if they haven't formally committed
to that regularity, then that would be a kind of de facto DOSP.
(Question: do they preserve the commit metadata for commits
originally made in the private repository, so that when those
commits are published, the exact delay between the creation of the
commit and its becoming public can be seen? Karl guesses that they
do preserve all the metadata, but we should check.)
Cf. the situation with video game development, as Seth noted.
* [OTRS](https://www.znuny.org/en/blog/why) (open source -> delayed ->
proprietary), but one person said that the announced delayed open release
never actually happened.
* 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?)
* UNCLEAR [Zed](https://zed.dev/blog/open-sourcing-zed-on-zed)
(suggested by @Zaeraxa in reply to https://news.ycombinator.com/item?id=37745772)
* INAPPLICABLE Hudson->Jenkins
Alex Scammon mentioned the Hudson->Jenkins transition to Karl. But
on looking more closely into [the
history](https://en.wikipedia.org/wiki/Jenkins_(software)), it looks
like this was not about licensing, but rather about community
influence vs corporate (Oracle) influence on shared project
decisions. ([This
article](https://www.infoworld.com/article/2624986/oracle-s-open-source-missteps-continue-with-hudson-project.html)
seems to give a good overview of what happened.)
# An annoying nomenclature problem
Even though we seem to think that the Business Source License should be
called BUSL, most of its end-users seem to refer to it as BSL! It
may be awkward if we end up having a ton of citations where we say
things like "the project FooWare announced it was using BUSL in 2022
(see 'Announcing FooCorp's Switch to BSL')".
I (Seth) think there's a distinction to be made between these three cases:
* "automatic": licenses that are not open source licenses but that state
(in the license text somewhere) that they automatically convert /
automatically permit use and redistribution subject to a specified
open source license after a period of time
* "manual": publicly announced practices of manually relicensing old codebase
snapshots on a particular schedule, which depend on a person at the company
explicitly making a delayed open source release
(In some sense, this is a potential distinction between a "delayed open
source licensing business practice" and a "delayed open source license".)
* "post-hoc" / "unscheduled": proprietary software that eventually was
relicensed under an open source license, without a public statement of
intent to do so at the time of its original publication, or without a
published schedule for the conversion
I would include the former two in the scope of the report but not the
latter one (except to explain how it's different). Some people have been
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
licenses can have enforceability problems. For their older Founders
Copyright project, they actually used a copyright assignment to the
Creative Commons nonprofit rather than (as they usually suggest for
public licensing of creative works) a unilateral license document.
(Was that because of concerns that copyright can't necessarily be
abandoned under U.S. law, or because of concerns that a licensor or the
licensor's heirs could withdraw or revoke the license if it were given
unilaterally with a delay?)
It might be helpful to understand how serious the enforceability concerns
are, although it doesn't seem that they've ever been tested in court, so
it may be hard to say anything definitive.
Look in the follow-ups in these threads (and subthreads thereof) for
more examples. Please add other threads here too.
* https://kfogel.org/notice/AZSlnFS0GBe2x7Rd6u
* https://twitter.com/kfogel/status/1699104095976423795
* https://chat.opentechstrategies.com/#narrow/stream/2-general/topic/DOSP/near/172793
* http://lists.opensource.org/pipermail/license-discuss\_lists.opensource.org/2023-October/thread.html#22130
# Resources to check
* Free Software Business (fsb) mailing list archives at https://web.archive.org/web/20210000000000\*/http://www.crynwr.com/cgi-bin/ezmlm-cgi/0/
* The post [Why Open Source
Matters](https://redmonk.com/sogrady/2023/08/03/why-opensource-matters/)
from RedMonk (Aug 2023) points to some other examples. (Also, it's
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
# Sources / Acknowledgements
* Simon Phipps
* Stefano Maffulli
* Nick Vidal
