Hacker News new | past | comments | ask | show | jobs | submit login
CodeCov is now Open Source (codecov.io)
143 points by yla92 on Aug 2, 2023 | hide | past | favorite | 173 comments



Not really open source, they are releasing their code under the BSL (Business Source License https://github.com/codecov/self-hosted/blob/main/LICENSE). But still great, and they use Django :D

It's also interesting that they will no longer offer a commercial self-hosted solution.

> As a part of this shift, we are offering a new self-hosted repo that makes it easy to run Codecov in a minimal docker-compose based setup for proof-of-concept and small volume deployments. We are end-of-lifing our commercial self-hosted offering, but will continue to provide support to existing customers who are running Codecov on-prem.


N.B. BSL already refers to boost


Yeah BUSL or better yet BUSL-1.1 is the right way to refer to the Business Source License https://spdx.org/licenses/BUSL-1.1.html

BSL or better yet BSL-1.0 is indeed Boost https://spdx.org/licenses/BSL-1.0.html


Noted! We’ve messed this up in the past and I have a vague recollection of this same confusion. Hasn’t helped that others (possibly also partly due to us) have made the same mistake. We’ll work to correct this usage.


FYI we have a follow-up at https://blog.sentry.io/lets-talk-about-open-source/.

> Yesterday we announced that Codecov is now “Open Source”, and we messed up in two ways:

> - We wrongly used the term Open Source; while unintentional, we should have known better

> - We let our emotions get the best of trying to explain our position, rather than stepping back and addressing the problem

> I want to talk about both of these, how we made the mistake, why it’s important to us, and what we plan to do about this to improve the conversation in the future.

HN post: https://news.ycombinator.com/item?id=36990036


> Business Source License

Standard open-source but you can't use it in a competing commercial offering.


So not open source.


Mostly open source.


If you go by the OSI definition of Open Source (which, I know, not every does), then it's either open source or not. In this case, that license is not open source.

https://opensource.org/osd/

> The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

From CodeCov's BSL which goes directly against the above:

> You may make use of the Licensed Work, provided that you do not use the Licensed Work for a Competing Service.

-----

With that said, huge applaud to CodeCov for even making the code public under a BSL license, it's obviously a great step compared to status quo. I just wish they'd call it "Source Available/Public" instead of "Open Source" as many already seem to have troubles with what open source means.


Don't forget that it reverts to Apache 2.0 after three years—eventually open source for the nit-pickers. ;^)

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


You should probably use your position to get the title of this blog post changed, then. "CodeCov will eventually be Open Source" is far less deceptive.

Or, more elegantly, "CodeCov is now Source Available".


Exact text copied from the license file:

    Change Date:2023-06-29          2027-01-01
    
    Change License:       Apache License, Version 2.0


    Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.
Did Sentry inadvertently open source CodeCov under Apache terms as of June 29, 2023?


Good catch, thanks! Fixing in https://github.com/codecov/self-hosted/pull/6.


I'm not sure you can undo this with a pull request.


This mistake only occurs in the self-hosted repo, which contains very little code. All of the "real" code is in the other four repos, each of which have their own LICENSE file that did not have this mistake.


Yes you can. If someone claimed "I can use it because they accidentally published the wrong license and swiftly corrected it", that wouldn't hold in court.


Would you have any precedent for that? I think in most of the world, that would hold in court.


Okay, then either title the page "CodeCov will be Open Source in 3 years", or wait 3 years and then release a post titled "A really old version of CodeCov is now Open Source".


Is this an official statement we can ignore the license differences? Or are Sentry nit pickers also?


So not open source.


Eventually open source.


It is open source, just delayed.


Open source enough that you can use it privately


I am so freaking sick of companies lying and exploiting open source. This is Embrace, Extend, Extinguish at it's finest. By calling closed source software open source they're moving the window and confusing the entire concept of open source.

I would have rather see CodeCov stay completely closed than see them pollute and damage the open source community like this. Frankly, this abusive nonsense means I will stop using CodeCov and stop recommending them to anyone- which is what I did when Sentry went closed source as well.


> I am so freaking sick of companies lying and exploiting open source. This is Embrace, Extend, Extinguish at it's finest.

I don't see how this is 'Embrace, Extend, Extinguish'? This license guarantees that the code becomes Free Software at a maximum of 4 years - and in this case they've specified a shorter time period.

I'll give you that there are lots of games played in open source, so I understand that feeling of cynicism. But, this actually seems like an attempt to add some nuance to the commercial<-->free divide.

The reality is that many 'commercial' OSS companies have to take the open core route because understandably investors expect a return on their money. There are exceptions to this, but they are pretty rare. In fact, there are probably a whole set of SaaS companies that could be open source, but don't do so out of the fear of someone taking their code and 'free riding' them.

Finding a way to prefer the entity that sponsors/incubates the code base, while also genuinely allowing a community of contribution around it (not free riding) would be very beneficial in lots of situations. Maybe a better critique would be that this has some similarities to the Trolltech QT approach - but that's a different argument.


> I would have rather see CodeCov stay completely closed than see them pollute and damage the open source community like this.

That seems highly irrational. As of today, CodeCov is scheduled for full, OSI compliant Open Source. In a few years people can fully fork and do what they want with it under the Apache 2 license. How is this not an improvement over closed source CodeCov?

Sure, Apache 2 straight away would be nicer but in practice that’s really impossible to accommodate in a commercial context. The only alternative I know is where you keep the interesting pieces closed (eg: open core).

For most people the BSL restrictions won’t matter and if you find interesting code in Sentry or CodeCov you want under Apache ahead of time, you can always mail us.


You should really disclose that you work for Sentry/CodeCov in your comments about this.

Being "scheduled for open source in three years" is not the same as being open source today.

Keep in mind there is a third option- CodeCov could just be honest about what they're doing. They could just say "shared source" or "source available" and take the exact same actions they're taking, just without misleading people.


I was assuming that writing “us” would be clear about my association.

From where I’m standing there is a massive difference between “source available” and BSL with Apache 2. The latter does not require goodwill from us in the future.


Can I suggest calling it "Eventually-Open Source Software"?

> Software that has source code available that automatically becomes open source at some explicitly specified, unchangeable, point in the future.


> Can I suggest calling it "Eventually-Open Source Software"?

FWIW that's what I call it, but that's not exactly a well known enough term.


Eventually open explains itself. And makes anyone not sure what it means aware to find out. It is superior entirely to lying.


Most good-faith commenters put clear statements about their association to what they're defending. Not doing so immediately makes me suspicious.


>Keep in mind there is a third option- CodeCov could just be honest about what they're doing.

They are. In no way was I confused about what they are doing when I read this.

It's practically speaking open source for everybody with a poison pill for companies like AWS that have successfully charged rents on open source without giving anything back (like elastic search).

Restricting the hosting monopolist's freedom in order to fund the development of open source appears to make some people extremely angry.


> Restricting the hosting monopolist's freedom appears to make some people extremely angry.

That's not why anyone is angry. They're angry because it's labeled "Open Source" in the title, and then turns out to be not actually Open Source.


It's the same thing. Theyre angry because they agree with big tech's gatekeeping of open source.

You may think it's purely an apolitical question of definition but it's about as apolitical as saying "Crimea is part of Russia".


No, it literally is not the same thing, and is literally not about big tech at all. It is in fact very simple: Is the thing you're calling Open Source actually Open Source, or is it not? You don't get to change what words mean because you think they should change, or because your business model isn't compatible with their real meaning but you'd really like to use them anyways.


> It's the same thing.

Let's see how committed you are to that stance: just have them change it to the proposed wording. Should be no problem, since it's the same thing, right?


> As of today, CodeCov is scheduled for full, OSI compliant Open Source.

Then title the blog post, "CodeCov will eventually be Open Source" instead of being deceptive.


> Sure, Apache 2 straight away would be nicer but in practice that’s really impossible to accommodate in a commercial context. The only alternative I know is where you keep the interesting pieces closed (eg: open core).

"impossible", huh? Wow, that must make Zulip the company really mad to hear they're going to close up shop tomorrow morning, and those GitLab folks are never going to go public </snark>

I mention GitLab as a nod to your open core comment because the MIT product they ship provides real value, as does their very real hosted offering


Do you disagree the Apache licensed version of Sentry doesn’t provide real value?

What about all the supporting tech that we have released as MIT, BSD, or Apache?

All of that is funded by our ability to stop companies like your beloved GitLab from being the ones who commercialize the other parts. Our goal is not to argue about proper nouns, but to maintain the spirit of open source, and to do that we need to move the conversation forward.


GitLab is a good example of not actually opensource. They are open corse which is much worse than BSL. There are tons of features they don't allow you to use even if you self-host unless you purchase a license.

BSL lets you use all features and self-host as long as you aren't a reseller. It is the best model I've seen.


I would enjoy seeing the specific features of the MIT codebase that they "don't allow" you to use


All the features they exclude from the MIT code base and only include in the The GitLab Enterprise Edition...

https://about.gitlab.com/pricing/#compare-options

There is a box for "Open Source - MIT License". You'll notice most of the features are not covered under it.


> All the features they exclude from the MIT code base and only include in the The GitLab Enterprise Edition...

> > I would enjoy seeing the specific features of the MIT codebase that they "don't allow" you to use

I feel we are not on the same page. But, good luck with your BSL future


What do you mean we aren't on the same page? These are two options when opensourcing things:

- GitLab went with Open Core and kept most of their features closed source and not available to the community

- Companies that choose BSL provide all their features to the community both from a source available standpoint AND a usage standpoint.

In my opinion BSL is a MUCH better place to be in than the open core model.


I agree with you.

If the choice is Open-Core vs Non OSI Approved License(tm) Open-Source, I definitely support the latter.

The OSI needs to be honest and push "OSI Approved Licenses(tm)"... Instead they're like the Simpson's Old Man Yells at Cloud meme, trying to pretend their special interest group has a trademark on "open-source"

https://knowyourmeme.com/memes/old-man-yells-at-cloud

Even though they admit that trademark was denied

https://opensource.org/pressreleases/certified-open-source.p...


Everything is always fine until someone comes along and starts selling hosting of Open Source SaaS projects. I cannot talk for Zulip and I truly hope they will succeed with not relicensing or closing part of the software.


This strawman argument gets trotted out every time and every instance that I've heard thus far is exactly that. It's the "otherwise the terrorists win" of my profession

Ordinarily I would have gladly used Sentry's community and my good experience with its hosting and customer service as rebuttals but now ...


At one point Sentry was packaged with GitLab and bundled as a capability/extension of the GitLab suite of products (see "Error Tracking"): https://gitlab.com/gitlab-org/gitlab/-/issues/39701


You are misinformed; they implemented a Sentry-compatible endpoint if the Project enabled it: https://gitlab.com/gitlab-org/gitlab/-/blob/v15.0.0-ee/lib/a...

I feel perhaps you meant to link to https://gitlab.com/gitlab-org/gitlab/-/issues/329596 which describes their intention to accept Sentry formatted JSON payloads and store them in their own database. Searching for "no need" in that issue will highlight the number of times they were drawing a distinction between the effort required to run GitLab and the effort to run the 15 containers of Sentry self-hosted


In a commercial context, was this planned or some last ditch effort to get more users/usage?


We generally Open Source our stuff. When we acquired specto for profiling all the stuff was opened up as well either under Open Source straight away for SDKs and supporting infrastructure or time locked under the BSL.


Planned - this is how we operate at Sentry, it just took us a bit of time to get it ready to release


It's not closed source. They're source available. Which I would argue is better than both Open and Closed source.

It provides the flexibility of open source with the benefit of being supported and maintained by an actual company that has actual resources. There are percentage wise very few open source projects that have full time resources on them. There are so many tools/projects that if you report a bug to them that bug isn't getting fixed and if you create a PR to fix it it's nto getting merged because the maintainer has moved on with their lives and maintain it as a minor tiny hobby with 1-2 hours a month (if that) and there are tons where they've been taken over for vital maintainance only by a hardcore few that maintain lots of tools since the original maintainer has moved on. This annoys me about open source. It feels super unprofessional and normally we only get something that is maintained properly when it's closed source.


You can argue all you want, but it's not Open Source and even you agree about that.

Whether "source available" is better or not is an argument I don't really care about- it's just a red herring. The issue I have is companies claiming Source Available is the same thing as Open Source. I find that to be completely unethical.


> The issue I have is companies claiming Source Available is the same thing as Open Source. I find that to be completely unethical.

That is a fair point. It annoys me too.


You're taking an explicitly pro rentier stance here and seeking to shame a business model that actually supports the development of open source.

Youre on the side of embrace, extend, extinguish.

These licenses exist because rentiers like Amazon and Microsoft are using their hosting market dominance to charge rents on open source and undermining the business model of companies like Elastic Search that actually create it.


Oh please.

I am not saying they're required to be open source. I'm not saying they shouldn't be shared source. I'm simply saying they shouldn't lie about being open source. If CodeCov had the exact same license with the exact same restrictions, but didn't lie in their messaging, I wouldn't be commenting about it.


Oh please is exactly what I thought when I read your comment.

This is open source. It's entirely within the spirit of the movement.

The political imperative to twist the definition comes from tech monopolists, angry at a new wave of licenses that inhibit their ability to profit unhindered. You're getting outraged on their behalf.


Read the first line of the BSL license-

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

The only way you can argue that it's open source is if you're purposefully trying to deceive people.


Just don't fucking call your software open source when it's not open source. Don't try to leech off the goodwill people have towards open source by falsely claiming that your software is open source.


It's open source hated by big tech that undermines Jeff Bezos's goodwill.

It provides a revenue stream to actually pay developers to create more useful open source.

That's where the political imperative to gatekeep the term comes from.


It's not open source.

Many people find it easier (or think it's easier) to generate a revenue stream from selling closed source software than from selling open source software, so they decide to make their software closed source.

We need to gatekeep terms for them to retain their meaning. We can't just accept it when tech companies try to change the meaning of "open source" to mean "we published the source code so you can read it". The term source-available exists, and it means something different from open source. If these people announced that they're making their software source-available, everyone would be happy, but they're not.


What’s abusive about it? 80% of Sentrys source code is licensed under Apache-2.0 (and is how Codecov will be in a few years) which is far more than what everyone’s favorite open core companies have done.

Is it abusive to stop companies like AWS or GitLab from taking your work and selling it? Is it abusive to try to let as many people as possible use your software?

I’ll tell you what’s abusive - people thinking they have the rights to other peoples work unconditionally, or that they can profiteer off it without contributing back.


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.


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.


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.


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?


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.


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


"I've decided to become vegetarian. From now on I only eat meat on Wednesdays."

"That's not what vegetarian means!"

BSL is not open source.


To extend the metaphor though... only eating meat on Wednesdays is much better than eating it every day, and releasing the source and accepting contributions, even if under a licence not recognised as meeting the full open-source standards, is still much of the value.


Sure it's better, but if you do that and then call yourself a vegetarian people are still going to call you a liar. Nobody's objecting to the change, just the dishonesty.


Colloquially, almost all of the perceived value of "open source" code is that the source is available. Terms like "shared source" are unclear and not useful.

I think the constructive criticism is useful here, but for all but the most in-the-know this is open source as they see it, and describing it as such is just using terminology in the way that society has decided it should be used.

If you feel that the term "open source" has become meaningless as a result, I'd recommend using the term "free software" instead to mean software that is both source-available and licenced in a way that supports software freedom.


> Colloquially, almost all of the perceived value of "open source" code is that the source is available. Terms like "shared source" are unclear and not useful.

...terms like https://en.wikipedia.org/wiki/Source-available_software , OTOH, are exactly useful for describing what you seem to want, and are perfectly clear. As opposed to muddying the waters by trying to redefine an existing term.

> I think the constructive criticism is useful here, but for all but the most in-the-know this is open source as they see it, and describing it as such is just using terminology in the way that society has decided it should be used.

Right, which is why everyone in the comments here agrees with that. Are you sure your definition is the one that society is using?

> If you feel that the term "open source" has become meaningless as a result, I'd recommend using the term "free software" instead to mean software that is both source-available and licenced in a way that supports software freedom.

LOL - you think it's fine to redefine Open Source because of how you think most people read the term and "shared source" is confusing, but you think we should call Open Source "free software"? A term that every single non-techie will read as "gratis software"? That's a non-starter if ever I heard one.


In my experience, most engineers have barely any understanding of the licencing side of open-source, but all of them use GitHub for "open-source".

To me that indicates a change in the societal meaning, as much as I agree that it is incorrect.

You're right that people would and do mistake "free software" for "gratis", and sure that's something we need to work on. I just think the battle is lost with "open-source" and has been for a number of years now, and I can't fault a company, and specifically a marketing department, for getting on board with the way the term has changed rather than taking a principled stance.


I just responded with the same thing but think you said it in a better way!

https://news.ycombinator.com/item?id=36971490#36973675

This is open source to most of us. I can read the code, use the code, and contribute to the project. I don't care if I can't make a SaaS offering of it.


Completely agree, and if BSL allows the project to continue making enough money to sustain itself instead of being turned completely over to the community and risk becoming abandoned, then I’m all for it.


They are making an effort though. Public-available code and open source go hand in hand, even if they have overwhelmingly different principles.

They, as a business, found it more advantageous to make their product available to the public. There are of course business interests rooted in it, (like ending support for their paid product, or gaining free publicity/more sponsorships) but shooing away acts like these just make going open source all around a worse business choice.


I completely disagree with this- they aren't making an effort at all here, they're actively damaging a movement. They could have just said they were going shared source or one of the other "closed for use, but open for audit" licenses that exist. Instead they lied about what they're doing, and did so in a way that damages open source development.

Making an effort only counts as a good thing if they're making an effort to do good things. This isn't that though.


> shooing away acts like these just make going open source all around a worse business choice

I don't understand? They're not going open source so why is the reaction in this thread making actually going open source a worse choice?

You can't expect a good reaction when you announce that a product is now "Open Source" and then not actually use an Open Source license.


> They are making an effort though.

Releasing the source is nice but they shouldn't use deceptive language.

> found it more advantageous to make their product available to the public.

That's fine but they should call it something else.


The license switches to Apache after four years.

To complete the metaphor: “I will only eat meat on Wednesdays for the next four years, after which I will be 100% vegetarian.”

As someone who is annoyed anytime proprietary-licensed software tries to capitalize on FOSS terminology, I concede that being immediately source-available with a guarantee of being OSS within a reasonable timeframe is still better than we’re likely to get from the majority of projects.


Three years here (four is the BSL default).


Here’s the exact line from your license file:

Change Date:2023-06-29 2027-01-01

Seems like it should really be interpreted to mean the Apache license started applying on June 29, 2023.


(Addressed elsewhere in the comments, this is obviously a mistake.)


> BSL is not open source.

I love BSL, it's my license of choice for my projects. However, I fully agree it's not open source and it annoys me when others claim to be open source while using BSL. I specifically have the first question in my faq about being open source where I say it's not open source. I've had feedback that some people just stopped paying attention at that point and others where they found it refreshing it wasn't pretending to be open source.


Practically speaking from an enduser standpoint who:

- Likes to self-host stuff for homelab purposes

- Has business needs for shipping self-hosted services in airgapped and on-prem solutions where SaaS isn't available.

Every piece of BSL licensed software that I run (CockroachDB, Couchbase, MariaDB, Sentry, etc) are all open source to me. I can read the code, I can contribute, and I can track changes being added by others.

Your metaphor doesn't hold up because from an user standpoint this IS opensource. I'm not creative enough to come up with a good metaphor but it'd be something closer to:

"I've created a community book collection that anyone is free to take from. But you aren't allowed to take the books and sell them"


> BSL is not open source.

No, but Apache 2.0 is, which is what we revert to after three years. The better analogy would be, "I've decided to become vegetarian, starting in three days." But then actually legally guaranteeing that you'll follow through vs. always pushing it off into the future which is what it sounds like with the vegetarian example, I know I wouldn't believe myself if I said that. :D

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


Open source has meaning, and you're polluting that meaning. It would be one thing if you were honest about it, but by continuing to call closed source software open you're proving that this isn't just a mistake but is actually maliciousness on your part.

Just say "We're making our source public, and after three years our legacy code will automatically become open source". Don't claim you're making something open source, but then have all these nasty hidden caveats. It's dishonest.


Feels like a spirit vs. letter conflict. When we say "Codecov is now Open Source" we sincerely mean it at face value. We think we're embodying the spirit of open source. If the letter doesn't jibe then let's change it together.

Also feels like we'd have to take this conversation to a video call or something to make any further progress.

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


I don't understand how the "head of open source" software can claim that a license which literally begins by saying it is not open source, is in fact open source. You're right gaslighting the community or you're engaging in self delusion.


I think just changing the title from 'CodeCov is now Open Source' to 'Source code of CodeCov is now available', it conveys the same spirit and meaning, without any misleading parts


The letter reflects the spirit valued by the community, OSI, and FSF. You are free to choose a different term to reflect a different spirit.


IMHO it's also dishonest to claim there is "one true definition" of the term "Open Source", when in fact 1) there have been a zillion discussion like this now, which demonstrates this consensus doesn't exist, 2) "Open Source" has seen usage going back to as far as 1985 at the least.[1]

All of this is reminds me of the "if people keep misusing your design, then it sucks"[2] story from the other day. If you don't want people to "misuse" [common and obvious adjective] + [common noun] then choose a better term.

[1]: https://www.arp242.net/open-source.html#pre-1998-usage

[2]: https://news.ycombinator.com/item?id=36939648


The problem is that your colleagues chose to write, "Codecov is now Open Source". They didn't write, "Codecov will be open source in years 3.417* years".

* January 1, 2027


And until then you can do whatever you want except build a competing business, and if you're that eager to build a code coverage business then you should just come work with us lol.

https://sentry.io/careers/


I think the BSL constitutes as Open Source. I’m obviously biased here as someone working at Sentry but here is my reasoning. If you download source today and just wait long enough it is 100%, unquestionably Open Source as per OSI Definition.

There are projects that only release Open Source licensed code in very irregular intervals and they are still Open Source. BSL is rolling Open Source with delay.


I'm sure I'm going to regret weighing into this, but the reason your "with delay" means it is not open source in my mind is that:

- it would require a fork since there is no way Sentry (the project stewards, not the company) is going to review and merge 5 year old code [I'm aware there's already a pseudo-fork but this bullet is to highlight what _contribution_ means in the context of 5 year old code]

- if I'm using Sentry today, and I find a bug or want to submit an improvement that scratches my itch, I donate that work to Sentry the corporation

- if corporate raiders continue to appropriate the term Open Source to mean "whatever marketing says we can get away with claiming" then in dilutes the goodwill from companies who really do use Open Source

I have an special bitterness in my heart for companies that start out with a FOSS license and then rug pull to a non free license. I will never forgive you nor SourceGraph for that betrayal


In practice the first point relates to the second: on many projects you need to accept a CLA which gives the original right holder more permissions. That is entirely separately from BSL or else. That is not a donation.

In practical terms most of Sentry at this point is fully Apache 2 licensed.

> I have an special bitterness in my heart for companies that start out with a FOSS license and then rug pull to a non free license. I will never forgive you […] for that betrayal

BSL is for me personally something I can fully stand behind. I understand others do not and I cannot change that. However I believe we all in the Open Source community need to find better ways to have commercial and Open Source community incentives to align. BSL is the best I personally found so far.

It means we can work in the open, don’t need to do things we would not stand behind to protect the business etc. You can today like 10 years ago do what you want with Sentry what you want.

> I'm aware there's already a pseudo-fork but this bullet is to highlight what _contribution_ means in the context of 5 year old code

The rolling Sentry commits are already ahead of the ancient BSD forks I’m aware of.


>BSL is rolling Open Source with delay.

.... which means it's not open source.

The "irregular interval" companies general release the source at the same time they deliver a new software version. It's not a fair comparison at all, since you can always get the open source code for the software you're running.


> I think the BSL constitutes as Open Source.

Did you even read the license?

Literally the first line of the "Notice" section:

"The Business Source License (this document, or the "License") is not an Open Source license."


Dogmatic idealism is the enemy of progress.


Would you rather they just keep their source completely closed then?

I just don’t understand the criticism of a company transparently acting in its best interest (in what I would consider to be a completely reasonable way).


They could just as easily word the press release ETL be “… releasing the source code”.

“Open Source” has a specific meaning. It’d be like saying “…is now free!” with “free” defined as some price I consider to round to zero. It’s clearly misrepresenting the word which has a specific meaning.


'[Old versions] will be open source' would, I think, also be a fair description. Right now it's source available proprietary freeware; in three and a half years it (specifically, the now-current version) will be open source.

For this reason, I think the Business Source License (BSL) (with an Open Source Change License) is less nefarious than the Server Side Public License (SSPL).


> Would you rather they just keep their source completely closed then?

I just want them to stop using deceptive language.

> I just don’t understand the criticism of a company transparently acting in its best interest (in what I would consider to be a completely reasonable way).

They are lying in order to benefit from the good will and legitimacy that open source brings.


> Would you rather they just keep their source completely closed then?

What you are doing right now is a pretty transparent motte-and-bailey <https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>

Don't do that.


BSL is a heck of a lot closer to "open source" than to "closed source".

It's open source, except that you can't use it in a competing commercial product. So for 99% of uses, open source.


There's a term for that already: source-available.


Correction: "CodeCov is now Source-Available for Noncommercial Use"

Literally the first line of the BSL: "The Business Source License (this document, or the "License") is not an Open Source license."


> The code is available now for you to run for yourself, study, modify, and redistribute in original and modified form. The BSL means you can’t sell hosting, but after a period of time the code reverts to the OSI-approved Apache 2.0 license.

That's pretty good, to be honest.

Congratulations!


Thanks! I wrote that part, referring of course to https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms and trying to be as straightforward as I could.


And yet you couldn't change the title to be less deceptive? "Open Source" means unhindered distribution, including for commercial use. Given that you're citing GNU, you should know better.


We have updated the language on our blog post to the more commonly accepted “open-source” terminology.

I’d encourage everyone who cares about OSS to participate and consider the changes happening in the broader technology sector. Sustainability is more important now than ever in the ecosystem, and we need to evolve our thinking and tolerance. We need to look deeply at the goals of open source and how we can continue to achieve them, and that isn’t going to be arguing about what once was.

Many of the Sentry folks who have chimed in here (including myself) are not here because they work for Sentry, but because they have contributed to open source for the better part of their careers, and many of us in very significant ways (certainly with software you’ve used). We care about improving and protecting the ecosystem. It does no one any good when this community is hostile towards the folks trying to help.


Listen, you can (and should!) use whatever license you feel works best for your business.

But the trickery around calling the BSL "Open Source" (now "open-source") in the blog post is a very bad look.

The BSL license - in your own repos [0] - has this text:

> The Business Source License (this document, or the "License") is not an Open Source license.

The "change date" is 2026-06-31 and the BSL allows one, at that time, to re-license under a real open source license.

What you're doing amounts to a pre-announcement of open sourcing something 3 years from now. To say it's "now open-source" as the blog post currently claims is quite misleading.

[0] https://github.com/codecov/codecov-api/blob/main/LICENSE#L25


Perhaps the real trickery is the OSI's shady lawyer led campaign after they were denied the trademark on open-source(tm)

https://opensource.org/pressreleases/certified-open-source.p...

And after they had admitted that:

> While there is agreement on the broad term "open source" as meaning approximately what is captured in the Open Source Definition the term has, ironically, now become so popular that it has lost some of its precision.

https://web.archive.org/web/20060411080543/http://www.openso...

To pressure developers that believe in "open-source" as in the opposite of "closed-source", to also accept their entire anti-developer property "Free Software" ideology.


> We have updated the language on our blog post to the more commonly accepted “open-source” terminology.

What are you talking about? That doesn't fix anything. It'd have been closer to the truth (and physically easier) to update it to say, "Codecov is not Open Source".

"Open Source" and "open-source"[1] are not two different things. You're just rearranging the deck chairs. Using the latter form doesn't soften the transgression.

In an earlier comment[2], you insisted "Our goal is not to argue about proper nouns". Yet... here you are. Why?

Just fix your mistake.

1. <https://en.wikipedia.org/wiki/Open-source_software>

2. <https://news.ycombinator.com/item?id=36973452>


Open Source, as a proper noun, is generally considered associated with the OSD from OSI. We are trying to clarify that what we’re representing is not that definition, but are representing what we feel is the spirit of open source software.


I fear this is an instance of that old Upton Sinclair/H. L. Mencken quip—never be so foolish as to waste your breath believing that you can get a man to understand something which his salary requires him not to understand.

Engage with the argument you are being confronted with.

There is no difference between "Open Source" and "open-source". The former is generally associated with the OSD, and the latter is generally associated with people who insist on hyphenating* things—but are referring to the same thing; there is no "open-source" definition that is more relaxed than the "Open Source" definition. You are lying if you want to pretend that there is a widely recognized difference. There isn't.

The problem never was that you're using the Business Software License. The problem is that you are _lying_.

So stop lying.

It's that easy.

* EDIT: And removing the hyphen[1] doesn't fix anything. You have been through no fewer than four different variations of the title at this point[2][3][4]. The hyphen is not the problem. The problem is that you are lying. Try just not doing that.

1. <https://archive.is/XJz9r>

2. <https://archive.is/aSH9K>

3. Unarchived version that used lowercase "open-source" with a hyphen, cf <https://news.ycombinator.com/item?id=36974314>

4. <https://archive.is/XJz9r>


So why did the OSI write this?:

> While there is agreement on the broad term "open source" as meaning approximately what is captured in the Open Source Definition the term has, ironically, now become so popular that it has lost some of its precision.

https://web.archive.org/web/20060411080543/http://www.openso...

Why did the OSI apply for a trademark on the term Open-Source?

Why does the OSI continue pay the trademark registration fee to renew the unambiguous term "OSI Approved License" and why don't you adopt that term?

Perhaps because both you and the OSI know that when you focus on the term "OSI Approved Licenses", it's just another word for "free software", and most people that are interested in "open-source" are interested because it's the opposite of "closed-source", not interested because they want to associate with the FSFs anti-developer property ideology.


> So why did the OSI write[... ¶] While there is agreement on the broad term "open source" as meaning approximately what is captured in the Open Source Definition the term has, ironically, now become so popular that it has lost some of its precision.

That passage says two things:

1. "open source" means what OSI says it means

2. there are people like OP who exist

OP does exist. That's a self-evident and indisputable fact. Were you expecting me to argue otherwise?

Acknowledging that it's true, however, is completely different from saying that the definition they're using is widely agreed upon or that there is a difference between "Open Source" and "open source" that is wide accepted. (The first sentence in that passage actually says the opposite...)


You can literally make the same argument back to yourself, given _I_ and many others agree with the statement I made. Your opinion is fact but mine is opinion?

We’re not going to agree - that’s fine — but I’m not a liar. I’m simply stating our intent. We will keep pushing sustainable open source forward, and hope others will help.


> Your opinion is fact but mine is opinion?

No. Opinions are opinions, and facts are facts. Mixing them up is a type error.

It is not an "opinion" that if someone were claiming that there is widespread agreement of a distinction between "Open Source" and "open-source" (or "open source") then that is untrue—because that's how facts work: they are either true or they are untrue.

It's my opinion, on the other hand, that you guys are willfully dishonest and just kind of scummy, and so it is also my opinion that neither I nor any company I work at now or in the future should ever do business with you.


There should be a distinction between FOSS and OSS. Nobody is trying to infringe on your FOSS rights. But some may argue the term OSS has changed to not strictly mean FOSS. The term "open source" at face value only implies "source available" until you read the license.

Ask 1,000 developers and I'd bet real money the majority would say projects under BSL and other non-"OSI approved" licenses are "open source." Not FOSS, but OSS.


In my experience most people think of open source as free plus source available. The average user doesn’t care much beyond that, which is supported by people’s willingness to add just about any dep to their software without validating licenses. No one will ever agree on terminology, but for me personally BSL is in the same category as GPL in that it achieves a bunch of the core principles, has less consequence, but also only works for certain types of software (eg sentry not libcurl).


> for me personally BSL is in the same category as GPL

Cool. So use the GPL, then.

Previously: <https://news.ycombinator.com/item?id=36973417>

> No one will ever agree on terminology

K. And "no one" will ever agree that evolution by natural selection is responsible for the origin of species. Dang. What a pickle.


> I’d encourage everyone who cares about OSS to participate and consider the changes happening in the broader technology sector. [...] We need to look deeply at the goals of open source and how we can continue to achieve them, and that isn’t going to be arguing about what once was.

This isn't a change to achieve open source goals, this is redefining the goals of open source to suit your business interests. You want to take the positive marketing of open source and use it without taking the same risks, by affording the fundamental open rights, which other actual open source projects take. It's not that folks don't respect your right to protect your business interests via the license, but you simple don't have to use the open source term to do that, attempting to redefine what folks love in the process.


> Come on in. Codecov is now open (source).

Literally made me LOL. Because I know the feeling.

I went with "open, source available" for my business. I like yours, too.


That reeks of <https://lwn.net/Articles/82305/>.

It's not clever. It's not snatching victory from the jaws of defeat. It's just deceptive.


After reviewing the feedback (some of it from yall here), we recognize the challenges with using the term Open Source. We've posted a statement about this mistake and are working on improving things going forward:

https://blog.sentry.io/lets-talk-about-open-source/

For the folks who provided constructive criticism, we thank you.


FYI we have a follow-up at https://blog.sentry.io/lets-talk-about-open-source/.

> Yesterday we announced that Codecov is now “Open Source”, and we messed up in two ways:

> - We wrongly used the term Open Source; while unintentional, we should have known better

> - We let our emotions get the best of trying to explain our position, rather than stepping back and addressing the problem

> I want to talk about both of these, how we made the mistake, why it’s important to us, and what we plan to do about this to improve the conversation in the future.

HN post: https://news.ycombinator.com/item?id=36990036


Well, that puts a damper on my plans to release an alternative OS coverage service.

Now I can just use CodeCov.


After a couple of decades of development I must say I personally find integration tests more useful than unit tests

I mostly only do unit tests for things which are very "logic intensive" like a parser and such things. I think a good rule of thumb is if writing unit tests during development actually helps me with development the tests are probably also useful during the development cycle.


I agree, and with integration tests I find coverage reports even more useful, because it's not always immediately obvious what is and isn't tested from a high level.


Hey, I think I thought of a way to make everyone happy here: Why not dual-license it as AGPL / BSL-Apache? That way it is Open Source right now, but under the AGPL so AWS won't touch it, and then in 3 years it also becomes available under the more permissive Apache license.


Personally most of us at Sentry who made these decisions don’t like the invasive open source licenses. It was between this and allowing others to sell our software (which is very demoralizing), but we didn’t want to limit adoption and some companies won’t run GPL software due to the risks.


Right, so dual license it to allow both


If you look at it from a high level, Sentry wants to have their cake and eat it too. They don't want to promote GPL/AGPL open source development because it's harder for them to profit off of it, but they don't want others to profit off of their work which is why they're sticking with a "source available" license.


I’m not sure why you’re 20 comments deep on HN, but we forbid (like most companies) GPL software. It’s no harder to profit off GPL than it is Apache, but GPL is a disease that plagues the technology world. There’s a reason we convert our code (and release most code) under Apache and that’s because it’s true FOSS. GPL has strings attached just like BSL.

Clearly we hurt your feelings somewhere on the past, but let’s not go around spreading falsehoods.


> Er, what? GPL is completely fine for corporate use; it doesn't even trigger until you distribute to third parties

A lot of us distribute software. It’s not an outlier, it’s the majority. It may have been a different concern 20 years ago, but software and adoption has changed dramatically.

> It really doesn't. And if you're at a point where you're arguing that BSL is Open Source but GPL isn't... on the bright side, there's no point in arguing after that; you're clearly in a different world than the rest of us.

I’m not. I’m saying that it’s odd to be able to justify GPL as open source yet be unwilling to consider something like BSL as part of the ecosystem. Both have serious restrictions, albeit different. Neither let you “do whatever you want” which some might write is true FOSS.


> but we forbid (like most companies) GPL software.

Er, what? GPL is completely fine for corporate use; it doesn't even trigger until you distribute to third parties.

> but GPL is a disease that plagues the technology world. There’s a reason we convert our code (and release most code) under Apache and that’s because it’s true FOSS. GPL has strings attached just like BSL.

It really doesn't. And if you're at a point where you're arguing that BSL is Open Source but GPL isn't... on the bright side, there's no point in arguing after that; you're clearly in a different world than the rest of us.

> Clearly we hurt your feelings somewhere on the past, but let’s not go around spreading falsehoods.

Let's also not go around making unhelpful ad hominems.


> I’m not sure why you’re 20 comments deep on HN

Why are you?


We explicitly _do not_ want to promote GPL as we do not believe in it as the right tool. It’s not exclusively around protecting ourselves, but also how we do it. Decisions like this are more rooted in what we think is right for the world than a business demand (tho BSL for us, the decision to move off BSD, was triggered by what some companies were doing).


I think we need a new term for licenses like these that are not quite open source. Saying it is open source is deceptive and erodes the meaning of open source, but they are also more open/free than just "source available" where the source code is available but you have no rights to do anything with it (although I've seen cases where even that is advertised as "open source").


But how does that compare to SonarQube's code coverage?


My [very biased] $0.02:

If you need only coverage on the most recent git diff / patch + looking at the repo level coverage on the head of a branch, both do a reasonable job.

Codecov's focus on code coverage largely branches off on:

-- Tracking the git tree (comparing base to head of a PR) --> e.g., how much did test coverage change on this branch / PR

-- Supporting monorepos: Demarcating by test type ("Flags") and team/module ("Components") so you can focus only what you care about vs. the full repo.

-- Supporting partial test runs: Codecov lets you run only some of your tests and still show accurate overall coverage data.


Considering this is a service completely focused on it, pretty well I imagine.


If you find something they do better, let us know!


People often claim that open source is more secure, which is implied in this release. But the CodeCov breach that leaked any secrets provided to CI/CD pipelines [1] was done via a bash script available to anyone to read the code. The breach wasn't complex at all. It was just that nobody noticed for a long time that the bash uploader script sent all secrets to a random IP address.

It makes me wonder what the benefit really is to being open source. Is it just marketing?

https://about.codecov.io/security-update/


It’s not about security for us, but about accessibility of technology. Open source lifts the barriers on who can use software (eg outside of politics, compliance, etc), and enables knowledge share. It’s - from Sentrys angle - how we enable any developer to take advantage of our technology, hopefully enabling them to solve other problems and grow the industry.


So cool to see the CTO of Sentry here! This makes some sense to me - I'm actually following an issue with Sentry I had recently and although it's not being fixed anytime soon at least I know the status.

https://github.com/getsentry/sentry-python/issues/370

I'd love to believe that one day someone will crack the nut of "Sentry puts a bounty on this issue and YPCrumble decides to make a PR because it's something he's experiencing AND he'd get some experience working on the Sentry codebase which would be a learning opportunity, and he feels like he's getting paid for his time."


Will make sure folks see this internally. Thanks for the feedback!


Open source does not magically make your software more secure. Community needs to audit the code if they are going to use it instead of trusting blindly.


What can I do with this being open source if I cant use it for a competing service? Run an inhouse instance?


Yep. And that's great!


Yes, personal/in-house use.


Oh come on. You are being angry at the wrong target. If you become angry about this technically not being "open source" (by the OSI definition) you are just helping the rent-extracting monopolies in Big Tech to steal more.

The OSI definition was accepted due to corporate lobbying and I imagine this probably also includes astroturfing to apply pressure on companies who don't go "all the way" and basically subsidise their competitors for free.

This gives me strong ElasticSearch vibes - everyone got mad at Elastic for changing the licence, and no one gave a damn about Amazon building a moat around the technology, profiting massively from it yet leaving the burden of maintenance to Elastic.

Anti-disclaimer: I have zero affiliation towards this project or company.


Sentry is one of the rent extracting companies. They want to extract value from the open source community, including marketing value, without actually being open source.


How so? You can use it for free without paying rent. You just can't compete with them without paying.


Not to mention any reasonable competitor is using our FOSS-licensed code to compete against us (such as our symbolification services). There is nuance and people don’t care about that. We will keep shipping.


Where is the "extracting value" part? If you mean "calling their product open source while you think it is actually not" that is a really weak justification. By extracting value I literally mean using open source code as a SaaS model then not contributing back anything. Getting angry over names is not seeing the forest from the trees...


So in your view, what is the opposite of "closed source"?

Is your definition the one that 99% of English speaking humans would agree with?

Why should the opposite of "closed closed source" be one groups ideological checklist, that's really an offshoot of "free software", a radical, anti-property ideology that is generally not accepted - and thus the GPL licenses are generally unpopular.

Why does the OSI bother to maintain a trademark on "OSI Approved License"? Isn't that hypocritical? If not, why not?

In my view, the OSI does have value, and "OSI Approved Licenses" are useful to know about, just like "FSF Approved Licenses" are good to know about... But they should not pretend to own language and have trademark on "Open Source" when the USPTO denied them a trademark:

https://opensource.org/pressreleases/certified-open-source.p...

Also, there is extensive documented "prior to 1998" use of the term "open-source" meaning exactly "the opposite of closed-source", rather than someones ideological checklist:

https://www.arp242.net/open-source.html#pre-1998-usage


Btw I think you are replying to the wrong person, from your post it looks like you wanted to reply to my parent.


> I imagine this probably also includes astroturfing to apply pressure on companies who don't go "all the way" and basically subsidise their competitors for free.

I think you are exactly correct.

It's deeply disturbing that the OSI out of one side of their mouth says "indie developers, you should forgo any right to your own software or not truly open-source" and out of the other side of their mouth collects donations from giant internet monopolies that freeload...

MIT/BSD/Public Domain licenses long pre-date the OSI.

The FSF is it's own thing...

What's even the point of the OSI beyond trying to pressure developers to drop their creations into the public domain to be stolen?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: