If they're going to all this trouble for "ambiguity," I don't know why they wouldn't further extend their custom SPDX identifier to include the "2 year" rollover, since that's one of their pearl-clutching reasons for this bullshit: https://github.com/getsentry/loose-confederation/issues/4
FSL has less ambiguity when compared to BUSL. Each use of BUSL is essentially its own unique license due to the variable Additional Use Grant. For example, a company could not pre-approve BUSL as an acceptable license for the company, because all BUSL licenses will have a different Acceptable Use Grant. On the contrary, FSL is a new license that can be pre-approved since it has no variables. It's an improvement upon BUSL. I personally like it, although I won't be moving from ELv2 to FSL due to another reason [0].
I feel the article is pretty clear that it is attempting to
improve the BUSL.
1) It’s a license without any variable substitution (as the BUSL has).
2) It also has a firm change date to Apache 2.0 or MIT after 2 years (the BUSL default is 4, but this is also variable).
The BUSL has seen significant adoption but has a host of problems outlined in the article. But if you believe software should be an OSI-approved-license-or-nothing, this may not interest you.
Equating "Here's the full source code and you can do more or less what you want with it, except this one specific thing because it would really harm the future development of this software" with "proprietary" (that is, "no access to the source code at all") is just silly and ridiculous.
dang, I know you're busy with the OpenAI news melting things, but can we get the title of this post to be uneditorialized? This is about the new FSL license, not just about Sentry relicensing under FSL. The actual title is "Introducing the Functional Source License: Freedom without Free-riding."
I always thought 4 years was very generous. I don't think there are many pieces of software I could persuade my boss to pay for if the alternative was using a free 4 year old version. At 2 years there's no chance. Most software we use is 2 years old without even trying.
Your boss apparently doesn't really care about security posture... which is a shame. Most software that's 2 years old, much less 4 years old, is missing numerous security patches introduced in more recent versions. But I guess you could be in an industry that doesn't run up-to-date software? Typically, 2-4 years is EOL.
The source code to the fixed versions is still available in those cases, and there's essentially no chance that even verbatim copies of the patches for most security fixes would pass the threshold of creativity to be copyrightable. Worst case scenario, you have to work with another person to have them study the fixes that upstream publishes and then explain the vulnerability to you so you can write a fix of your own.
So essentially you pay your engineers to maintain a fork, so you can use the software for "free." Then the question of "build vs buy" eventually arises, because maintaining a fork is a costly maintenance burden, and is essentially the "build" side of that question. Seems like the license would be working as intended then. ;)
Besides, this assumes you're creating a competing work. Most use cases of FSL can self-host the latest code. That's the whole point.
For something like Sentry that's typically not a huge problem.
Only the "receive errors from application" endpoints needs to be public; everything else can be gated behind a VPN or HTTP password or whatever. While it's certainly true that such an endpoint can have security problems, it's a pretty small surface area.
Besides, what kind of interesting stuff is there in Sentry? When configured correctly, probably not too much, depending on what type of app you're using it with.
TBH Sentry versions starting from 10 is kinda messy from infrastructure perspective. Sometimes it looks like artificially crafted to be complex to install and operate as a single node to serve like max 100k events/day.
It's definitely not intentional that self hosted is hard to run, and it's also a concern for us internally. The hard truth is that the scale at which Sentry's largest SaaS installation operates we need to make decisions which are unfortunate for smaller setups. However we're very aware of this challenge. It does not just show up for self hosted, it also complicates the development environments etc. It's not something that is done to harm people who want to self host, it's the consequence of our struggler of balancing the scale we have.
Thank you for insights. I know how hard it could be to design pluggable backends to fulfill different scaling requirements. Local development hurdles are a real chore, good luck with taming the beast!
There have been a few cases where other businesses have taken Sentry code to directly compete with Sentry.io (the SaaS business).
For example, at one point somebody operated sentry.otherdomain, reselling the service commercially as-is. In another case, a larger, better-capitalized software vendor explored bundling Sentry as part of a broader tools offering.
These efforts undermine the project because they did not contribute back to the project, either monetarily or with code contributions. Whereas when Sentry monetizes the work, the revenue earned pays the software developers who maintain and improve the work.
FWIW it is simpler because BUSL source can change to any license (including copyleft), whereas FSL can only change into MIT or Apache 2.0. So it goes from N possibilities to 2.
> Is there any functional difference between apache and MIT?
Apache 2.0 has an explicit patents clause, whereas MIT does not.
> Is there any functional difference between apache and MIT?
We only use FSL to Apache 2 so we would have been happy with just having this. However the issue of lack of GPL 2 compatibility of Apache 2 is known to us so having a GPL 2 compatible option with the MIT license we believe makes sense. In practical terms if you want to adopt FSL from scratch and you have no GPL 2 concerns, Apache 2 is most likely the better choice as it also carries a patent clause.
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/) 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-Relicens.... That's still a work in progress, but pretty close to presentable.
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.
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/ has already put a few into the field. Some are proving more popular than others.
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.
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.
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?
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.
Let's say a piece of software licensed like this becomes popular and is non-trivial to replicate.
At some point, a significant enough portion will be two years old and changed to the escrowed license. A fully open source fork will become tempting for pragmatic and ideological reasons.
If forked, what are the odds the copyright holder will re-license their source code for the sake of control & profit?
Every semi-open license/core tactic is just a rug-pull waiting to happen.
I’m not a lawyer, but AFAIK, they can’t relicense any permissive versions that are already out there.
They could choose to relicense future versions (i.e. they could stop future versions from becoming permissive, after 2 years). And if they did that, future changes wouldn’t propagate down (but it’d take 2 years to feel it).
> Every semi-open license/core tactic is just a rug-pull waiting to happen.
Note that everything you’re concerned about can also occur with permissive licensed OSS.
You're right that Apache 2.0 is irrevocable. But MIT isn't.
An open source project that starts to "scratch an itch" is far less likely to revoke a license than one that is motivated by money.
Motivation aside, if it's a non-trivial organic project, they've likely taken many patches from others and effectively cannot revoke the license of the code base.
But I shouldn't say "motivation aside" as motivation is the point when it comes to trust.
Can you actually revoke it in practice? I’m not deeply familiar with MIT (and personally always opt for Apache as it’s more well understood), but I didn’t think that was possible.
I believe you’re suggesting revocation means something else. Once the software is released under a license you’ve created a legal contract granting those terms. You can’t (at least in the referenced licenses) rewind and take away the license grant.
Sure you can fork it and license new code in a different way, but that’s not the same thing.
> Once the software is released under a license you’ve created a legal contract granting those terms.
I’m not a lawyer but I’ve followed the “is it a license or is it a contract” thing for 25 years now. One important part of the confusion here is that a contract requires mutual consideration; unilateral “contracts” aren’t contracts at all. The long-term argument is that the source code is subject to copyright which implicitly would not allow distribution; the license is what grants additional permissions on top of what copyright does and doesn’t allow, and thus probably could be revoked.
We as an industry and community have settled on the irrevocably of Open Source licenses. I doubt that any court would rule against this notion today. Too much would be at stake.
Makes it seem like it would be a legal grey zone in the US. And a reminder, not all of us are American and the ambiguity might be even less favourable in other jurisdictions.
I generally advise developers, and believe most of my US colleagues also advise developers, to treat past releases under MIT and BSD terms as irrevocable, even though they don't explicitly say they are. But that conclusion comes as much from practicalities as legalities.
If the MIT license lets people make and share copies willy-nilly, online and off, how do you go about notifying every potential recipient that you've taken that license back? Even if you send a notice to just one user you want to block, who wants to see that on the Internet within hours? Who wants to be the company potentially arguing in court to undermine the reliability of MIT license grants generally?
On the legal side, sketching very roughly: The general rule seems to be that non-exclusive licenses without terms remain revocable by default. But in what circumstances won't a court find a contract or quasi-contract, applying those rules instead?
So much better to get ahead of all this head scratching by saying in the terms that those giving can't take them back. Alas, literally nobody's got commit bit on what we call "MIT", "BSD", &c. anymore. But we made very sure to do it the Blue Oak Model License: https://blueoakcouncil.org/license/1.0.0#reliability Other, more recent forms, notably Apache 2.0, say it, as well.
If you're reading this and thinking about a particular bit of software, don't rely on what I've written here. Talk through it with a lawyer who's up to speed on the latest, will ask you for specifics, and will stand professionally responsible for their guidance. I won't.
The license for that version is irrevocable. It doesn’t mean I couldn’t publish a newer version with a different license, if I am the copyright holder. The existence of a newer version with a different license does not revoke your ability to use, modify, etc. the prior-released version. That’s what irrevocable means here, AFAIK.
MIT certainly doesn't say it can't be revoked. But do you really think it's inherently revocable at will, in all or even many practical circumstances?
From the US law perspective, I understand that some courts have decided that non-exclusive licenses without stated terms can be revoked at any time. But I wonder about situations when a court looking at a permissive grant for open software wouldn't also bring contract and quasi-contract concepts to bear. There's clearly an expectation of reliance, MIT and BSD themselves contain contract-type disclaimers and exclusions, and what a licensor might get in return doesn't have to be money.
If I had to bet, I'd bet on it not being revocable.
Betting a mere $20 on a case currently in court could be fun.
But my time is worth a lot more than that. So if I'm thinking about starting a viable open source fork off this thing, I'm effectively betting a lot more.
That kind of begs the question, who am I betting against? I'm suggesting on the other end is an entity that chose a licence that attempts to minimize competition. Please, re-read the last sentence as I can't stress it enough. What happens if that competition-adverse entity's business model is existentially threatened by my fork?
Maybe they're willing to try their luck and try the MIT license in court.
Whether or not I'd win doesn't matter to me. A long lawsuit is going to be expensive either way. The question I'd pose is if the case would be quickly dismissed?
I'm not a lawyer, I have no way of answering that. But I've donated money to more than one programmer's legal fund against an absurd case that was clearly meant to just kill the project [0]. I don't want to be that programmer. I'd rather work on something else.
Which gets to the actual point I've been trying to make all along. I personally wouldn't want to fork this, and I suspect a percentage of the open source community feels the same way. And forking is one of the most important aspects of open source.
[0] https://lwn.net/Articles/181261/ - The programmer actually emailed me back with a thank you note, expressing some surprise that a non-American would care about a legal system they were not subject to.
The main issue of such a license is that you can't fork the project when they go in a direction that you don't like.
Also, we can now say that Sentry is a proprietary software with open Sources but clearly not a free software anymore.
They are free to do whatever they want, but in my opinion it is an "asshole" move to say that you do a license to fight "free-riding" when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django.
Sentry wouldn't even exist without free-riding.
Btw, something strange with their license is that it means that no one else can contribute to the project except if there is a kind of cla.
Let's suppose that I fork the FSL version and add some patches. They are interesting. Now Sentry would not be able to integrate these changes into their version because the "with us" regarding the competition would not be the same person.
Same thing with contributions to the the apache 2 license code that can't make it inside the code of a later version that would be released as FSL.
Also, I don't want that to happen, but a bad faith actor could probably also poison their code:
- you look what would probably be needed for next development, a bug fix, a bug issue or change requested. You implement that in the best, obvious or multiple ways in your own fork.
Then, they would not be able to use that in their code without infringement on your copyright and ie having not to compete with you.
That is more a question about CLAs but licenses. The Python project for instance requires a CLA that gives the PSF the freedom to relicense more liberally than the current license. They would not accept or upstream code from a fork without that paperwork.
The implications of not having a CLA for a spring license like the FSL are a bit unexplored. I have an idea in my head how that would play out but who knows.
> Also, I don't want that to happen, but a bad faith actor could probably also poison their code
I recognize this is a thought experiment, but my mental model of the legal system is that it's not "code is law," it's "the golden rule: he who has the gold, makes the rules." So, how I expect this would actually play out is that any such bad actor would do bad actor things, and then the changes would be implemented by someone with a sentry.io email in some nuanced way, we'd see a news article about some lawyering, and the bad actor would be impoverished by lawyer bills
> Also, we can now say that Sentry is a proprietary software
The article explains that Sentry was licensed under a non-OSI license (the BUSL) for the last 4+ years. That license had more onerous terms than what it uses today. So if you believe this news means it has become proprietary today, you're ~4 years behind.
> when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django. Sentry wouldn't even exist without free-riding.
Sentry has donated tens of thousands of dollars - probably over $100k over the years - to the PSF and Django. It is currently an acknowledged active sponsor of both [1,2].
This year alone Sentry gave $500,000 to open source foundations and maintainers [3].
Sentry itself was built as a Django ecosystem project, and anyone can use it according to the license terms (e.g. stand up a server and collect errors for their non-competing projects). And many organizations do that today.
Sentry (the company) additionally contributes many permissive OSS projects, like popular utility libraries and key parts of the Sentry project itself (e.g. getsentry/responses or the SDKs).
The issue is when competing entities take the source, produce purely commercial offerings with no upstream contributions / the source they produce is 100% closed. That’s free-riding.
> The main issue of such a license is that you can't fork the project when they go in a direction that you don't like.
As long as it's not a Competing Use, yes, you can [0]. I don't get why so many people think you can't fork a project that uses BUSL, SSPL, ELv2, and now FSL. Just like any other OSS licenses, you can fork. And you just like any other OSS fork, you can't relicense.
It's obvious people don't actually read the license.
Did you actually look at the license, or any of the history of Sentry?
It’s still just as “free” as it has been for years. If anything this makes our commitment to open source _more_ explicit than it was under the BUSL.
On your free-riding point, just because we leverage open source doesn’t mean our software must be as free and open as possible. We use Linux - should it mean everything we build must be Foss? It’s ok if you have a religion about this but thats simply not practical in all software.
Additionally many of us have and continue to give ample time and money to the ecosystem we rely on. I doubt anyone in the Python or Django communities would claim we’re free riders.
When we say free riding we mean other companies. We mean folks who don’t participate in the community and simply want to take work for their own gain while giving nothing back. The industry is not sustainable if that becomes the norm.
55 comments
[ 0.25 ms ] story [ 104 ms ] threadIf they're going to all this trouble for "ambiguity," I don't know why they wouldn't further extend their custom SPDX identifier to include the "2 year" rollover, since that's one of their pearl-clutching reasons for this bullshit: https://github.com/getsentry/loose-confederation/issues/4
> I don't know why they wouldn't further extend their custom SPDX identifier to include the "2 year" rollover
Unlike the target license of which there are two to chose from, the two years are not variables in the license.
[0]: https://github.com/getsentry/loose-confederation/issues/4#is...
1) It’s a license without any variable substitution (as the BUSL has).
2) It also has a firm change date to Apache 2.0 or MIT after 2 years (the BUSL default is 4, but this is also variable).
The BUSL has seen significant adoption but has a host of problems outlined in the article. But if you believe software should be an OSI-approved-license-or-nothing, this may not interest you.
Besides, this assumes you're creating a competing work. Most use cases of FSL can self-host the latest code. That's the whole point.
Only the "receive errors from application" endpoints needs to be public; everything else can be gated behind a VPN or HTTP password or whatever. While it's certainly true that such an endpoint can have security problems, it's a pretty small surface area.
Besides, what kind of interesting stuff is there in Sentry? When configured correctly, probably not too much, depending on what type of app you're using it with.
What you can’t do is leverage that source to compete against its authors, e.g. launch a competing monitoring service. (Please consult the license.)
For example, at one point somebody operated sentry.otherdomain, reselling the service commercially as-is. In another case, a larger, better-capitalized software vendor explored bundling Sentry as part of a broader tools offering.
These efforts undermine the project because they did not contribute back to the project, either monetarily or with code contributions. Whereas when Sentry monetizes the work, the revenue earned pays the software developers who maintain and improve the work.
Is there any functional difference between apache and MIT?
> Is there any functional difference between apache and MIT?
Apache 2.0 has an explicit patents clause, whereas MIT does not.
Better explanation here: https://opensource.com/article/18/2/apache-2-patent-license
We only use FSL to Apache 2 so we would have been happy with just having this. However the issue of lack of GPL 2 compatibility of Apache 2 is known to us so having a GPL 2 compatible option with the MIT license we believe makes sense. In practical terms if you want to adopt FSL from scratch and you have no GPL 2 concerns, Apache 2 is most likely the better choice as it also carries a patent clause.
I've been working with colleagues to publish reusable restricted licenses through PolyForm Project (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-Relicens.... That's still a work in progress, but pretty close to presentable.
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/ has already put a few into the field. Some are proving more popular than others.
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.
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.
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?
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.
At some point, a significant enough portion will be two years old and changed to the escrowed license. A fully open source fork will become tempting for pragmatic and ideological reasons.
If forked, what are the odds the copyright holder will re-license their source code for the sake of control & profit?
Every semi-open license/core tactic is just a rug-pull waiting to happen.
They could choose to relicense future versions (i.e. they could stop future versions from becoming permissive, after 2 years). And if they did that, future changes wouldn’t propagate down (but it’d take 2 years to feel it).
> Every semi-open license/core tactic is just a rug-pull waiting to happen.
Note that everything you’re concerned about can also occur with permissive licensed OSS.
An open source project that starts to "scratch an itch" is far less likely to revoke a license than one that is motivated by money.
Motivation aside, if it's a non-trivial organic project, they've likely taken many patches from others and effectively cannot revoke the license of the code base.
But I shouldn't say "motivation aside" as motivation is the point when it comes to trust.
The trick is that you don't need to threaten everybody, just any fork that gains traction and might be a viable open source project.
Otherwise stated, you don't go after every user, just the competition.
Sure you can fork it and license new code in a different way, but that’s not the same thing.
I’m not a lawyer but I’ve followed the “is it a license or is it a contract” thing for 25 years now. One important part of the confusion here is that a contract requires mutual consideration; unilateral “contracts” aren’t contracts at all. The long-term argument is that the source code is subject to copyright which implicitly would not allow distribution; the license is what grants additional permissions on top of what copyright does and doesn’t allow, and thus probably could be revoked.
Makes it seem like it would be a legal grey zone in the US. And a reminder, not all of us are American and the ambiguity might be even less favourable in other jurisdictions.
I generally advise developers, and believe most of my US colleagues also advise developers, to treat past releases under MIT and BSD terms as irrevocable, even though they don't explicitly say they are. But that conclusion comes as much from practicalities as legalities.
If the MIT license lets people make and share copies willy-nilly, online and off, how do you go about notifying every potential recipient that you've taken that license back? Even if you send a notice to just one user you want to block, who wants to see that on the Internet within hours? Who wants to be the company potentially arguing in court to undermine the reliability of MIT license grants generally?
On the legal side, sketching very roughly: The general rule seems to be that non-exclusive licenses without terms remain revocable by default. But in what circumstances won't a court find a contract or quasi-contract, applying those rules instead?
So much better to get ahead of all this head scratching by saying in the terms that those giving can't take them back. Alas, literally nobody's got commit bit on what we call "MIT", "BSD", &c. anymore. But we made very sure to do it the Blue Oak Model License: https://blueoakcouncil.org/license/1.0.0#reliability Other, more recent forms, notably Apache 2.0, say it, as well.
If you're reading this and thinking about a particular bit of software, don't rely on what I've written here. Talk through it with a lawyer who's up to speed on the latest, will ask you for specifics, and will stand professionally responsible for their guidance. I won't.
From the US law perspective, I understand that some courts have decided that non-exclusive licenses without stated terms can be revoked at any time. But I wonder about situations when a court looking at a permissive grant for open software wouldn't also bring contract and quasi-contract concepts to bear. There's clearly an expectation of reliance, MIT and BSD themselves contain contract-type disclaimers and exclusions, and what a licensor might get in return doesn't have to be money.
Betting a mere $20 on a case currently in court could be fun.
But my time is worth a lot more than that. So if I'm thinking about starting a viable open source fork off this thing, I'm effectively betting a lot more.
That kind of begs the question, who am I betting against? I'm suggesting on the other end is an entity that chose a licence that attempts to minimize competition. Please, re-read the last sentence as I can't stress it enough. What happens if that competition-adverse entity's business model is existentially threatened by my fork?
Maybe they're willing to try their luck and try the MIT license in court.
Whether or not I'd win doesn't matter to me. A long lawsuit is going to be expensive either way. The question I'd pose is if the case would be quickly dismissed?
I'm not a lawyer, I have no way of answering that. But I've donated money to more than one programmer's legal fund against an absurd case that was clearly meant to just kill the project [0]. I don't want to be that programmer. I'd rather work on something else.
Which gets to the actual point I've been trying to make all along. I personally wouldn't want to fork this, and I suspect a percentage of the open source community feels the same way. And forking is one of the most important aspects of open source.
[0] https://lwn.net/Articles/181261/ - The programmer actually emailed me back with a thank you note, expressing some surprise that a non-American would care about a legal system they were not subject to.
I believe that's only true with CLA, which is something I have started to check for in any new "Show HN" announcements
Also, we can now say that Sentry is a proprietary software with open Sources but clearly not a free software anymore.
They are free to do whatever they want, but in my opinion it is an "asshole" move to say that you do a license to fight "free-riding" when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django. Sentry wouldn't even exist without free-riding.
You absolutely can. You can even start a competing company after two years.
Let's suppose that I fork the FSL version and add some patches. They are interesting. Now Sentry would not be able to integrate these changes into their version because the "with us" regarding the competition would not be the same person.
Same thing with contributions to the the apache 2 license code that can't make it inside the code of a later version that would be released as FSL.
Also, I don't want that to happen, but a bad faith actor could probably also poison their code: - you look what would probably be needed for next development, a bug fix, a bug issue or change requested. You implement that in the best, obvious or multiple ways in your own fork.
Then, they would not be able to use that in their code without infringement on your copyright and ie having not to compete with you.
The implications of not having a CLA for a spring license like the FSL are a bit unexplored. I have an idea in my head how that would play out but who knows.
I recognize this is a thought experiment, but my mental model of the legal system is that it's not "code is law," it's "the golden rule: he who has the gold, makes the rules." So, how I expect this would actually play out is that any such bad actor would do bad actor things, and then the changes would be implemented by someone with a sentry.io email in some nuanced way, we'd see a news article about some lawyering, and the bad actor would be impoverished by lawyer bills
The article explains that Sentry was licensed under a non-OSI license (the BUSL) for the last 4+ years. That license had more onerous terms than what it uses today. So if you believe this news means it has become proprietary today, you're ~4 years behind.
> when you are standing on the shoulders of free software components like Python or somehow python frameworks like Django. Sentry wouldn't even exist without free-riding.
Sentry has donated tens of thousands of dollars - probably over $100k over the years - to the PSF and Django. It is currently an acknowledged active sponsor of both [1,2].
This year alone Sentry gave $500,000 to open source foundations and maintainers [3].
Sentry itself was built as a Django ecosystem project, and anyone can use it according to the license terms (e.g. stand up a server and collect errors for their non-competing projects). And many organizations do that today.
Sentry (the company) additionally contributes many permissive OSS projects, like popular utility libraries and key parts of the Sentry project itself (e.g. getsentry/responses or the SDKs).
The issue is when competing entities take the source, produce purely commercial offerings with no upstream contributions / the source they produce is 100% closed. That’s free-riding.
[1] https://www.python.org/psf/sponsors/
[2] https://www.djangoproject.com/foundation/corporate-members/
[3] https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-...
As long as it's not a Competing Use, yes, you can [0]. I don't get why so many people think you can't fork a project that uses BUSL, SSPL, ELv2, and now FSL. Just like any other OSS licenses, you can fork. And you just like any other OSS fork, you can't relicense.
It's obvious people don't actually read the license.
[0]: https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-...
It’s still just as “free” as it has been for years. If anything this makes our commitment to open source _more_ explicit than it was under the BUSL.
On your free-riding point, just because we leverage open source doesn’t mean our software must be as free and open as possible. We use Linux - should it mean everything we build must be Foss? It’s ok if you have a religion about this but thats simply not practical in all software.
Additionally many of us have and continue to give ample time and money to the ecosystem we rely on. I doubt anyone in the Python or Django communities would claim we’re free riders.
When we say free riding we mean other companies. We mean folks who don’t participate in the community and simply want to take work for their own gain while giving nothing back. The industry is not sustainable if that becomes the norm.