What Is Open-Source Software? Licenses, Models & Why It Matters (2026)

You are about to ship a product on top of a library you found on GitHub. Before it goes out, one question matters more than how good the code is: does its license actually let you use it the way you plan to?

Open-source software is software released under a license that lets anyone use, study, modify, and share it, with the source code available to make those freedoms real. The Open Source Initiative (OSI), which has stewarded the definition since 1998, approves the licenses that qualify. “Open” is about those freedoms, not about price. Plenty of open-source software is sold, and plenty of free-of-charge software is not open at all.

The reason this trips teams up is that “source you can see” and “source you can freely use” are different things, and a lot of code sits in the gap between them. This post covers what open source actually means, the license families you will meet, what does not qualify despite looking open, and why the distinction changes what you can build.

One quick note: this is about software. “Open source” also names an intelligence discipline, OSINT, which is a separate topic entirely.

The core idea: source you can use, study, change, and share

Strip away the legal text and open source rests on four practical freedoms. You can run the software for any purpose. You can read the source to see how it works. You can change it to fit your need. And you can share it, changed or not, with other people.

The Open Source Definition the OSI maintains spells this out in ten criteria, but the ones that bite in practice are these: no restriction on who uses it or in what field, no ban on commercial use, and the source has to travel with the right to modify it. A license that says “source visible, but no commercial use” is not open source, however public the repository.

A quick example makes the freedoms concrete. Say you adopt a permissive-licensed logging library. Running it in production is the first freedom. Reading its source to understand a slow path is the second. Patching that path in your own fork is the third. Shipping the patched copy to a customer, or publishing the fix back upstream, is the fourth.

A license that blocked any one of these, by forbidding commercial use or barring redistribution, would fail the definition no matter how public the code.

This is also where “free software” and “open source” meet. The free-software movement frames the same freedoms in terms of user liberty; the open-source label, coined in 1998, framed them for business adoption. The licenses overlap heavily. When people say “free” in this context, they mean free as in freedom, not free of charge.

The three license families that set your obligations

Almost every open-source license belongs to one of three families. The family, more than the specific license, tells you your obligations.

Permissive: MIT, Apache-2.0, and BSD

Do almost anything, including building a closed-source product on top, as long as you preserve the copyright and license notice. MIT and BSD are short and minimal. Apache-2.0 adds an explicit patent grant, which protects you if a contributor later asserts a patent on their contribution. This is the family most companies prefer to depend on, because it carries the fewest obligations and the least legal risk.

Copyleft: GPL and AGPL

Share-alike. If you distribute software that includes GPL code, you must release your combined work under the GPL too, source included. AGPL closes what people call the SaaS loophole: it treats running the software as a network service the same as shipping it, so you owe the source to your users even when you never hand them a binary.

Copyleft keeps derivatives open, which is the point, and it is a real constraint if you want to fold the code into a closed product.

Weak copyleft: MPL and LGPL

A middle ground. The Mozilla Public License applies copyleft at the level of individual files: change an MPL file and you share that file, but you can combine it with proprietary code around it. The LGPL does the same for libraries, letting a closed application link to the library as long as the library itself stays open. These let you use copyleft components without opening your whole codebase.

What is not open source, even when the code is public?

Some of the most popular infrastructure software in 2026 is not open source, even though you can read every line. Two categories look open and are not.

The first is source-available. The source is public, but the license restricts how you use it. The Business Source License (BSL), created by MariaDB, lets you read and use the code but blocks a competing production use until a change date, often four years out, when each version converts to a true open-source license.

The Elastic License 2.0 permits almost everything except offering the software as a managed service. The Server Side Public License (SSPL), written by MongoDB, requires anyone offering it as a service to open-source their entire serving stack, a condition the OSI rejected as failing the definition. All three are source-available, not open source.

This category grew as infrastructure companies relicensed away from open source to protect their cloud revenue. HashiCorp moved Terraform to the BSL in 2023, which pushed the community to fork the last open version as OpenTofu. The same pattern produced OpenSearch from Elasticsearch and Valkey from Redis. Those forks exist precisely because the originals stopped being open source.

The second category is AI model weights. A model like Llama is downloadable but ships under a custom license with use restrictions, which makes it open-weight, not open source. Gemma ships under Google’s own terms and Falcon under a TII license; none are OSI-approved, so the software conventions in this post do not fully transfer to them. The open-source versus open-weight LLM guide covers that distinction in full.

How to check a repository’s real license in three steps

Do not trust the label at the top of a README. The table below sorts the families by what they cost you, and the three checks under it settle any specific case.

First, open the LICENSE file in the repository root and read the actual name, not the summary someone wrote in the README. Second, match it against the SPDX list: a recognized OSI license like MIT, Apache-2.0, or GPL-3.0 is open source, full stop.

Third, if GitHub shows the license as “other” or “NOASSERTION,” treat it as unknown and read the file line by line, because a custom license is exactly where the restrictions hide.

Once you know the license, complying with it is usually small but not optional. A permissive license means keeping the LICENSE file and reproducing the copyright notice wherever you distribute the code; Apache-2.0 also asks you to carry any NOTICE file and to state significant changes you made. A copyleft license means being ready to hand over the corresponding source on request.

Most teams automate this with an SPDX or license-scanning step in their pipeline, so a GPL or source-available dependency gets flagged before it reaches a release instead of surfacing later in an acquisition audit.

Open-core, dual-licensing, and relicensing

Open source is not anti-commercial, and two business models built on it explain most of the licenses you meet in enterprise software.

Open-core pairs an open-source core with proprietary features sold as an enterprise tier. GitLab, Label Studio, and many observability tools work this way. The core is open source you can self-host and use freely; the paid tier adds things like single sign-on, audit logs, or vendor support.

The point to watch is which features sit behind the wall, since the open core is sometimes missing the one capability you actually need.

Dual-licensing offers the same code under two licenses at once, usually a strong copyleft license and a paid commercial one. MySQL and Qt are the classic examples. You use the software under the GPL if you are willing to open your own work, or you buy a commercial license that frees you from the copyleft obligation. It is the same code; you choose which set of rules to live under.

A third pattern is relicensing, where a project changes its license over time, sometimes from open source to source-available and occasionally back again. Check the license of the exact version you depend on, not the one the project launched with, because the rules can move underneath you.

Five reasons teams pick open source software

The reasons to prefer open source are practical, not ideological. Five of them come up in almost every adoption decision.

Security is the first. Anyone can inspect the code for flaws, and with a widely-used project, many people do. Open source is not automatically safer, but a popular open project gets more eyes on its security than a closed one, and you can patch a hole yourself instead of waiting on a vendor’s schedule.

Cost is the second: no license fees and no per-seat or per-call metering, though you still pay for hosting and the people who run it.

Freedom from lock-in is the third and often the most valuable. You are not tied to one vendor’s roadmap, pricing, or survival, and if a maintainer walks away or a company relicenses, you hold the source and the right to fork. That is exactly what OpenTofu and Valkey did.

Community is the fourth: popular open projects come with public issues, real documentation, and a pool of engineers who already know the tool, so you hire from a labor market that exists rather than training everyone from scratch.

Auditability is the fifth. You can read exactly what the software does with your data, which matters for compliance, security review, and any setting where “trust us” is not an acceptable answer. A closed binary cannot offer that, and no amount of vendor assurance replaces reading the code.

Four beliefs about open source that do not hold up

Four beliefs cause most of the confusion around the term.

“Free means open source.” Price and openness are unrelated. Freeware is free of charge but closed: you cannot see or change its source. Open-source software is often sold as a hosted service or bundled with paid support. The word free in this world means freedom, not zero dollars.

“It is on GitHub, so it is open source.” GitHub hosts millions of repositories under every kind of term, including proprietary, source-available, and no license at all. A repository with no LICENSE file is not open source by default: without a license, ordinary copyright applies and you have no right to use it. Public and open source are not the same thing.

“Open source means no rules.” Even the most permissive license has obligations, usually preserving the copyright notice and license text, and copyleft licenses ask for much more. Ignoring those terms is a license violation, not a free pass, and it is the kind of thing that surfaces in an acquisition audit.

“The maintainers will fix my bug.” Almost every open-source license ships with an explicit no-warranty clause. The people who wrote the code owe you nothing: no support, no fix, no promise it works at all.

You get the source and the right to change it, which makes maintaining what you depend on your own responsibility. For anything your product relies on, budget for in-house expertise or a paid support contract, and treat community help as a courtesy rather than a service level.

What open source means for AI tools and model weights

Open source in AI follows the same rules as any other software, with one extra wrinkle to understand before you evaluate a tool or a model.

For a tool or library, check the license family, prefer permissive or a copyleft you can live with, and watch for source-available terms. Much of the modern AI stack is open, from orchestration frameworks to eval libraries to vector databases, usually under Apache-2.0 or MIT. When you are deciding what to build on or contribute to, the best open-source projects guide applies these same license checks to real repositories.

For models, the picture is muddier. A model is weights plus code, and many “open” models release only the weights under a custom license with use limits, which makes them open-weight rather than open source. The practical rule for AI is the same as for any software: read the license, place it in a family, and know your obligations before you depend on it.

There is one more reason the license matters more in AI than in most software. Evaluation and observability tools see your prompts, your model outputs, and often your users’ data. An open-source, self-hostable tool keeps that data inside your own infrastructure, where a closed SaaS would route it through a vendor.

When the tool you adopt inspects sensitive traffic, self-hosting becomes a compliance requirement rather than a preference, and only an open license guarantees you can do it.

Where Future AGI fits: Apache-2.0 tools you can self-host

Future AGI ships its developer tools under Apache-2.0, the permissive family described above. One license covers the full path from trace to fix. traceAI instruments your application on OpenTelemetry. The evaluation libraries score what comes back and let you write custom evals for your own definition of correct, and agent-opt turns those scores into a better prompt.

Because the license is permissive and the platform is documented for self-hosting, that loop can run inside your own infrastructure on your own data. The open-source evaluation library walks through what a permissively licensed eval library looks like in practice.

Read the license before the code

Go back to the library you were about to ship on. The question was never whether the code is good; it was whether the license lets you use it the way you plan to.

Now you have a procedure. Open the LICENSE file. Place it in a family: permissive and you can build almost anything, copyleft and you share your changes, source-available or open-weight and you read the restrictions before you commit.

That one habit, reading the license before the code, saves the expensive surprise: the audit that finds a GPL dependency inside a closed product, or the relicensing that changes the rules under a tool you already shipped. Open source gives you freedom, community, and an escape from lock-in, but only within the terms of the license in front of you.

Check what open actually means for the tool you are holding, then build. If that tool is an AI model rather than a library, the open-source versus open-weight LLM guide is the next thing to read.