bentlegen

It stopped being relevant because its content became acceptable on major social networks, beginning in late 2022.

Hopefully you won’t mind me using their own arguments to promote this OSS web analytics project instead:

https://counterscale.dev/

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.

However, it's not meant to be a community project or used commercially for free.

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.

Which is exactly why they now need to switch licenses and put newer features behind more restrictive terms so users are forced to pay

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.

[1] https://blog.sentry.io/relicensing-sentry/

Google has an organization-wide ban on using AGPL software, and they explain why here:

https://opensource.google/documentation/reference/using/agpl...

Is it possible to run Counter scale on-prem against logs from HAProxy, Nginx, or Apache?

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.

Plausible is great (I use it at Sentry), but I want to clarify that only Plausible Community Edition is open source, and it note it differs significantly from their paid SaaS offering:

https://plausible.io/self-hosted-web-analytics

What terminology would you use instead to differentiate it from a SaaS solution?

Someone suggested "self-operated" elsewhere in the thread. Thoughts?

Because those are the underlying services that the above software is built on. And they allow the system to handle both very few to many many requests/sec for basically $0. That's the point of the article.

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.

Maybe self-operated is better terminology -- that's fair. (Though I think one of the key points is that there is almost nothing to operate.)

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.

I don't work for Cloudflare?

Can you do 100k requests/day for free running Kafka, Clickhouse, nginx, some queue-draining code, etc?

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?

I assume you're not talking about this company because there is no such script on spotlightjs.com (easily verifiable), and the docs are also actually in the repository:

Example: https://github.com/getsentry/spotlight/blob/main/packages/we...

Your browser's dev tools don't show you what's happening inside your server (and any downstream services) when responding to the browser's HTTP requests. Spotlight does. That's what's special about it.

In the early 2000s in college I wrote a basic terrain renderer in C++ and OpenGL. It randomly generated some textured terrain, and had some basic features like you could move the camera and look around. Nothing super impressive.

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.

Re: open.sentry.io, some of the language should probably be more clear. We’ll take a look at it.

Then release your software under a source available non-compete license with the caveat that it will become open source when you stop working on it. (Basically what you have already done.)

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.

https://fsl.software/

Feedback accepted. We’re still sharpening our language, and the FSL is the best articulation of what we want to do today.

I don’t feel it’s deflection because Armin is the creator of Flask, a founding engineer, and our Principal Architect. He additionally is a member Sentry’s senior engineering/product leadership, and a key contributor to our licensing efforts. It’s his blog and his personal comments, and we are not a monolith, but I feel his statements are a good reflection of our values. Mine at least. (Disclosure: I’m also a part of this group.)

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.

[1] https://blog.sentry.io/sentrys-open-source-values/

I don’t feel “given you already have a proprietary license, why wouldn’t you just make it freely permissive” needs much explaining. We develop the software; the exclusivity period helps us monetize the work (vs giving it away to someone else who would).

I think it’s worth reading the announcement from 2019 when Sentry first switched to BUSL. The original article links to many such pieces.

https://blog.sentry.io/relicensing-sentry/

but are people who are trying to replace open source software with a shared source version

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.

when you try to mislead people into thinking those licenses are open source I think you're crossing a line.

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.

Or in other words, to use their quote back on them: If you are convinced your license is the best thing since sliced bread, there is probably little we can do to disavow you of that notion.

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.)

All of this is covered in the article.

I think the direction of your comment is right, with two caveats:

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.

Sentry was already using BUSL (Business Source License) for 4+ years with a non-competitive Additional Use Grant. So we had already been doing this for a long time.

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.

It feels like you intentionally omitted his immediate follow-up to your quoted comment:

> 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.

[1] https://github.com/getsentry/fsl.software

Proprietary wouldn't allow for free, non-competing use of the software during the 2 year period. The FSL does.

The people we're concerned about are not the hundreds of thousands of Sentry users, including those that self-host.

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).

I'm not a lawyer, but here's my non-official interpretation:

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.