4 ms·

They do not seem to have learned the hard lessons of Familiar License + New Patch from Commons Clause. There are good reasons to expect they'll experience simil

They do not seem to have learned the hard lessons of Familiar License + New Patch from Commons Clause. There are good reasons to expect they'll experience similar confusion and hesitation. I've been working with colleagues to publish reusable restricted licenses through PolyForm Project (https://polyformproject.org/ https://polyformproject.org/) for a few years now. I'd like to publish a form for scheduled relicensing through them as well, and blogged about it here: https://writing.kemitchell.com/2023/10/24/Scheduled-Relicensing https://writing.kemitchell.com/2023/10/24/Scheduled-Relicens.... That's still a work in progress, but pretty close to presentable.

bentlegen 3y ago
Your blog post seems to focus on the “bolted on” aspects of the BUSL in negative terms, so I’m curious why this license (FSL), which removes the ability to add custom terms, would serve to cause more confusion.
- kemitchell 3y ago
  My blog post bemoans coupling terms for license change to terms for the initial license, effective on release. BUSL does both license change and an initial, "non-production" license, all in one form. This new FSL does license change and a PolyForm Shield-esque "don't use to compete with us" license, all in one form. The more choices the forms make and bundle together as a package, the more likely we are to see yet another announcement of a new form with some other predictable, but as yet unbranded, combination. It's not about minimizing blanks to fill out. It's about maximizing what terms licensors can share and reuse, and what "brands" for those terms they can promote and popularize. It's pretty clear what the questions are for scheduled relicensing: "what new terms?" and "when?" And it's a relatively small legal job to write terms that just schedule a new license to kick in, with blanks for the answers. I don't see why we'd want to "hard-code" those values, given how much licensors' choices have varied. The original users of scheduled relicensing, and most recently Hashi, chose copyleft licenses, not MIT or Apache 2. Of the recent crop of companies announcing scheduled relicensing, I think Sentry's the first I've seen that chose two years. There is also a lot of variation in what terms developers want to apply from initial release, but a lot of it has been independent reinvention on recurring themes. If we popularize a named form just for scheduling relicensing, projects can put those terms in `FUTURE-LICENSE` or somesuch and whatever license terms they want for day one in `LICENSE`. Then we can focus on developing a recognizable set of restricted-license choices that serve most developers in these situations, for maximum reuse. The "menu" of PolyForm licenses https://polyformproject.org/licenses/ https://polyformproject.org/licenses/ has already put a few into the field. Some are proving more popular than others.
  - zeeg 3y ago
    We are not trying to build a license with infinite options to fill out - it’s my opinion that will never lead to adoption. It’s intentional the choices we made and we see Sentry leading the way here. Theres a reason we’re forceful on it being permissive. Theres a reason we chose two years over four. These choices make the ecosystem better. We don’t want a repeat of the complexity that is BUSL and that’s exactly why we shipped a static license. Theres quite a lot of companies who will happily follow a role model, and in the past some of them have chosen BUSL entirely because Sentry leverages it. We hope to inspire people to adopt a better license - better for adoption, better for developers - and help that next generation of companies by giving them more sane defaults. These defaults mean more free software. They mean easier adoption within legal departments. They mean less fuzzy use grants (albeit only for SaaS in our case). These are all net improvements if your business looks like Sentry, and a lot of companies do.
    - kemitchell 3y ago
      I don't doubt your conviction. It's easy enough to stand up a website, but naming things and yet another public license change ain't nothing. I've guided companies to decisions on all these licensing choices. Decisions differed, and reasons did, too. Every choice to delayed-relicense open meant more open software and made the ecosystem better, insofar as more code means better. Everyone thought their choices were right---for them. There's definitely value in painting the shed red and calling that a standard, but there's no one in any position to enforce adherence. The thought I'd leave you with is that if you're worried about adoption under your restricted terms, and not just the eventual open ones, I think you could get a lot more projects reusing a "don't compete with us" license uncoupled from permissive relicensing on an aggressively short interval. "Licensed under Foundation Source v2, releases become MIT after 2 years" isn't any harder to mimic, for companies you suspect will just follow your lead. And then anyone adopting just FSLv2, or "FSLv2, releases become MPLv2 after 4 years" (Hashi?), or some other combination, could also be bouncing around through the industry, bumping into coders and legal departments, informing them one at a time that FSL exists and might be worth green-lighting. I wish you and yours the best. I'd never say this is bad, and I haven't. But I've been at this a while, and I do suspect it could be better.
zeeg 3y ago
I’m not sure what you mean? We’ve been using the BUSL for years successfully. This is just an improvement (for customers) on that license. Are you suggesting our successful business is going to all of a sudden fail now because we made the BUSL easier to understand and more clear in our goals around it?
- kemitchell 3y ago
  You can write the rules for your software in whatever license terms you like, and I stand for your right to do so. My concern is whether you and other companies in your position will have good, reusable options for implementing the rules you need in ways potential users will understand. Maybe your goal with the new "Functional" brand, rather than a new "Sentry License", was just to communicate that you'd welcome follow-on by other companies who happen to make all the same license choices you did, and are willing to put that under a neutral brand, rather than your own. But I strongly suspect you'd get more reuse and stronger branding for your approach, in the long term, by remembering how much confusion and controversy conjoined naming like "MIT + Commons Clause" and "Apache2 + Commons Clause" caused. I know and deeply respect a number of people involved in that presentational choice. I think they made for apparently good reasons, to give everyone who came together around the project a way to adopt without dropping the brands of their current open licenses. I also think it's safe to say it backfired.

bentlegen 3y ago

Your blog post seems to focus on the “bolted on” aspects of the BUSL in negative terms, so I’m curious why this license (FSL), which removes the ability to add custom terms, would serve to cause more confusion.

kemitchell 3y ago
My blog post bemoans coupling terms for license change to terms for the initial license, effective on release. BUSL does both license change and an initial, "non-production" license, all in one form. This new FSL does license change and a PolyForm Shield-esque "don't use to compete with us" license, all in one form. The more choices the forms make and bundle together as a package, the more likely we are to see yet another announcement of a new form with some other predictable, but as yet unbranded, combination. It's not about minimizing blanks to fill out. It's about maximizing what terms licensors can share and reuse, and what "brands" for those terms they can promote and popularize. It's pretty clear what the questions are for scheduled relicensing: "what new terms?" and "when?" And it's a relatively small legal job to write terms that just schedule a new license to kick in, with blanks for the answers. I don't see why we'd want to "hard-code" those values, given how much licensors' choices have varied. The original users of scheduled relicensing, and most recently Hashi, chose copyleft licenses, not MIT or Apache 2. Of the recent crop of companies announcing scheduled relicensing, I think Sentry's the first I've seen that chose two years. There is also a lot of variation in what terms developers want to apply from initial release, but a lot of it has been independent reinvention on recurring themes. If we popularize a named form just for scheduling relicensing, projects can put those terms in `FUTURE-LICENSE` or somesuch and whatever license terms they want for day one in `LICENSE`. Then we can focus on developing a recognizable set of restricted-license choices that serve most developers in these situations, for maximum reuse. The "menu" of PolyForm licenses https://polyformproject.org/licenses/ https://polyformproject.org/licenses/ has already put a few into the field. Some are proving more popular than others.
- zeeg 3y ago
  We are not trying to build a license with infinite options to fill out - it’s my opinion that will never lead to adoption. It’s intentional the choices we made and we see Sentry leading the way here. Theres a reason we’re forceful on it being permissive. Theres a reason we chose two years over four. These choices make the ecosystem better. We don’t want a repeat of the complexity that is BUSL and that’s exactly why we shipped a static license. Theres quite a lot of companies who will happily follow a role model, and in the past some of them have chosen BUSL entirely because Sentry leverages it. We hope to inspire people to adopt a better license - better for adoption, better for developers - and help that next generation of companies by giving them more sane defaults. These defaults mean more free software. They mean easier adoption within legal departments. They mean less fuzzy use grants (albeit only for SaaS in our case). These are all net improvements if your business looks like Sentry, and a lot of companies do.
  - kemitchell 3y ago
    I don't doubt your conviction. It's easy enough to stand up a website, but naming things and yet another public license change ain't nothing. I've guided companies to decisions on all these licensing choices. Decisions differed, and reasons did, too. Every choice to delayed-relicense open meant more open software and made the ecosystem better, insofar as more code means better. Everyone thought their choices were right---for them. There's definitely value in painting the shed red and calling that a standard, but there's no one in any position to enforce adherence. The thought I'd leave you with is that if you're worried about adoption under your restricted terms, and not just the eventual open ones, I think you could get a lot more projects reusing a "don't compete with us" license uncoupled from permissive relicensing on an aggressively short interval. "Licensed under Foundation Source v2, releases become MIT after 2 years" isn't any harder to mimic, for companies you suspect will just follow your lead. And then anyone adopting just FSLv2, or "FSLv2, releases become MPLv2 after 4 years" (Hashi?), or some other combination, could also be bouncing around through the industry, bumping into coders and legal departments, informing them one at a time that FSL exists and might be worth green-lighting. I wish you and yours the best. I'd never say this is bad, and I haven't. But I've been at this a while, and I do suspect it could be better.

zeeg 3y ago

I’m not sure what you mean? We’ve been using the BUSL for years successfully. This is just an improvement (for customers) on that license. Are you suggesting our successful business is going to all of a sudden fail now because we made the BUSL easier to understand and more clear in our goals around it?

kemitchell 3y ago
You can write the rules for your software in whatever license terms you like, and I stand for your right to do so. My concern is whether you and other companies in your position will have good, reusable options for implementing the rules you need in ways potential users will understand. Maybe your goal with the new "Functional" brand, rather than a new "Sentry License", was just to communicate that you'd welcome follow-on by other companies who happen to make all the same license choices you did, and are willing to put that under a neutral brand, rather than your own. But I strongly suspect you'd get more reuse and stronger branding for your approach, in the long term, by remembering how much confusion and controversy conjoined naming like "MIT + Commons Clause" and "Apache2 + Commons Clause" caused. I know and deeply respect a number of people involved in that presentational choice. I think they made for apparently good reasons, to give everyone who came together around the project a way to adopt without dropping the brands of their current open licenses. I also think it's safe to say it backfired.