Reading OSS Licenses Before You Use Them — Understand the Duties That Reach Your Code

A Japanese edition(日本語版) is available here: OSS を使う前のライセンス見極め.

Written: 2026-05 / Scope: OSS licenses (the framework rests on license texts, so it is fairly portable across jurisdictions; the violations and case law cited center on the US, Germany, and the EU) / last_updated: 2026-05-24 Changelog: 2026-05-24 first published

The scope of this article: this is not about "which license to put on the OSS you write" (granting / selecting a license for your own work). It is about "before you adopt and incorporate OSS that someone else published, working out which license it carries and understanding what obligations that places on your own code."

Where this fits in the series: this is the OSS deep dive of the "rights basics" series. Where the hub article, the pre-ship rights check, gave a quick four-tier overview of OSS by source-disclosure scope (narrow to wide), this article asks: when you actually adopt something, where do you look, and how do you decide?

A few terms (for newcomers):

• OSS (Open Source Software): software whose source code is published and that anyone may use, modify, and redistribute within the license terms.
• SPDX identifier: an industry-standard short name that uniquely identifies a license (e.g., MIT / Apache-2.0 / AGPL-3.0-only). It appears at the top of a LICENSE file or in the license field of package.json.
• Copyleft: a licensing philosophy that requires derivative works to be released under the same terms (GPL / LGPL / AGPL are the canonical examples).
• OSI (Open Source Initiative): the non-profit that maintains the Open Source Definition (OSD) and certifies whether a license is "open source."
• SaaS (Software as a Service): software you use or offer over a network as a service, without installing it in your own environment.
• Binary: an executable file compiled from source code (one form of distribution).
• CLI (Command Line Interface): a tool you operate by typing text commands (e.g., git, npm). In this article it appears as the canonical "invoke as a separate process" combination form — distinct from tighter linking.
• Docker: a technology that packages an app together with its runtime environment into a unit called a "container" for distribution and execution. This article distinguishes the open-source Docker Engine from the commercially-conditioned Docker Desktop (details in the body).
• Dify: an AI-app development platform for building LLM apps and workflows through a GUI. It appears here as an example where an Apache 2.0 base still carries extra conditions for commercial (multi-tenant) use (details in the body).

One thing before we get to the substance. OSS rests on the enormous effort of authors and maintainers around the world — much of it contributed for free. This article works through license obligations dispassionately, but whatever tier a license sits in, our respect and gratitude toward the authors and communities who published their code is constant. Understanding the obligations correctly is, in part, the etiquette of using that work comfortably over the long run and giving back to the ecosystem.

With that said, on to the substance. "It's OSS, so it's free and I can do whatever I want" is half right and half a misunderstanding. For much of OSS, how you combine it with your own code (linking) and how you distribute it (binary / SaaS) can cause a source-disclosure obligation to propagate into your own code. The bottom line is that there are only four things to do: (1) identify the tier from the SPDX identifier → (2) place it on the spectrum by how widely the source-disclosure obligation reaches (narrow → wide) → (3) reconcile it with your combination form → (4) reconcile it with your distribution form. This article works through those four steps, tier by tier.

Start by identifying the "tier" via SPDX

The first step in adopting OSS is checking the SPDX◆ identifier. At the top of a LICENSE file, in the license field of package.json, or in the license field of Cargo.toml, you'll find a short identifier like MIT, Apache-2.0, or AGPL-3.0-only (Go has no license field in go.mod, so check the LICENSE file or pkg.go.dev). Once you have the SPDX identifier (the industry-standard name that uniquely identifies a license), you can place that license on a spectrum by how widely the source-disclosure obligation reaches (narrow → wide).

The axis here measures how widely a "source-disclosure obligation" can reach into your own code (the scope of copyleft). It is not a measure of software quality, nor of "freedom" in the general sense, and it is not a question of which philosophy is better or worse — permissive licenses prioritize "reuse by anyone," while copyleft licenses prioritize "keeping the source open, including for derivatives." Those are differences of purpose (the copyleft side takes the position of "protecting the freedom of users"). This article does not wade into that philosophical debate; it only gives you the material to work out, at adoption time, "where to look, and what obligations reach your own code." It is enough to confirm whether the tier is one you can live with for your particular form of use.

From a side-project / solo-developer's point of view — and for someone in a company deciding whether to adopt OSS — the table below organizes the five tiers by source-disclosure scope, from narrow to wide. Grasp just the "core" of each obligation and you can make the first call.

Sources: OSI Approved Licenses / FSF — Why the AGPL.

One important caution here: "it's OSS, so it's all free" is a misreading. In recent years, "the source is visible but it isn't OSS" licenses have proliferated (we cover them under "Source is visible but it isn't open source" below). Once you've read the SPDX identifier, the reliable move is always to go to the official license page and read the terms in full.

The combination form changes the obligation

Even within the same copyleft license, how you "combine" your own code with the OSS changes how heavy the source-disclosure obligation is. This is where OSS adoption is most often misunderstood. There are roughly four axes — dynamic linking / static linking / separate process (a CLI invocation or standard inter-process communication) / network provision (SaaS).

Let's look at how the combination form plays out license by license.

• LGPL (limited-scope copyleft / weak copyleft): with dynamic linking the obligation is limited, and your own code can stay under its own license. The thing to watch is static linking. You satisfy the obligation by providing a way for users to replace and re-link the LGPL library themselves (for example, by supplying object files) (LGPL-3.0 §4). It's an obligation that's often overlooked when you've "just statically linked" it.
• GPL (whole-work copyleft / strong copyleft): the boundary of "derivative work (combined work)" is the biggest point of contention. The FSF takes the position that linking of any kind makes something a derivative (dynamic linking included), while Linus Torvalds, the creator of the Linux kernel, holds that "user-space programs are not derivatives" — and the reality is that much of this has not been clarified by case law. In practice, for example, if you don't want to disclose the source of your own code, you can choose LGPL, or draw a clear process boundary using a separate process plus standard input/output. Conversely, if you're fine with — or actively want — disclosure, you can combine it under the GPL as is.
• AGPL◆ (network copyleft): when users interact with the program over a network, you may be required to offer a way to obtain the corresponding source of the modified version (a download link, etc.). That said, if you simply use it as-is without modification, the obligation tends to be limited, whereas the scope of the corresponding source changes depending on how you modify, combine, and offer it as a unit. Because the trigger scope depends on the combination, modification, and distribution forms, you need to check the official text and a specialist (don't jump to conclusions).

Sources: Mozilla MPL 2.0 / OSI LGPL-3.0 / FSF — Why the AGPL.

The "source is visible but it isn't open source" trap

Even when source is published on GitHub, that doesn't make it "open source." Licenses called source-available (the source is visible but it isn't OSS) have become prominent since 2018 (starting with MongoDB's SSPL), aiming to deter "free-riding" — hosted resale by cloud providers. The OSI does not recognize these as OSS, primarily on the grounds that they violate OSD clause 6 (no discrimination against fields of endeavor) (clause 9, that a license must not restrict other software, also comes up as a point). Here are the representative examples.

• BSL 1.1 (Business Source License): after a set period (up to four years), it automatically converts to an OSS license such as the GPL. Until then, the permitted scope of use is governed by an "Additional Use Grant" defined by each project, so the actual restrictions (whether production use or offering a competing service is allowed, etc.) differ from project to project. It originates with MariaDB, and HashiCorp adopted it in 2023.
• SSPL (Server Side Public License): when you offer the software as a service, it requires disclosure of the source of the entire stack, including the management UI and storage. Adopted by MongoDB (2018), Elastic (2021, though in 2024 AGPLv3 was added as an option, with ELv2 (Elastic License v2) / SSPL still available), and Redis (2024, though from Redis 8 onward AGPLv3 can also be chosen).
• ELv2 / RSAL / CCL: condition use on things like prohibiting the provision of a hosted service or a competing SaaS (Elastic / Redis / Confluent).

The practical point here is that reselling the software itself as a hosted service can put you in breach, whereas using it internally, or as one component of your own service, is often not a problem (but because the prohibited forms of provision differ by license, check each license's terms before adopting it). Work out your own form of use and you don't need to be excessively afraid.

And licenses move. Redis migrated from BSD to SSPL/RSAL in March 2024, and immediately afterward the Linux Foundation forked Valkey. In May 2025 it added AGPLv3 (selectable alongside RSALv2 / SSPLv1), and if you choose AGPLv3 you can use it as OSI-approved OSS. Getting into the habit of checking the license-change history before adopting something pays off.

Two everyday examples that people commonly get wrong. The AI-app development platform Dify is based on Apache 2.0, but "operating it as a multi-tenant environment" requires a separate commercial license (written approval) (in Dify, one tenant = one workspace), and it also requires retaining the logo and copyright notices in the console and apps (use that does not employ the front end is out of scope). Testing or internal use of a single workspace is usually unlikely to be a problem, whereas separating multiple workspaces to offer the platform to a whole company or to multiple customers can fall within scope. If you don't have a grip on "what's running where," you can brush up against the terms without realizing it — so confirm the line in the official terms.

License-related "free traps" aren't limited to OSS. Docker Desktop is free for personal use, education, non-commercial OSS, and small businesses (fewer than 250 employees and less than US$10 million in annual revenue), but business use beyond that scale requires a paid subscription. On the other hand, Docker Engine (the open-source container runtime) remains free, so larger organizations face a choice of "pay for Docker Desktop" or "substitute Engine plus another approach." (This is not about an OSS tier; it's an example of per-product commercial-license design.)

The fine print — patent clauses and contribution rules

From here we go one step deeper into the specifics. First, there are differences even within the permissive tier. MIT and BSD say nothing explicit about patents, leaving room to be sued over a contributor's patent. Apache 2.0, by contrast, has an explicit patent grant plus a retaliation clause that terminates your rights if you bring a patent suit, and it also requires retaining the NOTICE file. Note that Apache 2.0 and GPLv2 have incompatible clauses (Apache is one-way compatible with GPLv3). The point to remember is that "they're all permissive, so they're all the same" is false.

Next, the rules for those who contribute. OSS includes dual / triple licensing, where the same code is distributed under multiple licenses (e.g., MySQL is GPL + commercial; Redis 8 has three), a strategy often used to earn revenue from the commercial edition while keeping a community via the OSS edition. What matters here is the difference between a CLA and a DCO.

• CLA (Contributor License Agreement): a contract in which a contributor grants the project a broad copyright license (or an assignment). Depending on its contents, the maintainers can change the license more easily later (how far is possible depends on the CLA's clauses). MongoDB, Elastic, Redis, and HashiCorp all use a CLA, which is generally seen as having helped their later relicensing.
• DCO (Developer Certificate of Origin): a lightweight procedure where a Signed-off-by line at the end of a commit attests that "I have the right to license this." It does not transfer copyright; each contributor remains the copyright holder. So, unlike a CLA, the maintainers cannot relicense unilaterally — a change generally requires the agreement of all contributors, which is effectively impossible in a large project. (The Linux kernel, for instance, has not moved to GPLv3 mainly because its lead developers objected to GPLv3's tivoization and related clauses and deliberately kept it "GPLv2 only"; on top of that, its distributed copyright ownership across thousands of contributors makes any unilateral relicensing impractical.)

Whether the project you contribute to could change its license in the future — you can get a sense of that from whether it uses a CLA.

What case law shows: "the license isn't just decoration"

OSS licenses are not declarations that exist only for show; they are enforceable conditions that courts have repeatedly upheld as valid. In the US, Jacobsen v. Katzer (2008, Court of Appeals for the Federal Circuit — a case concerning the Artistic License, one kind of OSS license) established that the conditions of an OSS license are "enforceable copyright conditions" — and that a violation is not a mere breach of contract but can be enjoined as copyright infringement. In embedded devices, GPL violations have been frequent, and in a series of suits over BusyBox (from 2007), vendors that failed to provide source were driven to settle or to release their source, while Westinghouse, which defaulted, was ordered to pay treble damages.

At the same time, enforcement has its limits and contested points. In Germany's VMware lawsuit (2015–2019), the plaintiff could not sufficiently identify his protectable modifications or show their incorporation into VMware's vmklinux, and the claim was dismissed (the unresolved question was whether vmkernel and GPL-derived code formed a combined work — i.e., a derivative work — not a "collective work"; the case was dismissed on the evidence before reaching it). The lesson: in collaboratively developed GPL code, proving individual contributions and their incorporation carries a heavy evidentiary burden. And monetization-driven activity that uses minor violations as leverage to demand settlement money (the McHardy case) is distinguished from community-minded enforcement: in Geniatech v. McHardy the Cologne court signaled it found his contributions insufficiently substantiated and his motive monetary, after which McHardy withdrew all proceedings and was ordered to pay costs, and the netfilter project later reached a binding settlement constraining such enforcement.

The other lesson is that migrating to source-available triggers forks. Elastic produced OpenSearch, Redis produced Valkey, and HashiCorp (Terraform) produced OpenTofu. In the Elastic case a trademark was also involved: AWS renamed its managed service from Amazon Elasticsearch Service to Amazon OpenSearch Service (it helps avoid confusion to remember that the name = a trademark, which is a separate layer from the license on the source code). When a product you've adopted changes its license, the wise move is to assess — including whether you can move to a fork.

Summary — a pre-adoption OSS checklist

The order of operations is "identify the tier via SPDX → combination form → distribution form → change history." Paste the list below into a LICENSE note or a PR description and check it before you ship. Note that this list is not a final legal determination; it is a first-pass screen for working out whether you should consult a specialist.

□ 1. Checked the SPDX identifier (top of LICENSE / package.json / Cargo.toml, etc.; for Go, the LICENSE file or pkg.go.dev)
□ 2. Decided up front how much source-disclosure your own work can accept (= how far you're willing to open your own source)
□ 3. Identified where the OSS sits by how widely the source-disclosure obligation reaches, narrow → wide (PD〔public domain〕/ permissive / limited- or whole-work copyleft / AGPL / source-available / commercial)
□ 4. Checked the combination form (dynamic / static linking / separate process / SaaS)
□ 5. Checked the distribution form (binary / SaaS / internal only; AGPL may require providing the corresponding source when a modified version is offered over a network)
□ 6. Prepared to meet the obligations (retaining copyright notices / NOTICE, providing source for modified parts, etc.)
□ 7. Inventoried transitive dependencies as well, via an SBOM (a software bill of materials)
□ 8. Checked whether it's a "source is visible but it isn't OSS" license (SSPL / BSL, etc.)
□ 9. Checked the license-change history (future migration risk)
□ 10. Recorded the basis for the adoption decision (why it was judged OK)

References

Centered on primary materials. A trailing (primary) marks a primary source; (supporting) marks commentary used to locate the primaries.

Official / definitions

• OSI — Licenses(primary)
• OSI — The SSPL is Not an Open Source License(primary)
• FSF — Why the GNU Affero GPL(primary)

License texts

• Apache License 2.0(primary)
• GPL-3.0 / LGPL-3.0 / AGPL-3.0(primary)
• MariaDB BSL 1.1 / MongoDB SSPL / Elastic License v2(primary)

Product / service terms (terms can change; all confirmed as of 2026-05)

• Docker Desktop license terms (Docker official)(primary)
• Dify Open Source License(primary)

Case law / license migrations

• Jacobsen v. Katzer (535 F.3d 1373, CourtListener)(primary) / Jacobsen v. Katzer (Wikipedia)(supporting)
• BusyBox GPL enforcement — Westinghouse injunction (SFC, 2010-08-03)(primary) / BusyBox (Wikipedia)(supporting)
• SFC — VMware Lawsuit FAQ(supporting)
• Redis — What is Valkey?(supporting)
• OpenTofu — Fork of Terraform(supporting)

On AI assistance: Starting from points the author already knew, the author asked Claude (an LLM by Anthropic) to research, organize, and summarize, then added to and revised the result while verifying the primary sources — each license's official text and the case law — for themselves. For the "not legal advice" note and what is out of scope, see the disclaimer at the top.

About the author

More than 20 years of electrical and software development — from control engineering at a major electronics manufacturer — plus about 10 years of solo development. Across hardware and software, and across enterprise and individual work, I publish the basics that "become a risk if you don't know them," and I plan to cover practical ways to use AI as well. More at About this blog.