Hacker News Reader

Comment by tedivm | Hacker News Reader

The abusive part is the lie, especially the lie that is literally trying to change the definition of open source. There are sentry employees in this very thread trying to argue that "BSL is open source".

If CodeCov said "We are releasing our software under a shared source model" they would still be accomplishing all of the stuff you're saying (preventing AWS and Gitlab from using their product), but they wouldn't be lying about it. That's the major difference here.

The fact that this lie has damage beyond just their company is what's important. If we continue to shift the definition of "open" to include more and more cases of "closed" then the entire concept of open source loses it's meaning. Microsoft tried this in the 90s/2000s, and it's really disappointing to see companies that claim to be promoting open source attempting this today.

View on HN

I created the Sentry project, am the CTO, and represent one of the strongest voices in our company for why this opinion of open source must change or open source will continue to be unsustainable.

I disagree with your sentiment here, as I see plenty of negative effects from unfunded open source, from low ethics companies, and from proprietary softwares deterrent to progress.

BSL is allowing us to give $500,000 to other open source projects this year, in addition to allowing any team in the world to use our software. What other open source company is putting their money where their mouth is? Nothing obligates us to make any of these decisions.

We need to evolve our irrational views of idealism and find common ground that allows sustainability if we want open source to thrive.

No one is saying there's anything wrong with releasing your code under the BSL. What's wrong is that you're lying and claiming you're open sourcing your code.

At this point it's hard not to think that they're purposefully ignoring this. It doesn't matter how many times I say that I don't care about their license, just their messaging, and yet we've got at least three employees from Sentry completely ignoring that and acting as if we don't think they have a right to license their own software.

It's a straw man that lets them ignore the actual issue people have.

They've been like this before with Sentry, when I've raised their sketchy use of open source. I have some example queries/responses in this issue:

https://github.com/ssddanbrown/Open-Source-Confusion-Cases/i...

The repo readme has other examples of sketchy cases of open source and licensing usage. This aspect (of why not just use a different term) often gets ignored. Sometimes folks say they're using it "to prevent confusion to users since they would have heard about open source" which is always an ironic self-involved viewpoint to see.

There are a lot of companies that support open source (Github has given away far more than you have, other companies sponsor employees to work on software directly, etc etc), you aren't special just because you claim that you're an open source company. It's not the BSL that gives you the ability to donate money, it's the fact that you sell a profitable product. You could sell a proftable product with a closed source license, or you could call your license shared source, and still donate money.

That being said, I think this is the first time I've seen someone at Sentry openly admit that you are trying to change the overall definition of open source and I do thank you for at least admitting it. If your end goal is to exclude commercial reuse from the open source definition then my theory about embrace/extend/extinguish seems to be as accurate as I thought.

> your end goal is to exclude commercial reuse from the open source definition

This is fairly accurate, though there are a range of possible outcomes we would be satisfied with.

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

What is the standard in this case? The Open Source Definition? What is the extension? A limit on commercial reuse in the OSD itself? A widely endorsed time-based license scheme such as BSL? Let's say this came to pass (use your imagination :P ). What is extinguished thereby? The OSD still stands. The supposed extinguisher is _more_ committed to the standard, not less. Other companies that use even weirder licenses like SSPL and ELv2 and now HFOIL :rolling-eyes: are likely brought back within an easier to reason about system and we can all stop arguing about this a couple times a year. There is net _more_ open source software in the world, in both the strong (current) and weak (time-delayed) sense.

That seems better to me than the current situation, and if in your view that is a change in the essence of open source, then yes, let's change open source. Change or die.

[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]

Open Source has always meant without limitations on use. You want to extend the standard to add a limitation on use, which would in turn radically change the definition of open source (to the point where you'd extinguish the current definition). Rather than simply accept that open source doesn't work for your business, at least for your core product, you want to change the definition of open source to something that it isn't.

> literally trying to change the definition of open source

1. The only way for businesses to release their core products under OSI-approved licenses is through a time delay such as the BSL.

2. It's good for businesses to release their core products under OSI-approved licenses.

3. Therefore, some concept of time-delayed release must be included in the definition of open source.

I'll concede that this is an evolution or refinement of the definition of open source, but not a change to the essence.

[disclosure: I'm Head of Open Source at Sentry, which owns Codecov.]

It's kind of crappy for you and others at Sentry to attempt to unilaterally change the definition of open source, despite the fact that there clearly is opposition to it.

Why do you say unilaterally? MariaDB wrote the BSL, not us. Sentry is far from the only company with the problem of wanting to open-source its core products without exposing itself to the risk of other companies cannibalizing our business model without contributing to product development. This is an existential threat and the BSL protects us from it so we can keep improving Sentry.

"The Business Source License (this document, or the "License") is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License."

BSL doesn't try to redefine open source, it's clear it's transitional. So you're trying to do something MariaDB didn't do and the BSL doesn't do.

> Therefore, some concept of time-delayed release must be included in the definition of open source.

Or, you know, use the existing definitions for that transitional stage.

Your assertion is neither "therefore" nor "must".

Why are you so attached to calling something open source when it is not open source? You know it will piss people off. You know it will generate bad will. You can avoid all of that by simply not calling it open source. Why are you so insistent upon using deceptive labelling? Where is the benefit?

Reply on news.ycombinator.com