What qualifies as open source?

What qualifies as open source? The 10 criteria and what doesn't

what qualifies as open source is misunderstood, leading developers to integrate code with hidden restrictions. Using source-available licenses thinking they are open source creates legal and commercial risks. Understanding the official criteria protects projects from future compliance issues and ensures true software freedom.

What Does "Open Source" Really Mean?

Open source is more than just publishing your code on GitHub. Its a formal set of principles that guarantee anyone can freely use, study, modify, and share your software for any purpose. The internationally recognized standard for these principles is the open source software definition (OSD), maintained by the Open Source Initiative (OSI), a non-profit organization founded in 1998 (citation:4). If a software license doesnt meet all ten of these criteria, its not open source—no matter what its marketing materials claim (citation:1).

The 10 Criteria That Define Open Source Software

The osi open source definition is the definitive checklist. Its the result of years of community discussion and practical experience, originally derived from the Debian Free Software Guidelines (citation:9). For a license to be OSI-approved, it must meet all of the following requirements.

1. Free Redistribution

The license cant stop anyone from selling or giving away the software. You can charge for it, bundle it, or give it away for free, and the license cant demand a royalty or fee for that sale. This prevents a licensor from making a short-term profit at the expense of the long-term community growth (citation:5).

2. Source Code Access

The program must include source code, and it must be distributable in both source code and compiled form. If you dont ship the source with the software, you must have a well-publicized way to get it for a reasonable reproduction cost—preferably free download. Crucially, the source code must be the preferred form for modification. Obfuscated code or intermediate outputs dont count. You cant improve a program without being able to modify it (citation:9).

3. Derived Works

The license must allow modifications and derivative works, and it must allow them to be distributed under the same terms as the original. This enables rapid evolution, experimentation, and independent peer review. Without this, the whole collaborative model falls apart (citation:5).

4. Integrity of The Author's Source Code

The license may restrict distribution of modified source code, but only if it allows patch files to be distributed with the original code for building at compile time. This protects the original authors reputation by making it clear whats an official version versus an unofficial modification. Derived works can be required to carry a different name or version number (citation:9).

5. No Discrimination Against Persons or Groups

Open source is for everyone. The license cant lock anyone out of the process. You cant stop evil people from using it, you cant restrict use based on nationality, and you cant require adherence to a particular political or social belief. Maximum diversity leads to maximum benefit (citation:1)(citation:5).

6. No Discrimination Against Fields of Endeavor

This is critical for commercial adoption. The license cant restrict the program from being used in a business, in research, or for genetic research. It cant be open source for non-commercial use only. If a license tries to prohibit commercial use, it fails this test immediately (citation:5).

7. Distribution of License

The rights attached to the program must apply to everyone who gets a copy, without them needing to sign an additional license or non-disclosure agreement. You cant close up software by indirect legal tricks (citation:9).

8. License Must Not Be Specific to a Product

The rights cant depend on the program being part of a particular software distribution. If you extract the code and use it separately, it must still have the same rights as in the original bundle. This prevents another class of license traps (citation:5).

9. License Must Not Restrict Other Software

The license cant impose restrictions on other software distributed alongside it. It cant demand that everything on the same CD or in the same repository must also be open source. Distributors get to make their own choices about their own software. Even strong copyleft licenses like the GPL meet this requirement—they only affect the work theyre linked into, not merely co-distributed programs (citation:5).

10. License Must Be Technology-Neutral

The license cant be predicated on any specific technology or interface style. It cant require a click-wrap agreement for every download, because that would break distribution methods like FTP or CD-ROMs, and it wouldnt work in non-GUI environments (citation:9).

Open Source vs. Free Software: What's the Difference?

Practically speaking, theyre the same thing. The Free Software Foundation uses a four-point definition focused on user freedoms, while the OSI uses the ten-point definition. Both lead to the same licenses being approved.

The difference is philosophical: the free software movement emphasizes the ethical imperative of freedom, while the open source movement focuses on the benefits of open source software (citation:1). In the 1990s, the term open was sometimes used to imply merely inspectable source code, but the OSIs definition cemented it as entailing the perpetual right to fork and redistribute (citation:1). Today, many people use the umbrella term FOSS (Free and Open Source Software) to avoid the debate.

Open Source vs. Source Available: The Critical Distinction

This is where most of the current confusion lives. Source available licenses make the code visible, but they dont grant all the freedoms required by the OSD. They often restrict commercial use, ban specific use cases, or prohibit distribution to competitors (citation:2)(citation:6).

The rise of source-available licensing is a direct response to cloud providers monetizing open source projects without contributing back—a practice thats caused companies like MongoDB and Redis to switch from OSI-approved licenses to more restrictive terms (citation:6). For example, MongoDB created the Server Side Public License (SSPL) to ensure that anyone offering the software as a service must also release the source code for the entire service stack, not just MongoDB itself (citation:6).

Similarly, the Business Source License (BuSL) often restricts production use, though it automatically converts to a real open source license after a set period, typically four years (citation:6).

How to Spot a Source-Available Trap

These licenses look like open source at first glance—the code is on GitHub, you can clone it, maybe even modify it. But read carefully. Youll see clauses like you may not provide the software to third parties as a hosted service, or you may not use this software in a nuclear facility, or vague restrictions on commercial use.

The Dont be a Dick Public License is a notorious example—its legally vague and creates huge compliance risks (citation:10). If youre building a business, integrating source-available code can lock you into a vendor or expose you to lawsuits down the road.

Use Software Composition Analysis tools to detect open source license requirements early; over 20% of licenses in some knowledge bases are classified as source-available, and nearly half of them restrict commercial use (citation:2)(citation:10).

What About Open Source AI?

The same principles apply, but theyre harder to satisfy. For an AI model to be truly open source, its not enough to release the model weights. You also need the training code, the training data (or comprehensive documentation of it), and the full pipeline (citation:7).

The European Open Source AI Index evaluates models on criteria including base model data availability, training code, hardware architecture, model cards, and datasheets. Many models that call themselves open fail these tests because they dont release their training data—often due to licensing or privacy restrictions.

The OSI is actively working on defining what qualifies as open source AI to bring clarity to this space (citation:2). If youre evaluating an AI project, ask: Can I fully reproduce it? Do I have access to everything needed to understand, modify, and distribute my own version?

Why Does This Matter? The Business and Ethical Case

Adopting software under OSI-approved licenses gives you legal certainty. You know you can use it commercially, you can modify it, and you can integrate it into proprietary products if you choose (with permissive licenses like MIT or Apache).

Youre not at risk of a sudden license change that breaks your business model—though thats happened with some projects moving to source-available licenses. For contributors and maintainers, understanding what qualifies as open source builds trust. It signals that youre playing by the communitys rules and that your project is a safe place to invest time and code. The OSIs license approval process exists precisely to prevent confusion and protect the meaning of the software (citation:1).

Ill be honest—when I first started in tech, I thought open source just meant I could see the code. I didnt understand that the license mattered. It took getting burned by a source-available project that wed built a product on to realize the difference. We had to spend months rewriting that module. Now I check every license against the OSD before we commit. Dont make the same mistake.

Choosing an Open Source License for Your Project

If youre releasing your own code and you want it to be open source, you must pick an OSI-approved license. Dont write your own. Dont modify an existing one. Use one of the standard licenses exactly as written (citation:1). The choice comes down to your goals:

Permissive licenses (MIT, BSD, Apache 2.0) allow anyone to use your code in proprietary projects with minimal restrictions. They maximize adoption. Copyleft licenses (GPL, AGPL) require that any derivative works also be open source under the same license. They ensure that improvements stay in the commons (citation:1). Weak copyleft licenses (MPL, LGPL) require that modifications to the licensed files themselves stay open, but allow linking to proprietary code.

Theres no wrong answer—it depends on what you want to achieve. But once you pick one, stick to it. And put a LICENSE file in your repository root. Its that simple.

Open Source vs. Source Available: A Side-by-Side Look

Open Source (OSI-approved)

• Always available and must be the preferred form for modification.
• Guaranteed. Can be used for any purpose, including in proprietary products (depending on license variant).
• High. Uses standard, OSI-approved licenses with established case law.
• Free redistribution is a core requirement. Can be sold or given away.
• No discrimination. Can be used in business, research, or any other field.
• Explicitly allowed. Modifications can be redistributed (under same or compatible license).

Source Available

• Available, but may be obfuscated or not the preferred form for modification.
• Often restricted. May prohibit use as a service, or require a commercial license for certain uses.
• Lower. Licenses are often custom and untested in court; terms can be vague.
• May be restricted. Sometimes allowed, but with conditions (e.g., non-compete clauses).
• May have restrictions (e.g., no nuclear use, no military use, no competitive offerings).
• Varies widely. Often discouraged or prohibited for competitive purposes.

Startup's Licensing Nightmare

DevScale, a 15-person B2B SaaS startup, built their core data synchronization feature on a popular database that was licensed under the SSPL. The founder had found the code on GitHub, assumed it was open source because the source was visible, and never checked the license terms.

Fast forward 18 months. DevScale closed a Series A and was preparing to launch their cloud-hosted product. Their legal counsel reviewed the stack and hit the brakes: the SSPL required them to release the source code for their entire service—including their proprietary orchestration layer—if they offered it as a hosted service.

The team spent three frantic months rewriting the sync layer using a truly open-source alternative (licensed under AGPL, which they understood). They delayed launch by a quarter, burned through $200k in dev resources, and lost their first-mover advantage in a competitive market.

The founder's takeaway: "I learned the hard way that 'source available' is not 'open source.' Now we have a strict policy: only OSI-approved licenses go into production. It's not just licensing—it's business survival."