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.