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.)
The problem with "source-available" is that it has no real definition and it conveys no user freedoms at all outside of the loose freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate. That's why we needed a new term that does have a concrete definition and does convey user freedoms.
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).
> The problem with "source-available" is that it has no real definition and it conveys no user freedoms at all outside of the loose freedom to read the source code, which is why the term has never taken off with anybody. It's wholly inadequate.
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.
I think "psuedo-open-source" and "close to Open Source" convey something vastly different. The former implies, by definition, that it's fake Open Source, i.e. what most would call "open-washing." Fair Source was literally created from a CTA to stop open-washing [0]. We can absolutely say that Fair Source is close to Open Source without claiming it is Open Source, because it is close to Open Source if we look at raw user freedoms, and especially if we compare it to the typical understanding of source-available and closed-source. It's helpful to visualize these differences on a gradient. Fair Source is literally on the cusp of Open Source when visualizing that gradient, and even becomes Open Source.
> I think "psuedo-open-source" and Fair Source convey something vastly different.
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."
I think it is great Sentry folks do not pretend it is Open Source. It is great to see innovation and we will see if it becomes popular.
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.
> 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.
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.)
I have written quite a lot on my personal blog about our decisions and been very transparent. In particular, the decision on switching to BUSL orgininally I talk about here:
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.
> 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.
I see your point about commit ratio, and that I admit is a correct view of the tangible contributions, but I also dont think those are what got Sentry its traction.
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?
I'm not OP, and not currently a sentry user (but I am a sentry fan. That said, my feelings here are the same for other MIT-like to BSL/Fair-source like transitions).
> 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.
> 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?
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.
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.
> FWIW, if Sentry had stayed GPL 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.)
Not one bit, I misspoke from memory there, sorry. FWIW I spent multiple years running Sentry for some fairly large orgs in the eras prior to Sentry's first relicensing. A large part of what got our teams interested in the product were the quality of engineering and the low risk of adoption.
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.
I'm not sure what's special here.
The company makes the source available, but doesn't accept changes from the community.
If the community really hates what the company does with the product, it can fork it.
If the company goes out of business, the license reverts to a standard OSI-approved one.
Unless I'm missing something – entirely possible – this doesn't sound like anything new and different.
From how I read the Fair Souce manifesto on their site, the company is allowed to accept and benefit patches made by dogooder developers, but those developers are not allowed to make any changes that impede on the "producer's business model", which implies that hard forks would actually be prohibited. So it's actually worse. You're allowed to do free labor for the company, and nothing/no one else.
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:
I would do this if it benefited my company. It’s almost always easier in the long run to fix something upstream than to have to maintain a downstream fork.
Any patch that I make to a third party dependency increases the risk of upgrading the dependency. Any change they take from us benefits us in the long term, and benefits the industry as a whole.
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.
So, since I'm an unrepentant cynic, I guess it's now, like 1.5 months until the inevitable "Sentry: it has been an interesting journey" blog post?
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 been around for ~15 years, and has been using a license fitting the Fair Source definition for ~5 years. This is not a "hastily preparing ourselves to be acquired" sort of move. What makes you think this is a sign of some impending change?
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.
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...
I would recommend reading more of the pricing page. You'll learn that:
- $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.
What's the concern here? The pricing is transparent, and yes we've adjusted it over the years to be more in line with our costs. We still charge you per error just like we have since I started the business, and we're very honest about that. If you scrolled down you would see a full transparent pricing calculator for all of our product offerings.
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.
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?
It's not _just_ read, it's read and modify but not redistribute in a way that competes with the original product,
> 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.
Another one in the long line of victims of the "popular open source product -> VC funding -> demand for profits -> closed source -> enshittification" pipeline.
Honestly generally love it. Not surprising, after all, are we at n8n Fair Code licensed ourselves(not to be confused with Fair Source). I would, however, really love it if it ended up being more inclusive and so in a joint effort rather than a divided one. More information about why we did not join here:
https://medium.com/@faircode/n8n-commits-to-fair-code-6b8923...
I wish you would have been more involved in the discussions [0] [1] leading up to this. I know you were invited to participate, since Chad shared your thoughts a few times via proxy. Regarding your main points:
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.
Yes, I totally agree that I should have been more involved in hindsight, and that is definitely on me! In the first conversation with Chad, we actually agreed on chatting again after a few weeks regarding the next steps, but that never happened. The next time I heard about it was a few weeks before the launch (and yes, for sure, also partly on me!).
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.
We had some pretty detailed discussion that you missed out on: https://github.com/fairsource/fair.io/issues/14#issuecomment.... I'm sure SUL would have been right there with ELv2 since it's derived from it. I wish you would have participated. I ultimately relented because I relicensed to the FCL (because I wanted an ELv2 that was DOSP).
Ultimately, DOSP is a good thing and I want to see more companies adopt it under Fair Source.
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.)
[1]: https://fair.io/about/
[2]: https://fair.io/faq/