Write a license

[chadwhitacre]

BUSL-1.1 is an interesting approach but is hampered by the variables it allows for:

1. additional use grant
2. change date
3. change license

The first of these is especially wide open, resulting in wildly different meanings for different implementations such as MariaDB, Sentry, and HashiCorp. This makes every BSL/BUSL unique, which means that compliance departments have to individually review each implementation, greatly slowing adoption.

Let's write a new license that takes the best of BUSL-1.1, in particular the "delayed open source publishing" approach, and tightens it up so that it can be something compliance departments can work with more easily.

---

Draft website: fsl.software

Draft license: Google Doc

☝️☝️☝️☝️☝️☝️☝️☝️☝️☝️☝️☝️☝️☝️☝️

[djc]

CockroachDB apparently is another fairly high-profile BUSL user?

https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/

It was discussed on this podcast episode recently as a good example in particularly because it has a highly objective, clear additional use grant. (In contrast, the podcasters are not so positive about how HashiCorp has communicated on their use grant(s).)

[chadwhitacre]

Okay! Circling back here ... we (Sentry) are ready to go on this one. We've written a license we're calling Functional Source License (FSL). We've got a draft of the license on a draft of a website to promote it (using this repo for GH pages; we own fsl.software for when the time comes):

https://getsentry.github.io/loose-confederation/

cc: @heathermeeker interested in your feedback in particular on this one. 🙏

[ljharb]

cc @kemitchell for possible feedback as well

[kemitchell]

Why conflate the license for use now with the schedule for relicensing later? Business Source does that, but your complaint against Business Source seems to be that it does too much, with too much flexibility.

[hmeeker]

I have a lot of comments. Is it possible to do a real-time drafting session?

[chadwhitacre]

I'm up for it. :)

Early next week okay?

[gavin-zee]

Why conflate the license for use now with the schedule for relicensing later? Business Source does that, but your complaint against Business Source seems to be that it does too much, with too much flexibility.

We were aligned with some of the BUSL principles, like having some period of time during which competing uses of the software were prohibited, after which a full conversion to an open source license occurs. Our main issue with the BUSL was that because the "Additional Use Grant", "Change Date" and "Change License" can be defined by the licensor, no two versions of actually implemented license were alike.

The FSL attempts to solve for this by hardwiring definitions of competing use, the non-compete period and the actual change license.

We also thought about simply having a non-compete restriction that expired after a set time, but ultimately decided that it was important that the software become available under an open source license.

[chadwhitacre]

Greetings, @kemitchell! :-)

Why conflate the license for use now with the schedule for relicensing later?

Simplicity, I guess? What would the alternative look like?

[kemitchell]

There are clearly some license terms that lots and lots of people want, like "do whatever you want, just don't hold us liable". But for businesses looking to defend themselves from competitors with small steps back from open terms, the rule has been lots of variation. If MariaDB had "hard-coded" its own "Additional Use Grant", rather than making it as a field to fill, Hashi probably wouldn't have adopted the Business Source. Their "Change Licenses" and "Change Dates" differ, too. The old trade-off between adaptability and adoption applies.

I don't see any strong correlations between the kinds of present-tense license rules companies want and the release schedule or target license they choose. Many teams interested in restricted licenses don't want scheduled relicensing at all. So piling all those choices into one "standardized" license only means more potential disagreement and misfit.

I've long had it on my list to publish versioned terms just for scheduling relicensing of published code onto new terms. Decouple that from the restricted license terms that apply in the meantime, so we can focus more on finding and popularizing reusable restricted forms, like the PolyForm licenses.

[chadwhitacre]

Thanks @kemitchell. We did have a conversation internally about whether we think our goals could be met by adopting PolyForm. The reason we decided to initiate a new effort is that we like the BUSL except for the variability, and we're not seeing critical mass with PolyForm's adoption. From initial conversations with other smaller companies in our orbit, we think we have a shot to build adoption around FSL. We shall see! 🤞

[gauthamcs]

About this line in the FSL Q&A (link)

"In plain English, you can do anything with FSL software except (for one year) use it to compete with its author."

Unclear if the one year non-compete term provide companies enough coverage for their work, especially as their project matures and significant enhancements take longer than a year to ship.

One extreme scenario is a large cloud provider deciding to bundle a 1-year old version of an FSL project with their other offerings. This becomes especially challenging as the project matures and there are fewer needle moving enhancements each year. At that point, a year old version of the software may be “good enough” and the cloud provider’s distribution advantage may make it hard for the project owner to stay competitive.

IMO the non-compete term should be longer than a year. This doesn’t materially change the intent or the spirit of the FSL but provides contributors the ability to stay competitive.

[chadwhitacre]

From HN:

Don't know if anyone at Sentry will read this, but I think the idea of the Functional Source License is pretty interesting.

But is it customizable? e.g. does the source has to be made available 1 year? How about 2? How about 1.5?

How about something like FSL-Y2-MIT for a 2-year limitation? You could still use FSL-MIT for the standard 1 year term.

Then you could maybe allow quarter- or half-integer values, e.g. FSL-Y1.5-MIT or FSL-Y0.25-MIT.

All of this easily represented in the name or with minimal digging.

Just wanted to throw in my share of the bike-shedding.

[chadwhitacre]

My reply: "One of our goals is to keep the parameters to an absolute minimum, to aid in adoption. The simpler we can keep it the more easily it will get picked up, is the thinking."

[kemitchell]

Blog post and draft on separating scheduled relicensing from initial license terms: https://writing.kemitchell.com/2023/10/24/Scheduled-Relicensing

[chadwhitacre]

a year old version of the software may be “good enough”

@gauthamcs What is your comfort level with two years? Could you get behind that?

[ljharb]

Software moves very fast; a year old is ancient - I'd expect less time, not more.

[chadwhitacre]

Software moves very fast; a year old is ancient

For an individual, but for an enterprise? Would some ginormous company be willing to use a year-old version of (e.g.) Sentry for (e.g.) half the price? Does that matter?

[chadwhitacre]

@gavin-zee @heathermeeker and I had a drafting session today, here's the doc we're marking up. We plan to touch base again tomorrow with @gavin-zee bringing a revision.

We're consolidating our story internally on FSL as an objectively better BUSL that deepens Sentry's commitment to our Open Source values: balancing user freedom and developer sustainability.

We're planning to go with 2 years instead of the current 1. The BUSL default is 4, and almost all of the examples we find in the wild use the default (@benvinegar feel free to add links/color):

• Hashicorp: 4 years
• MariaDB: 4 years
• CockroachDB: 3 years
• Directus.io (?): 4 years
• Couchbase: 4 years
• SurrealDB: 4 years
• Kamu.dev (?): 4 years
• Source.network (?): 4 years

@heathermeeker makes the point that anyone who wants to relicense sooner than that certainly can.

We are likely going to remove the MIT variant, for a few reasons:

1. We want there to be no parameters, in order to aid adoption.
2. The FSL itself already has a patent clause (so if someone doesn't want patent clauses they're already out of luck for 2 years).
3. The Apache variant is the one we would use at Sentry.
4. Having two is a slippery slope (per 0 1 infinity).

Our intention is to relicense from BUSL to FSL by November 17.

[ljharb]

Note that removing the MIT variant would likely prevent significant adoption in the JS space, where MIT is the primary license used.

[hmeeker]

There is also the (theoretical) incompatibility between Apache 2 and GPL2, which would drive toward MIT.

[gauthamcs]

a year old version of the software may be “good enough”

@gauthamcs What is your comfort level with two years? Could you get behind that?

Definitely better than 1-year. IMO if anyone can relicense to a shorter duration than the default, we could just have the default to a longer duration.

[mitsuhiko]

Note that removing the MIT variant would likely prevent significant adoption in the JS space, where MIT is the primary license used.

One thing to consider is that Apache2 retains patent grants, MIT magically loses them past the changeover. So ... that's a bit odd.

[chadwhitacre]

If we want/need more than one change license then here are a few somewhat rational sets of licenses to allow:

1. Sentry's status quo (current set):
   • Apache 2.0
   • MIT
2. GitHub's Choose a License:
   • Apache-2.0
   • GPL-2.0
   • GPL-3.0-only
   • MIT
   • ISC
3. OSI's Popular / Strong Community:
   • Apache-2.0
   • CDDL-1.0
   • EPL-2.0
   • GPL-2.0
   • GPL-3.0-only
   • LGPL-2.1
   • LGPL-3.0-only
   • LGPL-2.0-only
   • MPL-2.0
   • BSD-2-Clause
   • BSD-3-Clause
   • MIT
4. The superset of (2) and (3):
   • OSI's list + ISC

I'd probably lean towards (3) or (4), because I like a stronger relationship with OSI.

---

P.S. Should we try to get more 👀 here?

[djc]

Have you discussed with OSI already to see if the FSL has a chance of being recognized by them?

While I understand there's some value of alignment with OSI, I feel like the set is so large that it substantially waters down the strength of the messaging. It also feels like the more viral licenses that are in the OSI set might conflict with other goals? Personally, from the OSI list I'd feel that CDDL/EPL are not popular enough, GPL/LGPL are viral which makes adoption harder especially in a business context, and BSD is pretty similar to MIT so might have negative net value. The MPL is the only one from that set that seems like an interesting option.

[chadwhitacre]

Have you discussed with OSI already to see if the FSL has a chance of being recognized by them?

I have a call with @smaffulli on the calendar later today. The goal is not to have FSL recognized as an OSD-compliant license, but if there's an opportunity for a more general approval of our approach I'd rather secure it than not. :-)

[augb]

Change License

On the first anniversary of the public release date of the Software, the Software will become available under the Apache 2.0 license. On that date, the Terms and Conditions above automatically terminate and the following terms become effective: ...

from FSL-DRAFT-Apache-2.0.template.md

I read the above Change License statement to mean that all changes to the software as of the "~change license~ public release date" would be then, and going forward, Apache 2.0. Any subsequent changes are automatically incorporated as part of the Apache 2.0 license, whether from the commercial entity or explicitly as part of an open source project.

An example might be that the software is release on 10/27/2023 and consists of one file, File A. (This example assumes that Apache 2.0 is the subsequent license and the release term is 2 years.) My understanding is that File A would be publicly released on 10/27/2025. If File B is added to the project on 10/27/2024, it would also be released under Apache 2.0 on 10/27/2025, as opposed to 10/27/2026.

Is my understanding in line with the intentions of the Functional Source License?

If so, I wonder if an explicit statement along the lines of the following (with my revisions shown below in italics) would be helpful?

On the first anniversary of the public release date of the Software, the Software and any subsequent changes will become available under the Apache 2.0 license. On that date, the Terms and Conditions above automatically terminate and the following terms become effective

PS I would be in favor of Apache 2.0 as the subsequent license.

Update: Changed to public release date instead of change license date.

[chadwhitacre]

@augb Hrm, I can see how this might be ambiguous. The intention is the opposite, though. Maybe something like this, then?

diff --git a/FSL-DRAFT-Apache-2.0.template.md b/FSL-DRAFT-Apache-2.0.template.md
index 3b37a3d..c9811aa 100644
--- a/FSL-DRAFT-Apache-2.0.template.md
+++ b/FSL-DRAFT-Apache-2.0.template.md
@@ -70,10 +70,10 @@ trademarks, trade names, service marks or product names.

 ## Change License 

-On the first anniversary of the public release date of the Software, the
-Software will become available under the Apache 2.0 license. On that date, the
-Terms and Conditions above automatically terminate and the following terms
-become effective:
+On the second anniversary of the public release date of the Software, the
+Software as of said release date will become available under the Apache 2.0
+license. On that date, the Terms and Conditions above automatically terminate
+and the following terms become effective:

 > Licensed under the Apache License, Version 2.0 (the "License"); you may not
 > use this file except in compliance with the License. You may obtain a copy of

[chadwhitacre]

Or "the Software released on that date". Thoughts @gavin-zee @heathermeeker?

[gavin-zee]

Or "the Software released on that date". Thoughts @gavin-zee @heathermeeker?

@chadwhitacre this ties back to the point we were discussing yesterday about what the "Software" is. For simplicity, I wonder if we say the "Software" is the version number of the software made available under the license. The change date is the second anniversary of the public release of that version.

If substantive changes are made to that version (including adding new files), wouldn't that be a new version number anyways?

[chadwhitacre]

Good point. Yes, version numbers are generally understood to be immutable, so we could accomplish this that way.

[benvinegar]

I like the idea of including the change license in the title, even if we only release the Apache 2.0 variant, because:

1. It communicates the target license in the filename, and helps explain that the purpose of this license is to change to something else (clarity)
2. It allows for other target licenses in the future (flexibility)
3. FSL is too generic sounding and will have trouble sticking out in a sea of 3-letter licenses (better marketing/communication)

[ljharb]

How does the license apply to unreleased code (that’s usually still consumable directly from GitHub)?

[augb]

Or "the Software released on that date". Thoughts @gavin-zee @heathermeeker?

@chadwhitacre this ties back to the point we were discussing yesterday about what the "Software" is. For simplicity, I wonder if we say the "Software" is the version number of the software made available under the license. The change date is the second anniversary of the public release of that version.

If substantive changes are made to that version (including adding new files), wouldn't that be a new version number anyways?

I think this clarifies what the new license applies to. This also gives flexibility to the releasing organization to apply different terms going forward, should the need arise.

Update: grammar

[dcramer]

@ljharb

How does the license apply to unreleased code (that’s usually still consumable directly from GitHub)?

Any code on GitHub would have the license applied to it, so technically speaking it'd be whenever the code was "licensed" (which is often when its been pushed to GitHub). I've seen others try to resolve this by claiming branch names, but tbqh that adds an awful lot of complexity that requires maintenance is hard to defend.

[ljharb]

@dcramer so that means that release date is irrelevant; each commit is licensed independently?

[dcramer]

@ljharb

@dcramer so that means that release date is irrelevant; each commit is licensed independently?

Thats my understanding (and I'm also ok with that approach). I'm not sure its the best solution, but one goal was to simplify its use and the date stamping of the LICENSE file is quite tedious.

[ljharb]

Makes perfect sense - which seems like it'd mean that version numbers and the term "release" don't belong in the license? (re some of the above discussion)

[gavin-zee]

For simplicity, I think it would be easiest to say the change license kicks in two years after the initial public release date of the Software.

The Software would be the version number of the software released under the license. It would include all code associated with that particular version.

The next version would be "new" Software and the change license counting would start anew for that version from its initial release date.

I worry that if we don't tie this to a version number and release date it becomes very difficult for users of the Software to know when their rights kick in under the change license without a lot of additional effort (i.e., having to look through all PRs and merges).

[ljharb]

I mean, a released version would presumably match a commit, and anything included in that commit would become available at the latest 2 years after that commit date, so that seems fine - it's ok if some parts of the software are available sooner.

[gavin-zee]

Single, earlier change date = better for the licensee

Individual change date for each commit = better for the licensor, but wouldn't any truly substantive commits (i.e., introducing new features or functionality) be under a new version anyways?

I don't have a philosophical attachment either way - I just want to make sure the license is clear on its face in plain English

[chadwhitacre]

Drafting session (final?) scheduled for Monday at 11am US/Pacific. @ljharb et al. lmk if you would like to join.

[ezekg]

Chiming in here on request from @chadwhitacre. I've been following along the conversation here. I have a bit of a different perspective, since I'm currently using ELv2 and not BUSL (though I did consider it).

I really do like the idea of the FSL, especially the time-released aspect borrowed from BUSL, but ultimately, it fails to offer a key protection that ELv2 provides my business: preventing somebody from removing license gates from an open-core code base. A "license gate" being a part of the code base that is protected by a license key, for example, a set of enterprise features. To give context, unlike Sentry, Keygen does monetize the self-hosted edition of Keygen via an enterprise edition called Keygen EE. This is in addition to Keygen CE, the free community edition, and the managed Keygen Cloud offering. Risking the monetization of Keygen EE would undermine my original motivation for open sourcing Keygen: to increase enterprise adoption.

To give a bit more context — Keygen's code base is a monorepo, and it is not dual-licensed. The entire code base is licensed under ELv2. And Keygen Cloud, Keygen EE, and Keygen CE are all the same code base (Keygen Cloud is actually an instance of Keygen EE, licensed by Keygen itself). Since Keygen was previously closed source, I didn't want to split the repo up into the ee/ directory structure that you commonly see in other open core projects. Although that would solve my dilemma here, by separately licensing that ee/ directory, I deemed doing so as too risky; too much code churn for little benefit. In my case, the enterprise features are spread throughout the code base, gated with a license key check.

Instead, I opted for ELv2 because it offered me the ability to say, "hey, I'm making this open source, do what you want with it, just don't compete with me or remove the license gates for the paid features." (I originally pondered BUSL as well, with an additional use grant to cover those protections, but found ELv2 was simpler and less ambiguous, so I ultimately went with ELv2.)

Right now, FSL can't help me with that latter protection, which is very important to me since I am monetizing the self-hosted edition of Keygen via the enterprise edition. I would hate for somebody to fork Keygen, strip the license gates, and then leave money on the table there i.r.t. potential customers of Keygen EE using the "free" fork instead.

tl;dr: Much like ELv2, FSL provides protection from cloud competition, but unlike ELv2, FSL does not provide protection from self-hosted "competition" (via a fork and stripping away license gates).

[chadwhitacre]

Thanks @ezekg. I was talking to another COSS founder recently and self-hosting is like 80% of their revenue, so you're not the only one. For better or worse, FSL as written is for companies like Sentry that don't monetize self-hosting. My gut is we shouldn't try too hard to expand the aim of FSL, but rather ship it as an incremental improvement to BSL, and follow up in the coming months/years with wider movement-building (#2) that encompasses multiple approaches (parallel to SUL / Fair-code but with more investment ;-).

[ljharb]

@chadwhitacre i'd love to, but i have a conflicting meeting that hour.

[chadwhitacre]

the date stamping of the LICENSE file is quite tedious difficult for users of the Software to know when their rights kick in under the change license without a lot of additional effort (i.e., having to look through all PRs and merges).

If we don't put a date in the license file itself, then we need some level of effort to discover the start date. We trade off licensor effort for licensee effort, in other words. Can we talk about "publication" to keep it generic (could be published as a commit on GitHub, as a package on npm/pypi, as a tarball on Sourceforge, etc.)?

The Software The Software is the version of a software product published under these Terms and Conditions, as indicated by our inclusion of these Terms and Conditions together with the Software.

Change License On the second anniversary of the initial publication date of the Software, the Software will become available under the Apache 2.0 license.

[chadwhitacre]

Okay! @gavin-zee @heathermeeker and I had our call, we've got a version of the license that we are ready to present as our final draft. I've convert it to markdown and put it back up on the site. Speak now or forever hold your peace!

[chadwhitacre]

If we want/need more than one change license then here are a few somewhat rational sets of licenses to allow:

I talked this through with @gavin-zee ... copyleft doesn't fit our values so those are out. BSD and ISC don't really offer anything over MIT, so based on that it seems like Apache 2.0 + MIT will cover like 99%+ of the community we're aiming for. I'm going to add a FAQ to this effect.

[hmeeker]

MIT and Apache 2.0 cover the bases for permissive.

[chadwhitacre]

Last call for input on the FSL draft. We're two days out from our announcement event (#7), it's time to promote DRAFT to 1.0 and relicense Sentry and Codecov. 💃

[chadwhitacre]

Closed with #12!

Relicensing Sentry and Codecov on https://github.com/getsentry/team-ospo/issues/212 ahead of #7 tomorrow.