“Open source” is one of the most successful phrases in the history of software. It is also one of the most over-loaded. People use it to mean free, safe, community-run, transparent, ethical and permanent. The definition guarantees exactly one of those things, and only partly.
What the licence gives you
An open source licence is a legal instrument. It grants permission: to read the code, to run it for any purpose, to change it and to pass it on, sometimes with conditions attached. That is a large grant, and it is the reason the modern internet exists. Almost every server, phone and browser is built on code that anyone can inspect.
But a licence is not a service agreement. It does not say the code works. It does not say anyone will fix it if it breaks. Most licences say the opposite, in capital letters, in a paragraph that nobody reads.
What it does not give you
Maintenance. A project can be open and abandoned at the same time. Much of the software that critical systems depend on is maintained by one or two people in their spare time, and the fact that the code is public does not create a queue of volunteers to take over when they stop.
Security. “Many eyes make all bugs shallow” is an aspiration, not a law. Eyes have to be pointed at the code, and they have to belong to people who know what they are looking for. Serious vulnerabilities have lived for years in widely used open libraries because everyone assumed someone else was auditing them.
Governance. Who decides what gets merged? Who holds the publishing keys for the package registry? What happens when a maintainer’s account is compromised, or when a company that funds the project changes its mind? Open code can sit under closed decision-making, and the licence has nothing to say about it.
Permanence. Licences can change for future versions. Projects can be relicensed, forked, or simply left to rot. The code you downloaded stays open; the project you depended on may not.
The supply-chain framing
The most useful mental model for open source today is not “free software” but “supply chain”. Every dependency you add is a supplier. You are trusting their code, their build process, their account security and their judgement about their own dependencies, recursively.
That framing suggests the right questions. Who maintains this? When was it last updated? How are releases signed? Does the project have a security policy and a way to report problems privately? Does anyone actually read its changelog? None of these questions are answered by the licence file.
What good stewardship looks like
The healthiest projects have boring characteristics. More than one person can publish a release. Contributions are reviewed by someone other than the author. Dependencies are pinned and audited. Security reports have a private channel and a public disclosure timeline. Funding, where it exists, is visible.
None of that is glamorous, and none of it is required by the definition of open source. It is simply what it takes for the promise in the licence to mean something in practice.
The point
Open source is one of the great collaborative achievements of the last half-century. Treating it as a free resource that maintains itself is the fastest way to break it. The label tells you what you may do. The rest is your responsibility.
