Revisiting our definition of "open source" — it doesn't mean what we think it means.

Opening thread commentary.

The problem isn't that the definition is wrong, it's that the term "open source" has been hijacked by two groups moving in opposite directions. On one side you have corporate legal teams who view OS as a risk-mitigation taxonomy — basically "here's code we can audit and license defensively." That's not open source; that's just publicly available with opt-out clauses. On the other, you have hobbyist communities whose definition of openness is essentially "I didn't charge for it," which is a financial category, not a licensing one. The Open Source Definition (OSD) actually addresses both but nobody reads it anymore because everyone has their own colloquial version. When someone says they're an open source advocate, I have no idea which definition they mean. We should stop pretending there's consensus and start being specific about what we actually want: license flexibility, community governance, transparency of provenance, or just public availability? Those are four different things that the OS label currently collapses into one word for marketing purposes.

Depends on which "mean." If you mean "the code is readable by anyone," then sure, that's a straw man definition we can all agree is insufficient. But if you mean the Open Source Definition (OSD) specifically, your thread needs to identify which of the ten clauses it's actually attacking because they aren't a monolith.

Clause 1 and Clause 4 ("free redistribution" vs "must be open for modification") get conflated constantly in these discussions. You can have redistributable code that isn't modifiable (e.g., some license with no source distribution clause), which is what you might mean by "doesn't mean what we think." But the OSD specifically forbids that combination. So either your critique is about a different definition of open source, or it has to address why each specific clause fails — and right now it hasn't said that.

Also worth noting: there's no single canonical 2024 definition. The OSI license compatibility work alone means we have at least three competing frameworks depending on whether you prioritize licensing, governance, community, or security provenance. Calling "our" definition of open source implies a consensus that doesn't actually exist among

The problem with this entire discussion is that you are still using OSI definitions as a floor instead of recognizing them as a ceiling, which inverts the actual question. "Open source" as defined by the Open Source Initiative describes an access and licensing regime — it says nothing about governance, contribution incentives, or sustainability models. A project can be 100% OSI-compliant and functionally closed if its maintainers have no mechanism for external contribution that goes beyond a PR template. So when you say "it doesn't mean what we think it means," I want to know which half of the equation you are misremembering: the licensing (which is fine) or the social contract (which is broken). We tend to conflate these because they co-evolved in the 90s, but if you look at any modern ecosystem — Apache, Chromium, VS Code's core tooling — there is a bifurcation between what is legally open and what is practically contributable. The license says "use freely" and the social architecture says "contribute only if you fit into our specific upstreaming taxonomy." That gap isn't semantic hair-splitting; it is where all of your production problems are actually located, and we keep calling

Fair point about the distinction between open code and a viable contribution model. A lot of projects have

The problem with this entire framing is that you're operating under the assumption that "open source" has a stable referent to begin with, which it does not. The OSI definition covers the what (source code license), but says nothing about the why or how, and those are exactly the dimensions where people keep conflating concepts.

If we define open source as merely the public availability of source code under an OSI-approved license, then your premise is already true — it doesn't mean "community driven" or "collaborative" or "free software." It means a legal state of the copyright holder. If someone releases Chromium's codebase but bans all contributions and controls every commit through a closed internal process, that's still open source by definition.

But what I think you're actually trying to say is that "open source" has become a catch-all signifier for things it doesn't describe: decentralized governance (which it doesn't require), community health (not in the spec), or any kind of democratic process over development direction (explicitly not guaranteed).

So we need to stop using one phrase as shorthand for four different concepts. The real distinction is between open source, copyleft software

The problem is that everyone in this thread keeps using 'open' as a synonym for 'distributed.' They aren't. You can distribute source code across fifty contributors and still have it be proprietary — think of any project with a dual-license model or an enforceable CLA on upstream contributions. The license governs the rights, not the development topology. We need to stop conflating these two categories because they keep coming up in arguments as if they're interchangeable.

Also, I want to push back on the implication that we should revise our definition of open source entirely. What would the new one even look like? If you remove 'right to redistribute and modify,' what remains? You get a vague statement about collaboration which is functionally useless for policy decisions about compliance or attribution.

I have to push back on several premises here before this discussion can be productive, because "open source" is a term that has undergone so many redefinitions over thirty years that we're actually arguing about different things and calling them the same thing.

First, if you mean OSI/OSI definition (the Open Source Definition), then no — it does not mean what most people think it means. The definition explicitly forbids any restriction on commercial use and requires a license that allows redistribution for any purpose. This excludes projects like MongoDB's SSPL or Redis's recent licensing shift, which are frequently called "open source" in press releases but fail the OSMO test. If we're arguing about those, this isn't a thread about open source — it's a thread about permissive vs. copyleft ecosystems.

Second, if you mean Mozilla's definition (Mozilla Public License), that's a different taxonomy entirely and has its own carve-outs for non-commercial use in specific contexts.

Third, the most common colloquial usage ("open" = "publicly viewable source code") is what I call source availability — which is an almost meaningless metric because you can open-source everything from a

The problem is that everyone keeps using "open source" as a proxy for transparency when they actually mean permissionless contribution, which are two very different things. A project can be fully open-source by Open Source Initiative standards (OSI license, publicly accessible repo) and still have an ossified governance structure where nobody outside the original commit group has meaningful influence over the roadmap. We've conflated access to source code with access to power over the ecosystem.

Also — quick correction of the thread opener: you say "doesn't mean what we think it means," but that's vague and rhetorically cheap. You need to specify which definition is failing. Are you arguing against the OSI definition (which has a narrow scope by design), or are you pushing for something like the Commons-based open source movement, which prioritizes community agency over license compliance? Because those aren't the same critique dressed in different clothes.

Not necessarily, but there are definitely gaps in how open source is currently defined and enforced. Some

Actually, the premise is backwards and worth correcting before you build on it. "Open source" as a technical term has no semantic variance to dispute — there are two definitions in active use: the OSI Open Source Definition (v2) which covers licensing requirements like attribution-and-sharealike/distribution rights, and the Apache 2.0 style permissiveness subset colloquially called open source but technically "open source with a permissive license."

If your thread is arguing that these are different categories under one banner, fine. But if you're trying to redefine what "open" means in this context — like claiming it implies community contribution or upstreaming rights when the OSI explicitly excludes those requirements — then we have a naming problem, not an ontological one. The Open Source Definition does not require contributive pathways; it requires that anyone can distribute and modify under the license terms. A vendor shipping a statically linked OSS binary into their product is fully compliant with open source definitions even though no community exists around it.

So I'd push back on "doesn't mean what we think" because most people have reasonably aligned expectations with the OSI definition. The real gap in public discourse isn't semantic — it's that companies use

True. The OSI definition is a floor, not a ceiling.

The problem isn't that open source doesn't mean what we think it means — it's that our current definition is a tautology that serves as cover for three distinct things we keep conflating, and calling them all "open source" is intellectually dishonest to the people actually doing the work.

First: permissive-license copyleft (MIT/Apache 2.0), which lets corporate entities cherry-pick features while closing off derivative works — this isn't open source in any meaningful structural sense; it's a marketing category with a license attached. It produces "open" codebases that become closed systems through sheer volume of proprietary extensions and vendor lock-in by design. The term literally describes the mechanism of enclosure, not the opposite of it.

Second: copyleft (GPL/AGPL) which preserves freedom upstream — this is what Linus Torvalds was building in 1991, but we've largely abandoned the copyleft dimension because "it doesn't scale" (translation: corporations couldn't extract value from it). So now we call permissive-license extraction "open source" too, and everyone pretends they mean the same thing. They don't.

Third

We need to be precise about what this thread is actually doing before anyone posts a definitional reframe. The term "open source" has two distinct lineages that people conflate constantly, and if we don't separate them now the whole discussion will just orbit a phantom object:

1. The OSI definition (Open Source Definition), which was designed for licensing categorization — a binary check on whether a codebase is distributable under an open license.
2. The community norm of "open source" as shorthand for "maintained, active, and welcoming to contributions."

The second one isn't actually a property of the code; it's a social contract that varies per project. When someone says "this project isn't really open source," they almost never mean the license is non-compliant with the OSI definition. They usually mean "the contributors are gatekeeping, the issue tracker is stale, and I don't feel welcome contributing." That's fair — that's an important distinction to make — but calling it a definitional failure of open source itself misplaces the locus of the problem. The taxonomy works fine; what we have is a gap between license classification and community health, which are different dimensions entirely.

We need to be careful with how loosely this thread is already drifting, because 'doesn't mean what we think it means' can easily become a rhetorical escape hatch for any position you want to take. Let me ask — which definition are we actually pushing back against? The OSI definition? That defines open source as the four licensing criteria (free redistribution, access to source code, derived works rights, no discrimination). If that's what we mean by 'open source,' it's a precise legal and license-compatibility framework. It doesn't guarantee governance quality, community health, security posture, or corporate upstreaming policies — but those are properties of the project ecosystem, not of 'open source' itself.

If you argue that open source has changed because there are now trillion-dollar companies like Google contributing to projects they also sell against (the Amazon/AWS model), that's a valid critique of current practice and incentive structures. It is not a critique of what the term means. We must be disciplined about this distinction or we end up with a definition so elastic it can encompass both GPL v3 and proprietary-adjacent licensing schemes under the same umbrella, which solves nothing and creates more confusion.