It stopped being relevant because its content became acceptable on major social networks, beginning in late 2022.
3,659 karma · joined April 2, 2009
Unlike Simple Analytics (the post authors), you deploy Counterscale to your own Cloudflare account and control the code + data end-to-end. It also uses no cookies, has no browser fingerprinting, and has no monetized SaaS offering.
It only has 90 days retention though, which could be viewed positively.
But they can?
Source available can mean everything from "proprietary, you can look but you can't touch" to "this source code is licensed under Creative Commons Attribution 4.0".
Creative Commons projects can be used in commercial projects, for free, provided you adhere to the license terms - but they do not meet the open source definition.
This is exactly the problem. "Source available" refers to such a massively wide gamut of possible licensing scenarios that it may as well be meaningless.
Sentry switched to BUSL in 2019, almost 5 years ago.[1]
Most of the aforementioned fundraising occurred after the license change (e.g. the $90MM round you mention from 2022, and another $60MM round in 2021).
The "restrictive terms" - which again, were introduced in 2019 - are that you can use the software but not use the code to compete against the software's authors. For 99.99% of users, this has been a non-issue, because most people have no interest in doing so.
https://opensource.google/documentation/reference/using/agpl...
Probably. But it's not for that use case (for example, Counterscale intentionally strips IP addresses).
> There's also a newcomer called Plausible which has a FOSS Community Edition [1] which can be self-hosted.
One of the goals of Counterscale is that you can deploy it "fire and forget" with a single terminal command.
Contrast this to Plausible CE, which makes it clear you need some basic adminstrative skills to operate the software:
> you should have a basic understanding of the command-line and networking to successfully set it up
The point is that Counterscale is designed differently than traditional "self-hosted" solutions in order to promote ease of deploy. It comes with serious constraints (like a dependency on Cloudflare). But some people may prefer those tradeoffs.
Someone suggested "self-operated" elsewhere in the thread. Thoughts?
To say, "I can run a server that can handle a bunch of requests for free" doesn't mean much. Of course you can do that. But can you replicate the aforementioned system for free? Probably not.
For me, the fundamental issue is whether I am controlling what code is out there, I'm paying the pure infrastructure costs, etc. So whether it's self-hosted or self-operated doesn't matter.
For some it sounds like if you aren't managing it at the operating system level then it isn't self-hosted.
Clickhouse says the minimum amount of RAM it needs is 8gb. Kafka also needs multiple GB of ram. How small an instance will you get away with?
Example: https://github.com/getsentry/spotlight/blob/main/packages/we...
A few months later I landed a 16-month internship on a team writing an OpenGL ES driver. There were 160 applicants, but the hiring manager said I was the only applicant who had actually played around with OpenGL.
It was a great job and I learned a ton.
Done.
Note that the license website is pretty clear that it is not Open Source. If you find a place where that is not true, you can open an issue on the website’s repo and we’ll address.
The Head of Open Source has followed up on the Codecov conversation and expanded on those comments [1]. I earnestly hope you’ll weigh these official comms higher than an HN comment.
I think it’s worth reading the announcement from 2019 when Sentry first switched to BUSL. The original article links to many such pieces.
Note that the thread you link to is a situation where they took an entirely closed source product, CodeCov, and made it source available under BUSL (and now FSL).
> Unlike other companies, such as Hashicorp, who admit that their software is no longer open source Sentry wants to have their cake and eat it too.
From the parent article (FSL: A License for the Bazaar, Not the Cathedral):
> But one thing is clear: until its expiration, the license does not qualify as Open Source. While I recognize the sensitivity around the term “Open Source”, I assert that the FSL's approach is more closely aligned with Open Source ideals than mere source availability. I consider it an “Eventually Open Source” license, though perhaps a more fitting term needs to be found.
Here's what Armin wrote in the parent linked article:
> ... But one thing is clear: until its expiration, the license does not qualify as Open Source. While I recognize the sensitivity around the term “Open Source”, I assert that the FSL's approach is more closely aligned with Open Source ideals than mere source availability. I consider it an “Eventually Open Source” license, though perhaps a more fitting term needs to be found.
I don't think anyone in this thread has claimed that this license is the best thing since sliced bread, or even described it as "great". It is a license we have chosen to use that we think is good for us, and we think it has merit for similar SaaS businesses who choose to share their code as we do.
(If I'm mistaken and someone has claimed that, I am happy to be corrected.)
> but is closed now to create scarcity
1. It's not about scarcity. The software has always been given away for free for non-competing use (it was licensed under BUSL for 4+ years with a non-compete Additional Use Grant before this change).
Sentry's cloud offering (sentry.io) has always "competed" with its own free self-hosted users, and the new license doesn't change that. It's strictly about preventing free-riders who monetize the work without giving back.
> it’s different from simply switching to Apache later because it’s the promise that’s doing the heavy lifting
2. I agree, but I want to clarify that it's not a promise (which could be broken). It's a grant that is written into the source code itself (in the LICENSE file). If you possess a copy of the code today with this LICENSE file, in two years that copy will be Apache 2.0.
The new license actually allows for more competition, because it has a shorter change date to permissive OSS than the aforementioned prior license (2 years vs 3 years).
So another read of this is: the business model is going great, so much so that we're comforable switching to a more progressive license vs. what we had.
> > my theory about embrace/extend/extinguish seems to be as accurate as I thought.
> This is confused. Embrace/extend/extinguish means to initially participate in an open standard and then extend the standard in such a way that the non-extended version is sidelined.
I'd encourage people to read the entire thread rather than seize on the cherry-picked comment, additionally loaded with terminology like "they want to destroy open source", which doesn't appear in the original thread.
I can't speak for whit537, but I do work at Sentry, and I feel your comments about our intentions are disingenuous. We are open in that we feel the existing models don't fit our needs, and we're trying to evolve the language to make non-compete licenses more approachable and thus more mainstream. That doesn't mean an elimination of existing popular OSS licenses. We're even explicit in saying, "FSL is for SaaS businesses". That's pretty narrow, and probably excludes 99% of software.
Note that the FSL is developed in the public, and echoes the language I've used above[1]. But if you believe pursuing additional licensing mechanisms means we're destroying OSS, there is probably little I can do to disavow you of that notion.
We're concerned about people who have taken the software for the purposes of competing directly against us, that hinders our ability to monetize the work. Monetizing the work helps us continue improving the software and distribute it for free use, benefitting those aforementioned real users (e.g. https://github.com/getsentry/self-hosted).
1) If you host the software, and say "hey get your Sentry over here", that's basically a substitute.
2) Means use the work in such a way where you expose its APIs (i.e. the software is returning API responses). Note this is written as "using the software ... in a way that exposes the APIs of the software".
Perhaps this could be made more clear, but I believe this was written with the understanding that there is prior art on the copyrightability of APIs, not some feigned attempt to assert a copyright.
3) If you're building some kind of software observability platform that leverages Sentry.
If you're concerned about doing any 3 of those, then yes, perhaps you should not use the software. Overwhelmingly 99.99% of software people aren't doing anything remotely close to any of these clauses.
I'll also note that Sentry itself was licensed for 4+ years under BUSL using similar terminology (that was arguably far more vague). The inclusion of non-competitive language in the license did not stop users from using the software – because again, most people aren't competing.
You're welcome to make your own decision, of course. No one is forcing you to use anything.