Open-Source Washing
github.com
github.com
There's plenty of room for arguing. The FSF, in fact, approves a few licenses that OSI doesn't.
I think when someone says there is no room for argument, they are just signaling that they aren’t open to being convinced of anything. Which makes discussion a bit of a dead end.
The whole discussion here is about semantics. What does "open source" mean? I think having a clear definition of "open source" (at least when it comes to software) is a good thing for the world and for the community. It helps us communicate to have the OSD definition. If "open source" changes its definition to no longer require no restrictions on usage, we have lost a good and useful term that will make it harder for the "real" open source community to communicate.
By analogy, imagine if some people started arguing that ceasar salads (with chicken) are vegetarian, because salads contain mostly vegetables. Wouldn't it be reasonable for everyone to resist that semantic drift? The term "vegetarian" would lose both its history and its usefulness.
Those who state historically accepted definitions in strong terms are trying to resist semantic drift. It doesn't mean "they aren't open to being convinced of anything", that's a bit uncharitable. It means they aren't open to semantic draft regarding this term.
A very fun thing is to look up word origins of words and terms I care about. There’s often a revealing or thought provoking history.
One of my favorites is the German word “enttäuschen” which means to disappoint but has a different original meaning.
However what irks me is when interest groups try to force a semantic change in order to fullfil a typically financial or political agenda.
Terms that have a positive connotation like “Open Source” need to maintain a degree of integrity in order to stay useful at all.
There are some things vegetarians disagree on: eggs, dairy, gelatin, etc.
This is an absurd interpretation from someone who does not understand why people actually even care about Open Source.
Any license that meets the currently accepted definition of "Open Source" should be considered "Open Source" (tautological, I know). Whether it's in a list by some organization or not is mostly irrelevant. Having the OSI list is useful only because it helps people check whether a certain license adheres to the definition or not... but if the license is not in the list, you could still check yourself whether it meets the definition, and if it does, it's Open Source.
Now, one could argue about who "owns" the definition of Open Source... well, then yes, I would agree that OSI's is the most widely accepted definition and everyone does well to try to follow that. That does NOT imply only OSI has the right to claim a license is open source!
And that's the problem. I'd say anything between (and including) "Source is available" and "only Free Software" is sufficiently common.
Then put it out as open source.
Makes sense.
Or like Nvidia's new drivers which are "open source", but all the meaningful parts are either buried in the card or in closed source libraries?
Or like VSCode where the plugins which matter are closed source and it's "open source sibling" VSCodium is banned from using the majority of the plugins?
If the 99.9999% of the tool is open source, but non-functional without that closed bits, can we say the software is open source?
The four freedoms matter, and this is what OSI says, too.
Licenses are legal text by nature, and some of them are pretty convoluted. I can write an open-source license with a sneaky retroactive licensing loophole, and create problems for anyone forking/using my code with that theoretical license. Similar landmines can be implemented in bad faith or loopholes can be found in good-faith licenses (TiVoization, anyone?).
So, just because a license satisfies four freedoms doesn't make a piece of software "Open Source". So a body examining licenses and saying that it's acceptable or not is a good thing to have.
We have been reinventing things and damaging tons of stuff just because we feel like having established things is bad to start with.
It wasn't clear what your intent was when you presented your example, since it does not actually illustrate your point. A piece of software consisting of a proprietary blob coupled with a minimal open source launcher is closed source as a whole because the majority of the software is closed source. That software does not satisfy the four freedoms, and is therefore not open source.
> So a body examining licenses and saying that it's acceptable or not is a good thing to have.
Yes, the OSI and FSF are important for establishing clear standards, and for helping developers and users identify exactly which licenses meet those standards.
A nice example: Try to "run" GitBook in a self hosted manner. You're free to do that. The code is out there. The license allows it, but there's no docs, and code is a landmine, probably.
As I said before, try to use VSCodium in a useful manner. You won't be able to do that. You can incorporate parts of it to your tools, but it won't work as well as the "closed source, official" VSCode, because it's designed to be like that [0].
So, saying that every license allowing four freedoms is an open source license, or even saying that "every application which has a valid, vetted Open Source license" is Open Source software is a stretch nowadays.
Lastly, we seen that not many companies thought about the ramifications of open sourcing their code properly. Elastic & HashiCorp are just two examples we made some noise about.
VSCodium does exclude the proprietary features of Visual Studio Code, but I don't see how that should disqualify VSCodium from being open source. (I use VSCodium frequently and I am satisfied with its feature set, so I strongly disagree with your claim that it is not usable in a useful manner.) VSCodium is also maintained by a community that is not sponsored by Microsoft, so I don't think it's fair to say that it is intentionally designed to be inferior to Visual Studio Code. We both agree that Visual Studio Code is not open source.
Elasticsearch (Elastic License, Server Side Public License) and HashiCorp (Business Source License) have adopted licenses that do not provide the four freedoms, and the software licensed in that way is not open source.
VSCodium may be open source in theory, but it's designed to be deployed in a less functional fashion than VSCode, more like a "Freemium", hence the "Codium", ringing me like "-ish", or "looks like". It's designed as a funnel. Yes, it's there, and it works, but it funnels users to Microsoft's closed version. Or you can embed it as an editor to your project, but not much more. I'd rather use KATE, Eclipse, Vim, Emacs, etc. Instead of it. Heck even Atom or its current incarnation is better.
Zed is also like VSCodium. The tool is "Open Source", with a proprietary backend and egregious data siphoning capabilities. It backstabs you, and being open source changes nothing.
I have given Elastic and HashiCorp as examples of companies using open source as a way to get support and traction in the early days, and back-pedaling when things didn't go as their plan. Whether this is calculated or not is another matter, but they look like they didn't fully think it through.
> VSCodium may be open source in theory, but it's designed to be deployed in a less functional fashion than VSCode, more like a "Freemium", hence the "Codium", ringing me like "-ish", or "looks like".
VSCodium is not "designed" to be less functional, since it is a project maintained by developers who are unaffiliated with Microsoft. VSCodium is an application that is "deployed" in the exact same way as Visual Studio Code on the desktop. The name VSCodium is a nod to Chromium, not "freemium".[1]
Using the Chrome analogy, Visual Studio Code is like Chrome, proprietary and closed source. Microsoft's "Code - OSS" repo[2] is like Chromium, and serves as a functional open source base for the closed source software with the proprietary client-side features omitted. VSCodium[3] is like Ungoogled Chromium,[4] with both being community projects unaffiliated with Microsoft/Google. VSCodium takes "Code - OSS", strips out the telemetry, and uses the Open VSX Registry[5] for extensions by default instead of Microsoft's proprietary Visual Studio Marketplace.
> Or you can embed it as an editor to your project, but not much more.
Have you ever used VSCodium? It's a full editor that includes almost all of the features of Visual Studio Code. It does not need to be embedded to be used.
> Heck even Atom or its current incarnation is better.
You're entitled to your own opinion, but Atom was developed by GitHub, which was acquired by Microsoft. After the acquisition, Microsoft diverted development efforts to Visual Studio Code, and both VSCodium and "Code - OSS" currently run circles around Atom in both performance and features. It doesn't help that Atom was discontinued last year, with the final version having been released in March 2022.[7]
[1] https://github.com/VSCodium/vscodium/issues/28
[2] https://github.com/microsoft/vscode
[3] https://vscodium.com / Source: https://github.com/VSCodium/vscodium
[4] https://github.com/ungoogled-software/ungoogled-chromium
[5] https://open-vsx.org / Source: https://github.com/eclipse/openvsx
In today's (OSS) world, employment or affiliation doesn't matter much. Microsoft can propose what they want and get what they want from the project, at the end of the day. I don't think these independent maintainers have power to say "No" (if a VSCodium developer can chime in here, I'd love to be stand corrected), or they risk VSCodium to be forked to VSCodiumX, by developers who are friendlier to the megacorp which loves Linux.
Yes, VSCodium is a node to Chromium. "-ium" has a ring akin to "-ish" in today's conjecture. Freemium - Free-ish but not. Chromium - Chrome-ish but not. VSCodium - VSCode-ish, but not. This might be curse in the naming, but it feels, looks and works like that, in practice.
The blog post I linked (for further reference, it's [0]) quotes a tweet which supports what I'm saying, heck even the blog post does a much better job of detailing what I was trying to say here in my previous comments.
To circle back, the problem with -ium projects are, they are effectively banned from participating in the main ecosystem which drives these projects forward, and to be in "The Ecosystem", you need to use the closed source versions with pervasive data collection and whatnot. Heck, even Google abuses Chromium with "Experiments and Proposals", which they use to politely yet forcefully push the web to the places they want. VSCodium is the same getaway drug and test vessel for Microsoft.
Lure with Open Source version, trap with closed source version for "Full Benefits" (for the company, because user is the product).
> You're entitled to your own opinion, but Atom was developed by GitHub...
Yes & yes.
> which was acquired by Microsoft.
Yes.
> It doesn't help that Atom was discontinued last year, with the final version having been released in March 2022
However, it's forked as Pulsar [1], which I meant by "current form" in my previous comment. Again, it's MIT licensed, and that's not my favorite, but at least it's not a company editor now.
Atom's original developers started to build Zed, which is worst of both worlds currently (Open source with a closed backend, plus "All your data belong to us" clause).
At the end of the day, from my perspective "-ium" projects and their sanitized versions are just open-core versions of the "main tools" developed from them.
Just because these versions somehow work, and have a permissive license doesn't make them open source in the meta sense. Pedantically they are open source software, yes, but they are just the "Open Core" or Demo/Shareware versions of the tools which companies use to strange to ecosystems.
This is just enshittification of open source in my eyes.
More power to you if you're happy with the -ium tools, but I'd rather use truly free software (Like Eclipse), or use completely honest closed source software (like BBEdit), instead of using tools designed to look like open source but not.
Corporations (ab)using permissive licenses to lure people to give away their code for internet points, and many of the same companies do not give away the code they improved upon. Even GPL is violated by some firms and they deny to obey it when they caught red handed or even flat out accept that they violate it and don't change their behavior.
Same corporations scare people away from strong copyleft licenses solely because it doesn't help their bottom lines, but they tell other things instead of admitting that they want free labor. Sometimes they even "sherlock" an application by inviting the developer to headquarters, luring them to talk about the design, re-implement it, and be very reluctant to even thank the dev whose dearest project is killed with a one swift lightsaber swing (read "The day AppGet died").
After seeing all this brouhaha and sinister motivations, muddying Open Source software and redefining it to "Software which is developed by enthusiasts which are lured by GitHub stars, permissively licensed, used by corporations and never supported back", and a couple of very successful projects with wise BDFLs, I'd prefer to have a trustworthy BDFL instead of institutions with varying motivations and agendas.
While we talked about GitHub, then there's whole CoPilot saga which crawls open source repositories, and conveniently forgets to understand what licenses mean, but I digress.
At the end of the day, Free Software (and even Open Source Software) is an idealistic endeavor first, and companies don't care about anything which is not money.
Consider the existence of casual or 'crayon' licenses. They might meet common definitions of "open source" in plain-english, yet, it could be questionable as to whether they would be enforced that way in a court, either due to lack of real world use or due to legal issues with their construction.
The question, "does a license which says it meets the definition of open source, but might not actually be enforceable" is not one that open source advocates agree on, even if they agree on the definition.
There's a better way to do this. Epic licenses Unreal Engine in a simple way. You sign up and you can download it. That's free. Until you have a game that makes at least a million dollars, it's free to use. Then they want 5% of revenue. If you're successful enough to reach that threshold, they'll find you. The game industry has good sales visibility.
- Right off the bat, the Venn diagram is wrong (with regard to the author's thesis that there is only open source and proprietary) since it suggests that there is "source available" that is not proprietary (outside of the proprietary bubble) and not open source (outside of that bubble). Why draw a diagram that doesn't follow your rhetoric?
- "any software whose license doesn't belong to the OSI's list is proprietary software" is just ridiculous. He's literally saying that if you hire some lawyers and create a new FOSS license, it's proprietary because it doesn't appear on OSI's list.
- "All licenses on this list are guaranteed to adhere to a fixed set of criteria. These criteria guarantee four essential freedoms:" is just off the cliff. He's claiming that all the OSI licenses jibe with the GNU Projects or Free Software Foundation's definition of free software. A counterexample is any BSD or MIT licensed software which has users that do not have those freedoms due to receiving only a binary. Both OSI and FSF agree that those licenses are, respectively, open source and free, but the FSF will not agree that those licenses preserve those freedoms. BSD-licensed software is free because it's GPL-compatible: a GPLed program can use BSD-licensed pieces. Since OSI burst on the scene some quarter century ago, pushing the open source rhetoric and agenda, they permanently locked horns with Stallman and his Free Software crusade. The OSI has its own definition of what is open source: https://opensource.org/definition-annotated/
The obvious conclusion is that the author is barely starting to be knowledgeable in this area.
And, no, software is not exhaustively partitioned into open source and proprietary. A binary executable (or ROM image or whatever) can land into the public domain. Then you have non-proprietary code that isn't open source because there is no source.
Indeed, "open source" taken at face value could be interpreted as "source available", but given the historical context, that's not what the term intends to represent.
It's because of this dissonance that I think it's important to make differences clear. Perhaps "free software" has always been a better name, but I think the community needs to come to an agreement on this.
Most people see free and think without cost.
So is shareware free software?
The first sentence says:
> Open source doesn’t just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
In particular, all commercial usage must be allowed, otherwise, it is not open source.
The copyleft requirement of GNU licenses restrict what a developer and/or company can do with the code since it forces them to make any derived code public... Which is generally undesirable for commercial projects; especially early in their lifecycles when bugs may be present and would be best kept private until the project has been more battle-tested.
GPL licenses are a good way to ensnare businesses and then up-sell other software licenses that are more suited for commercial use.
The copyleft requirement restrict what others developers can do with the code. If they don't like it... well, who are they to use the code at all?
Copyleft only kicks in on redistribution. If you're only testing internally, you don't need to distribute source code. It's only once you distribute that software that you also need to distribute source.
The IP (intellectual property) of the code has no relationship whatsoever with the IP of the content being served by the served.
> where is the distribution?
You setting up a production server counts as “distributing the service” in AGPL's definition, as AGPL is aimed directly at the SaaS business model.
So if you use an AGPL software on your server, you need to provide the source code (including any changes/customization you've made) to your users. BTW this is a common misconception with GPL, nobody forces you to publish the code in public like on github or anything, it could be behind a login form reserved to your customers only. But you need to give them to your customers under the same AGPL license, so if they want to publish it on github themselves, or fork it and make a business out of it, they can.
Most don't require it, agpl3 does.
(Edit Agpl3)
That used to be true, but AGPL changed that. Now it can kick in if you let others interact with the program on your computer.
Yeah, exactly like a ban on slavery means less freedom for those who would own, beed, and rent out slave labour. Are we supposed to cry at this evil restriction in the freedom of would-be slave owners, boo-hoo, and allow slavery in the name of freedom?
> The copyleft requirement of GNU licenses restrict what a developer and/or company can do with the code since it forces them to make any derived code public... Which is generally undesirable for commercial projects; especially early in their lifecycles when bugs may be present and would be best kept private until the project has been more battle-tested.
It's supposed to restrict that, just like laws are supposed to remove your "freedom" to murder or take slaves. Copyleft exists for the public good, not for commercial projects. It doesn't need to be "desirable" for them.
> GPL licenses are a good way to ensnare businesses and then up-sell other software licenses that are more suited for commercial use.
Utterly weird take.
It is really hard to continue reading after spotting such glaring mistakes at the beginning of the article.
And that's setting aside the more basic issues of whether an organization like OSI can impose its definition on the universe, whether the definition it's been trying to impose really works or just sounds good, and whether that's really a legal spec or a political document.
The world is messy. It does not owe us the luxury of clear binaries.
I’m no expert, but how is this any different than AGPL restrictions/requirements to redistribute source code if you are running a modification on a server? Obviously, AGPL offers greater “benefit” with its requirement, but this seems to still be a restriction on how you can run the software.
That’s a marked difference.
Close, but not quite! Under the AGPL, you only need to make the source code available to the people who interact with the software over a computer network. You don't necessarily need to contribute the code back to the main project.
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
A totally different restriction, yes, but a restriction that goes against OPs “no restriction to run” clause none the less.
> The freedom to run the program as you wish, for any purpose (freedom 0).
https://www.gnu.org/philosophy/free-sw.en.html
Telling the user that they cannot run software in production is a restriction on the purpose for which the software can be ran. Telling the user that the source of the software must be made available to other users whom the software is distributed to over a computer network is not a restriction on the purpose for which the software can be ran, because it can still be ran for any purpose.