There is always room for arguing. If not, we will have an argument about whether or not argument should be allowed.
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.
Semantic drift is a real problem. Too much semantic drift can make it difficult to communicate, because we no longer have a common vocabulary to communicate with. I don't think semantic drift is inevitable, but it is inevitable if it isn't resisted by a large enough fraction of the community.
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.
> 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.
There are some things vegetarians disagree on: eggs, dairy, gelatin, etc.
> any software whose license doesn't belong to the OSI's list is proprietary software.
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!
The whole picture is not necessarily as simple as taking the license at face-value because these licenses are also legal documents.
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.
Well, starting from your point, I can write my software as a complete blob and add its 10 line launcher as a small source file, license that 10 line launcher as MIT, while adding a very restrictive EULA to the blob.
In your example, the launcher would be open source but the blob would not. When you look at the proportions of the code in the combined software, it would be obvious that the majority of the code is proprietary and that the software as a whole is mostly closed source.
Like the SaaS apps which are touted as "open source" with small open source clients which are not functional without the closed source backends (or with open source backends which you can't install because of a couple of non-intentionally missing important bits)?
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.
We're in full agreement here. It's dishonest to describe software as open source when it is not operational without key components that the developer intentionally made closed source. I would be fine with them saying that the software is "partially open source" and explaining up front exactly which parts of the software are open and which are closed. As a whole, if a piece of software is non-functional without a proprietary component, then it is not open source.
The problem with your perspective from my point of view, is how convoluted the licenses can be.
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.
> So, just because a license satisfies four freedoms doesn't make a piece of software "Open Source".
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.
It was exaggerated example on purpose, but it's not very far from the truth. Many "Open Source" projects are licensed under a permissive or weak-copyleft license, everything incl. the source is put out there, hence you have the four freedoms, theoretically.
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.
GitBook hasn't been open source since October 2018 (https://github.com/GitbookIO/gitbook) and software is judged by its most recent version. GitBook in its current form is a proprietary web service. The October 2018 version is open source, but it's also abandonware.
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.
I tried to deploy GitBook in 2017 IIRC, and left it alone after seeing how it's shared to prevent re-deployment. I didn't know they abandoned the idea of "Looking Like Open Source" in 2018.
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.
I agree that if open source client software requires a proprietary web service to be used, that software as a whole is not open source. That doesn't mean the test of the four freedoms is insufficient, it simply means that the test needs to be applied to both the client and the server.
> 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]
> VSCodium is not "designed" to be less functional, since it is a project maintained by developers who are unaffiliated with Microsoft.
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.
We are in agreement, mostly, the only point of contention is that I never want to see a single organization being held, alone, as the sole arbiter of which license is open source and which is not. The world is a big place. There's room for multiple organizations with different priorities and interests to define things like this and anyone who claims "there must be only one" is suspect in my view as that's such an authoritarian point of view that I can't reconcile that kind of position with also being a supporter of the freedoms that are central to the open source movement.
I agree with you on that. Ideally, I'd love to have multiple institutions working on these issues, but while the idea is nice, it involves humans.
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.
Not really. People commonly misuse "their", "there", and "they're", but doesn't change the currently accepted definitions of these words. The OSI's Open Source Definition gains credibility from its broad support from the FOSS community, and because it has been explicitly recognized by quite a few governments: https://opensource.org/authority
Important issue, mediocre article. The problem is that the big AI companies are trying to advertise something as open source that isn't. There's also the issue that "weights" may not be copyrightable at all in the US, because they are not a work of human authorship.
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.
This is the major difference. There is an explicit understanding using the licence that the user shall pay 5% of the revenue post 1M in sales. However in Meta's case there is no such clarity . You are completely at the mercy of Meta once you have a functionality that depends on LLAMA and the business wont have any negotiating power. Entering in these potential situations is a strategic blunder and the best way to handle it is to pre-emptively avoid this path.
Having a figure showing three categories of software after a very vigorous assertion that there are only two seems like an odd way of laying things out.
- 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.
Interestingly, FOSS means more freedom for the code and for the end user of the code but less freedom for any developer or company who might be reproducing and/or hosting the code.
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.
> Interestingly, FOSS means more freedom for the code and for the end user of the code but less freedom for any developer or company who might be reproducing and/or hosting the code.
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.
Except the developer of the code is not binded by the copyleft restriction. The developer can take his own code, modify it, and not release any modification.
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?
Yes agreed, the original developer is not bound since they still retain the copyright. I meant to say 'reproducing' the code, not 'producing'. Only the developers of derived code are restricted.
> 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.
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.
Say I use a software with AGPL as license on my server. If my server doesn't output anything AGPL-licensed to its clients, where is the distribution? If there is no distribution, how can the AGPL be enforced?
> If my server doesn't output anything AGPL-licensed to its clients,
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.
Yes, I don't know how one can be able to cite sources yet be so ill-informed. This article probably doesn't mean anything to anyone. Open source means you get the source, that's it. OSI is a good reference, but it's not the boss of definitions.
No, open source doesn't just mean that you get the source. This is the open source definition, the only commonly used definition used in the software world:
The term "opensource software" was coined by the OSI founders explicitly to have the meaning they laid out in the Open Source Definition. The term didn't exist before that.
I appreciate the input, even though I don't necessarily agree.
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.
Shareware is not free software, since it does not provide users the right to inspect or modify the software. It is also not freeware, since some or all of its features are not available free of charge.
The opening sentence is hyperbolic and wrong, there is at least one additional category of source code that is neither proprietary nor open source: public domain. This entire article lost me after that initial overreach.
I feel like we just need new terminology. Visible source, for example. As the author says, "There's absolutely no problem with proprietary software". To me, there is a problem with it under some circumstances if I can't inspect the source. A lot of times you aren't including it in your own code, you're just using it in your toolchain and you want to make sure it isn't poisoned. "Open source" as a phrase has become a stand-in for being able to check the source, but obviously as the author points out it's a misnomer, and can be used for misdirection. Why can't we just call it "visible source" when this is the case, to avoid confusion or false marketing?
Historically, not even the Open Source Initiative tried to define "open source" this way. There were licenses commentators agreed met their definition that they did not approve---open source but not OSI-approved. See also "license proliferation". There's also the whole issue of "public domain". Is CC0 code "proprietary"?
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.
The bigger scandal is that Mr. Joe BigCo Developer rewriting a bonafide open source app in BigCo language Swiftgolanghacksharp makes that new thing also open source, but for some reason, everyone gets away with declaring it proprietary.
> The BSL license is not an Open Source license because it restricts users' freedom to run the program however they wish.
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.
> You can run the software with AGPL. You simply need to contribute it back to the main project.
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.
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.
I don't really want to build an open-source washing machine myself, but such a project would be really fascinating to read about. I too was very disappointed to find out (just reading the comments here, luckily I didn't waste time clicking on the article) it's just some boring drivel arguing about what is or isn't "true" open-source.
There's plenty of room for arguing. The FSF, in fact, approves a few licenses that OSI doesn't.