Sentry is now Fair Source
blog.sentry.io
blog.sentry.io
Maybe it's because it's new, but the website doesn't offer a ton of insight into how "Fair Source" is different from other attempts to re-brand proprietary software as pseudo-open-source. For example, the FSS definition on the home page mentions "minimal restrictions," but I can't find a clear list of what those restrictions are in the FAQ[2].
(And to be clear: I'm not an ideologue around FOSS/OSS; I think source availability also benefits the commons. But I would not be surprised if FOSS/OSS people chafe at these kinds of implied-value-judgment labelings ("fair source," "commons clause") for what is fundamentally not OSS.)
[2]: https://fair.io/faq/
Fair Source is meant to sit on the gradient between Open Source and source-available. It's not meant to replace Open Source, diminish Open Source, or claim to be Open Source. It isn't Open Source, and never has been. It's definitely not trying to be a "pseudo-open-source."
It's a new term to clearly communicate something that's close to Open Source, if we envision that gradient between Open Source and source-available, and something that eventually contributes to Open Source via delayed Open Source publication (DOSP).
I don't particularly disagree; I'll just observe that calling your particular flavor of source availability the "fair" flavor is a leading characterization that people who do OSS (either for fun or professionally) aren't necessarily going to agree with.
Concretely: I found the terms of the FCL[1], and one of the restraining terms of "competing use" against the "business interests" of the author. Any half-competent attorney could use this to argue that virtually any change, including basic security fixes, would harm the original author's business interests by reducing the relative competitiveness of their version. That doesn't strike me as very fair: as a security person in OSS, I don't want to be punished with lawsuits for trying to remove security problems from the projects I rely on.
> It's definitely not trying to be a "pseudo-open-source." [...] It's a new term to clearly communicate something that's close to Open Source
Can you explain why these sentences aren't contradictory? Please understand that I'm not using "pseudo" to mean something negative; I meant that it's clear you're attempting to adapt some of the features of OSS licensing into something that isn't itself OSS. That isn't a bad thing in my book, but I do think the "fair" labeling and repeated reference to the specific properties of OSS that FSS finds desirable is essentially obfuscatory.
[1]: https://fcl.dev/
Yes, that was my point: someone who doesn't know anything about "Fair Source" might have reasonable value associations about the word "Fair" that aren't actually present in the terms of the FSL. In particular, being constrained from making any sort of modification that could potentially be a competitive risk for the original author is both a massive poison pill and is not consistent with what OSS people typically consider to be "fair" (or compatible with received notions of software freedom).
The basic version of my argument is this: if it was named the "Eventually Open Source But Currently Not License," there would be no value judgment to be concerned about here. But the use of "Fair" is clearly meant to communicate a normative position that, in reality, muddies the waters and dilutes the benefit to the commons by maintaining the author's interests. And this is fine (IMO), as long as it isn't obscured by words like "fair."
What I see is a lot of "single vendor" projects which carry most of development burden want their business protected while having, often minimal, contributions from community.
The "Real Open Source" though is multi-vendor - think PostgreSQL, Linux, Kubernetes among others, in which case many parties share the burden of development and maintenance but also have even playing field monetizing product.
I engaged heavily with a lot of Dirk's work in my historical deep-dive:
https://openpath.chadwhitacre.com/2024/the-historical-case-f...
> Dirk asked in 2021, “What’s next after ‘source-available’?” Our answer is Fair Source. I’ve made the case that it is a good way to resolve tensions that have been present in Open Source since the beginning. The net effect can be more closed-source code released to the world, and less pressure to change the Open Source Definition one way or another.
> we will see if it becomes popular
Agreed, time will tell. A major test is whether we ever see a viable fork under DOSP, seems likely years away if ever.
- https://news.ycombinator.com/item?id=38877059 (sentry FSL relicense)
- in particular: https://news.ycombinator.com/item?id=38312686 (rugpull licensing still possible on future versions/contributions)
- Sentry's first relicense: https://news.ycombinator.com/item?id=21466967
Looking back to the first relicense in particular, the company effectively doing a rugpull on third party users/contributors, and the trend of companies trying to pretend they aren't doing exactly that sours me on basically any 'opencore'/required CLA project. I make rare exceptions for non-profits, but only those that are mature, well established, and not the sort of non-profit that puts most of their operation under a for-profit entity.
As woodruffw mentions, these implied-value-judgement labelings are really marketing terms designed to muddle the value and importance of what it means to be an open source product.
If it doesn't work for your business, fine, don't use an OSS license. But don't expect us to slurp up your peddling when you want to pretend its an OSS license, and don't act sad when you alienate swathes of your contributors.
*EDIT*: I misspoke, my brain had thought that old Sentry licenses were GPL, they were more MITish as seen in the LICENSE file in older releases of Sentry. My mistake :\
FWIW, if Sentry had stayed MIT or even moved to AGPL, I think they would have stopped much of their newer competition from even coming to market (I'm thinking of signoz, glitchtip, vs OTEL and its million integrations here.)
My position in 2019 was that much these decisions are being driven by the VC money, and I believe that is still true today. If it weren't, they could have chosen options that served the wider community better. (I also think that wider community and the accessibility of such is what got sentry much of its initial draw, but TBH im not sure how much that bears out in reality. I haven't studied deeply enough to have a good idea of the numbers there.)
> don't act sad when you alienate swathes of your contributors
This is ill-informed, for what it's worth. Our relicensing had essentially no effect on the ratio of commits from outside the company: it went from 3.5% to 3.4%. I wrote about this when OSI published the DOSP paper that we underwrote.
https://blog.sentry.io/nows-the-time-for-delayed-open-source...
> the company effectively doing a rugpull on third party users/contributors
Since Sentry has always been built by Sentry, our relicensing wasn't a rugpull. I wrote about this when Redis relicensed most recently:
https://openpath.chadwhitacre.com/2024/relicensing-and-rug-p...
I will then ask, do you think Sentry would have been able to get enough of a mass of users to justify getting the VC funding it did if it weren't a MITish licensed product in its early years? How do you value the various libraries of user interaction, issue submission, and other market intangibles?
For a product developer, that is an external cost/value to you (the theoretical 'you', in this case), insomuch as there's no contractual obligations there and its not exactly clearly recorded in valuations and balance sheets, I believe. That openness and availability over time builds up a body of goodwill that I believe is critical to the success of a longterm opensource product.
As for Redis, enough people cared about the license change that valkey (https://valkey.io/blog/hello-world/) got stood up essentially immediately, which also got significant amount of developer traction. I notice that you dont mention them at all in your writing about Redis. Why is that?
No.
> How do you value the various libraries of user interaction, issue submission, and other market intangibles?
Highly. Dirk Riehle has a post from 2009 where he talks about the business benefits of Open Source community. I quote from it in the Fair Source FAQ:
> Fair Source provides many of the same benefits for companies as Open Source, by helping to foster an engaged developer community around your software products.
> I notice that you dont mention them at all in your writing about Redis. Why is that?
Because my blog post predates Valkey by a week. I've added an update.
> I will then ask, do you think Sentry would have been able to get enough of a mass of users to justify getting the VC funding it did if it weren't a MITish licensed product in its early years?
I agree no they wouldn't, but I also think it's not realistic to look at the 2012 ecosystem from the lens of 2024. I'd wager that you'd find it very hard to get VC funding if you had an MIT licensed SAAS in 2024 that could be "jeff'ed". The reality is that Sentry's model worked for the first 6-7 years of it's life, and whether or not it would have survived the competition is something we'll never know.
We never were once GPL, or remotely copyleft.
Is this an AI generated comment?
In particular, not having to worry about some others' business model changing and increasing the risk of using the product, as well as the experience with Sentry being portable across many different companies and verticals.
When a midsize company drops what was previously an open source product, and turns it into something that shifts to an enterprise sales model, the value of that experience drops drastically. IMO that drop is the reduction of utility and value of that previous experience. It also creates a gap that is a real problem in making open source software sustainable at scale -- if no company can afford to take a successful OSS product and graduate it to a more structured and contractual environment, that creates a ceiling on how successful OSS software can be.
I appreciate that Sentry is (i think?) trying to create a real solution to that, but I think their basis for it is wrong. I have some of my own ideas on what a solution there would look like, but its something I'd really have to study more deeply as well I think.
“Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like.” --hn guidelines
Sentry has never been GPL. https://blog.sentry.io/lets-talk-about-open-source/
> pretending it's an OSS license
They are not pretending it's an OSS license. The article states:
> “Just don’t call it Open Source.” Point taken. Fair Source is our new term.
That was my mistake, my brain remembering wrong. https://github.com/getsentry/sentry/blob/9.1.2/LICENSE was its last open source license, MITish, right?
As for calling it "*source" and saying "oh we're not pretending its open source"? This is a point of opinion, but I think that's disingenuous marketing, at best.
2009 - BSD-3
2019 - BUSL-1.1
2023 - FSL-1.0
2024 - FSL-1.1
Details: https://blog.sentry.io/sentrys-open-source-values/#our-histo...
and https://blog.sentry.io/introducing-the-functional-source-lic...
https://cra.mr/the-busl-factor
Its worth remembering that licenses are just part of the packaging of a product - part of the distribution model. Sentry is successful because we quickly found product market fit, continued to iterate, and made an affordable and well crafted product. Our distribution model - and in general our approach to affordability - is key to that, but the freedoms of open source software are less so.
For clarity, VC has never had anything to do with it, but we are certainly ambitious. Our singular goal from a product point of view is adoption, and we ensure that via accessibility and affordability. From a competitor point of view I personally think we've done better than most could dream of wrt marketshare. Companies like SigNoz don't compete with us today, and projects like GlitchTip don't even register on the market. Our competition these days is the fuzzy areas of the APM venn diagram like Datadog, New Relic, etc.
Allowed? Sure. Expected to? Nope. I put it this way in the FAQ:
> Developers can propose modifications back to the producer if they wish, or simply benefit from the company's continual investment in maintenance and improvement.
That said, for me personally (taking my Sentry hat off for a second), I think the most interesting future is one in which companies use Fair Source licensing _and_ open hiring/twyw compensation:
https://opensource.com/open-organization/16/5/employees-let-...
https://gratipay.news/sharing-our-take-what-you-want-story-9...
Fair Source is a small step towards that as a possible future.
I'll be honest, that doesn't sound nice. It sounds like a way for corporations to skirt employment law, similar to other gig economy companies. Do not want.
https://opensource.com/open-organization/16/7/compensating-e...
Super-experimental, though. Not ready for prime time yet. :D
Anyway, so, I tried Sentry at some point, like, five years ago. Signed up for the 'team' plan, even though it's just lonely me, and had bugs coming in for about... a week, maybe less? Then, my subscription suddenly became inactive, because I had exceeded the 10K (or so, at the time) bugs that they were willing to track for me. Not, unique bugs, mind you, just the same bug that the same automated process was hitting every second or so.
But still, I now had to either negotiate an "Enterprise" price plan, or go away elsewhere. And I did actually ping them about the former, but never got a response. So, well, back to manually reading logs like an animal it is, then, I guess?
TL;DR: If your vision is to solve a certain problem, aren't the oh-we-didn't-see-that-coming corner cases the most interesting?
Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal"; you must have missed something. I say this having been a Sentry customer for the past 7 years across multiple companies, always with a paid plan beyond 10k errors and never with an enterprise deal.
OK, maybe not, but, on the current version of https://sentry.io/pricing/:
Developer (free): 5K errors
Team (US$312/user/year): 50K errors
Business (US$960/user/year): 50K errors
Enterprise (who knows): who knows
So, they now go from 50K (which sounds close enough to '10K 5-or-so years ago', right?) errors to "negotiated enterprise deal", and I have no idea whether that's worth it?
Do they coalesce errors these days? Again: I would love to use services like these, and I even don't mind getting a customized pricing plan, except that nobody like, ever, seems to want to talk about even the most basic details?
"Just give us your credit card number, and we'll see what happens, we'll make it work"... Right! But, but by any means, go and complain on HN that's it impossible to get paying customers...
wrt Enterprise, you seem to not be the target person. Its primarily about access to humans. Terms, liabilities, SLAs, services, etc. If you are FAANG scale, yes it is about price negotiation as well. When you are in the buying cycle at a company that needs these kinds of things you are well accustomed to this kind of thing.
1. A single component in my app causes the same error over and over again, every second or so
2. This causes me to run out of my 10K, 50K, or whatever, fully paid-up 'Teams' or 'Business' allowance within the first day, and then my account gets disabled
3. Once my account gets disabled, my only option is to "contact Sales" and they never reply to me (in the case of Sentry), or quote me an amount that I'm simply unable to pay (in the case of many other similar services).
So, you could address this concern by stating that you now coalesce similar errors, and that my scenario is no longer an issue. Or, you could just punt me to a sales contact. Or, just, basically, tell me to "get gud" and get back in touch once my services have proper error handling.
Instead, you chose to pretend that I can't write properly, which, frankly re-confirms my notion about Sentry: RUN AWAY WHILE YOU CAN! This goes doubly for employees, BTW, so... consider yourself informed!
1. You have a burst of errors - typically this happens first month when people dont understand their volume, or they had a runaway bug.
2. We rate limit/throttle you for your billing period. We also provide some tools that we'll eat various cost for periods of time (such as Inbound Filters and Spike Protection).
3. You never have to "contact sales", but you're certainly welcome to email support, and they almost always will forgive your volume.
It sounds like you want us to pick up the cost, which sure, sounds great as a customer, but we're trying to build a long term sustainable business. We can't just accept infinite data and not charge for it. All of that costs money, and while in some less common scenarios you can dedupe client side (we do), mostly they have to hit our servers, and that has a cost associated.
Good to hear that things changed, though: for me, it's a bit late, but, hey, I'm not your target audience anyway.
- $312/year and $960/year are for unlimited users, not per seat
- Additional error/event volume is priced separately from the base plan
- You can pay for error volume, either prepaid or on-demand, without a custom enterprise deal:
> Each of our plans comes with a defined quota, with the option to process additional events by setting a pay-as-you-go budget. You can also plan ahead and save 20% over the pay-as-you-go rates by reserving events.
That’s the beauty though: if we really fuck up it eventually fully turns into open source.
The entire point of choosing to use open source projects is that if you, the author, begin to enshitify the product (Or simply start to move in a direction different from users) users can fork the project and carry on an un-enshitified version.
If you can't compete with the author, you can't do that. So what is the point of picking software using this license over traditional closed source?
> So what is the point of picking software using this license over traditional closed source?
I don't want to compete with Sentry (or a variety of other open-like applications), but I _do_ want to support my employers identity provider, fix bugs (and push them back), and maybe even add features that I/my team use. As an example, I've personally contributed multiple bug fixes, performance improvements and documentation changes to sentry's libraries. I don't want to compete with sentry, I want them to maintain my improvements and for other developers to benefit from my work.
1. I'm on the governance 'board' for Fair Source, and I am not associated with Sentry. All it took was involvement and deeply caring about the subject (which I know you do).
2a. The requirement for delayed Open Source publication (DOSP) could have been discussed further if there was more involvement from other non-DOSP companies other than me (before I relicensed from ELv2 to FCL). I advocated for ELv2 to be considered Fair Source, but nobody else advocated with me, and I ended up abandoning it for the FCL. I was looking forward to you discussing SUL and how it was a good fit for Fair Source, but you never did.
2b. The lack of options for self-hosted monetization (e.g. EE/CE offerings) is no longer a problem for Fair Source under the Fair Core License [0], which I drafted alongside Heather Meeker (who helped draft FSL and ELv2) to solve the problem of self-hosted monetization under the FSL or BUSL.
With that said, I think where we landed i.r.t. requiring DOSP makes sense as a differentiation vs open core and "source-available." I was originally vocally against Fair Source requiring DOSP, but the lack of involvement from other companies using ELv2, SSPL, and SUL, made the decision a little bit easier.
When I heard from Chad, DOSP was also still optional. The only issue I had was about governance. That sadly changed around one week later, and it became a hard requirement, even though I made very clear that it would be a deal breaker. So, I would say I was at least involved there, but it did not really matter. Worrying about something like that was interestingly also why governance was so important to me. I expected it to become a problem sometime later but was surprised that it was already a problem before it really started.
Our original conversation was also more about what to move forward with, fair code or source, and should be more like a joint effort (at least how it sounded to me). I was, however, very honest about it, saying that my time was limited at that time, and so I am happy he takes the lead. Maybe that is where it partly broke down, and we understood something very different.
Regarding differentiation: Honestly, I do not think the difference between "fair source" vs "open core" vs "source available" is what matters. What matters is the differentiation vs open source.
Ultimately, DOSP is a good thing and I want to see more companies adopt it under Fair Source.
Anyway, it sounds like it would potentially not have changed much of a difference considering you are also pro DOSP ;-)