We throw the phrase "open source" around as if everyone agrees what it means. A repo is public, so it's open source, right? Not quite. There's an actual, written, ten-point definition behind the term, and most of us who use it daily have never sat down and read it. I hadn't either, for years, until a licensing argument at work forced me to. It's worth twenty minutes of your life.
The phrase isn't just vibes. It's a deliberate specification with real consequences for what you can do with someone else's work — and what others can do with yours.
Open source is more than visible code
The most common mistake is conflating "source available" with "open source." Plenty of code sits in public repositories under licences that forbid commercial use, ban redistribution, or let the owner change the terms whenever they like. You can read it; you can't necessarily use it the way the word implies. That gap is exactly what the formal definition exists to close.
If you want the precise version, the Open Source Definition lays out ten criteria a licence must meet, and the interesting thing is how much they're about freedoms rather than price. Free redistribution. Access to source. The right to make and distribute derived works. No discrimination against people, fields, or uses. Read together, they describe not a price tag but a bundle of permissions that travel with the code wherever it goes.
The criteria that catch people out
A couple of points trip up newcomers in instructive ways. One is the rule against discrimination: a genuinely open-source licence can't say "free for everyone except military use" or "not for companies over a certain size," however sympathetic the intent. The moment you carve out who may use the software, you've stepped outside the definition. That surprises people who assume open source is purely about generosity — it's actually about a very specific, content-neutral kind of freedom.
Another is license propagation. Some licences are "copyleft" — they require that derived works carry the same terms — while others are permissive and let you fold the code into proprietary products. Both are fully open source by the definition; they just encode different philosophies about what freedom should require of you in return. Knowing which kind you're depending on matters enormously the day a lawyer asks what's in your software.
Why this should matter to you
You might think this is lawyer territory, not engineer territory. But every time you pull a dependency, you inherit its licence and its obligations. Ship a copyleft library in a closed product without realising it, and you've created a problem that's expensive to unwind. Understanding the definition isn't pedantry; it's basic professional hygiene, like knowing what data you're storing.
There's a cultural reason too. The definition is the closest thing our community has to a constitution — a shared agreement, hammered out over decades of argument, about what the words mean. When people try to stretch "open source" to cover code that quietly restricts users, they're not just being loose with language. They're eroding a hard-won common understanding that a lot of people fought to establish.
So read it. Not because you'll be quizzed, but because you use these freedoms every single day and it's strange to depend so completely on something you've never examined. Twenty minutes with the actual text will change how you read a licence file forever — and you'll never again say "it's open source" quite so carelessly.
