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.
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.
> Software that has source code available that automatically becomes open source at some explicitly specified, unchangeable, point in the future.
FWIW that's what I call it, but that's not exactly a well known enough term.
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.
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.
You may think it's purely an apolitical question of definition but it's about as apolitical as saying "Crimea is part of Russia".
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?
Then title the blog post, "CodeCov will eventually be Open Source" instead of being deceptive.
"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
Ordinarily I would have gladly used Sentry's community and my good experience with its hosting and customer service as rebuttals but now ...
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
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.
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.
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.
> > 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
- 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.
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...
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.