What counts as open source?

What counts as open source: License vs Source-available

Understanding what counts as open source prevents legal issues when sharing or using digital infrastructure code. Clear legal boundaries protect developers from mistakes during the transition to public repositories. Learning the correct status ensures others utilize the software effectively while avoiding unusable code.

What actually counts as open source?

Software counts as open source when its source code is made publicly available under a license that grants anyone the right to view, modify, and redistribute it. It is a common misconception that simply seeing the code is enough. True open source requires a legal framework - specifically an Open Source Initiative (OSI) approved license - that ensures the software remains accessible for all users without discrimination. While the term is often used loosely, it refers to a specific set of criteria that prioritize collaboration and transparency over proprietary control.

Open source adoption has reached 90% among modern enterprise technology stacks,^[1] reflecting its role as the backbone of todays digital infrastructure.

This widespread use means that most developers are interacting with open source daily, yet the legal boundaries often remain blurry. I remember the first time I pushed code to a public repository; I thought making it public was enough to call it open source. I was wrong. Without a proper license, the code was technically source-available but legally unusable for others. It took me a few months and a gentle correction from a senior developer to realize that the license is what actually confers the open status.

The Ten Pillars: Official Criteria for Open Source

To definitively answer what counts as open source, we look to the Open Source Definition maintained by the Open Source Initiative.

These ten criteria ensure that the software remains a shared resource rather than a restricted product. Free Redistribution: The license cannot restrict any party from selling or giving away the software. Source Code Access: The program must include source code and allow distribution in source form. Derived Works: The license must allow modifications and derived works under the same terms.

Integrity of Author Source Code: Licenses may require modified versions to carry a different name or version number. No Discrimination Against Persons or Groups: Everyone must have the right to use the software. No Discrimination Against Fields of Endeavor: You cannot stop someone from using it for business or genetic research. Distribution of License: Rights must apply to all to whom the program is redistributed.

License Must Not Be Specific to a Product: Rights shouldnt depend on being part of a particular software distribution. License Must Not Restrict Other Software: It cannot insist that all other software distributed with it be open source. License Must Be Technology-Neutral: No provision can be predicated on any individual technology or style of interface.

Approximately 78% of open source components have permissive licenses (such as MIT and Apache 2.0). These documents are the teeth of the definition. If a project claims to be open source but its license forbids you from using it for commercial purposes or requires you to pay a fee after 1,000 users, it is not actually open source. It is just source-available. This distinction is critical for businesses to avoid legal traps. ^[2]

Open Source vs. Source-Available: The Great Confusion

The line between open source and source-available has become a major flashpoint in the software industry. Many companies that started as open source have shifted their licenses to source-available models to prevent large cloud providers from selling their software as a service. While you can still read the code, these new licenses - like the Business Source License (BSL) - often restrict commercial use or competition. But theres a counterintuitive factor that most beginners overlook - Ill explain why more restricted code isnt always bad in the sustainability section below.

In my experience, this bait and switch from open source to source-available is incredibly frustrating for community contributors. I spent nearly 50 hours contributing bug fixes to a database project only to see them change to a restrictive license a year later. My hands were literally shaking as I read the announcement - it felt like my volunteer work had been captured by a private entity. This is why checking the license file is more important than checking the code itself. If its not OSI-approved, its not open source. Period.

Why Does Being 'Open' Matter for Sustainability?

Open source is about more than just free software; it is about security and longevity. Because anyone can inspect the code, vulnerabilities are often found and patched faster than in proprietary systems.^[3] When a project is open, it doesnt die just because a company goes bankrupt. The community can fork the code and keep it alive.

Remember the critical factor I mentioned earlier? Heres the kicker: code that is source-available but not open source is often used by companies to balance staying in business with being transparent. While it doesnt count as open source by the official definition, it is often open enough for individual learners. However, for any professional project, sticking to true open source ensures you arent building your business on shifting sand. Simply put: if you cant fork it and run it elsewhere, you dont truly own your stack.

Comparing Software Models

Open Source (OSI-Approved) ⭐

Always allowed without fees or restrictions

High - community can maintain code if the owner leaves

Allowed, often with the right to share improvements

Source-Available

Often restricted (e.g., no 'as-a-service' offerings)

Moderate - visibility helps, but legal rights are limited

Varies - often allowed for personal use but not distribution

Proprietary

Requires specific paid licenses and contracts

Low - users are fully dependent on the vendor's survival

Strictly forbidden - source code is a trade secret

The Redis License Shift: A Community Struggle

Hieu, a software architect in Da Nang, built his company's entire caching infrastructure on Redis, believing it would always remain open source. In early 2024, the project moved from the BSD license to a more restrictive source-available model.

Hieu's first reaction was panic. His team had planned a new public-facing cloud service, and they weren't sure if the new license would force them to pay massive fees or change their architecture entirely. The '1-day setup' they enjoyed turned into weeks of legal review.

The breakthrough came when Hieu realized the power of true open source: the community had already 'forked' the last open version of Redis to create Valkey. He shifted his focus to the fork, which remained under the original open terms.

By switching to Valkey, Hieu's team maintained their 95% cache hit rate without changing their code logic. He learned that the license isn't just paperwork - it is the only thing protecting his work from corporate policy changes.