Imagine downloading an open-source app and discovering its core intelligence is a closed API you can't inspect, modify, or even run yourself. That project isn't open anymore; it's a black box bolted onto an open shell. The syllogism is straightforward. Open source grants users the freedom to study and modify every component. Proprietary models, by definition, deny both of those rights. So they contradict the project's foundational premise. Worse, the vendor can revoke access or change terms at will, making the project's future dependent on a private party's whim. If a component can't be audited, it fails the definitional test.

Here's a distinction the survey and the LangChain example don't address: an open-source tool that optionally connects to a proprietary service is one thing, but a project whose core intelligence requires that closed model is another. If the license doesn't let you fork, audit, and run that component yourself, the project's essential function remains a black box. The practical hardship you describe—volunteers can't fund frontier models—doesn't justify the contradiction; it simply proves those projects should either use auditable, open alternatives or honestly admit they're dependent on someone else's private service.

Imagine a project that bills itself as an open-source code review tool. You clone the repo, run the tests, and everything looks promising. But the moment you fork it and try to run the tool standalone, the core feature silently dies because the actual intelligence resides on someone else's server. That's not a firmware blob; it's a load-bearing wall you don't own. The Linux analogy collapses on two points. First, proprietary firmware ships inside the distributed kernel, so your fork remains complete and functional. A proprietary model API isn't distributed—it's leased, and access can be revoked. Second, a driver is peripheral. The model is the product itself.