Open source licenses explained the way most engineers actually need them: there are really only two categories that matter for day-to-day decisions — permissive and copyleft — and almost every license question your team will hit reduces to which category a dependency falls into and what that category obligates you to do when you distribute your product. The legal text varies enormously between individual licenses, but the practical decision tree is short once you know which bucket you're in.
What is an open source license, functionally?
It's the terms under which a copyright holder grants you rights to use, modify, and redistribute their code — rights you wouldn't otherwise have, since copyright law defaults to "all rights reserved." Every open source license grants some baseline set of freedoms (use, modify, redistribute), but they diverge sharply on what they require in return: some require nothing beyond attribution, others require you to release your own source code if you distribute a derivative work. That divergence is the entire reason license choice matters commercially — it determines whether using a dependency is a non-event or a legal obligation on your own codebase.
What's the difference between permissive and copyleft licenses?
Permissive licenses — MIT, BSD, Apache 2.0 — let you incorporate the code into a proprietary product and ship it without releasing your own source. The MIT license open source model is the simplest example: a short, four-clause text requiring only that you preserve the copyright notice and license text, with no patent grant and no reciprocal source-sharing requirement. Copyleft licenses — the GPL family, and more strongly the AGPL — require that if you distribute a derivative work, you make its source available under the same license. The distinction that actually matters day-to-day: pulling in an MIT-licensed library is essentially risk-free for a proprietary product; pulling in a GPL-licensed library into code you distribute can create an obligation to open-source parts of your own application, depending on how tightly the two are linked.
Why do so many teams get tripped up by "weak" vs "strong" copyleft?
Because the obligation's scope differs enormously depending on how a library is used, and that distinction is exactly where legal risk hides. Weak copyleft licenses, like the LGPL, generally only require you to release changes to the licensed library itself, and dynamic linking (calling it as a separate library rather than compiling it directly into your binary) typically doesn't trigger obligations on your own code. Strong copyleft — GPL, and especially AGPL, which extends the obligation to software offered as a network service rather than only distributed as a binary — can pull your own application's source into the release requirement if it's considered a derivative work. Getting this distinction wrong is the single most common way a legal team ends up doing an emergency license audit weeks before a product launch.
What does license choice actually cost you as a maintainer or a consumer?
As a maintainer, it determines who's comfortable adopting your project: permissive licenses maximize commercial adoption because companies don't have to worry about triggering source-release obligations; copyleft licenses trade some adoption for a guarantee that derivative works stay open. As a consumer of dependencies, the cost shows up in compliance overhead — tracking every dependency's license, watching for license changes on version bumps (a maintainer can and occasionally does relicense a project going forward), and catching copyleft dependencies before they reach a distributed product rather than after legal review flags it during an acquisition due-diligence pass.
How do teams track license obligations at dependency-tree scale?
Manually reading license files for a few dozen direct dependencies is manageable; doing it for the thousand-plus transitive dependencies a modern application actually ships is not. Automated license scanning as part of software composition analysis flags license type per package, surfaces copyleft dependencies specifically for review, and catches license changes introduced by a routine version bump — which is the scenario most manual audits miss entirely, since nobody re-reads a license file for a dependency that was already "approved" once.
FAQ
Is open source software always free to use commercially?
Almost always in a narrow financial sense — no license fee — but "free" doesn't mean "no obligations." Copyleft licenses can require you to release your own source code under specific distribution conditions, which is a real cost even without a dollar figure attached.
What license should a new open source project pick by default?
There's no universal answer, but MIT or Apache 2.0 are the most common defaults for projects that want maximum adoption with minimal friction; Apache 2.0 additionally gives you an explicit patent grant that MIT doesn't include.
Does using a GPL-licensed tool internally (not distributed) trigger obligations?
Generally no — most copyleft obligations trigger on distribution, not internal use. Running a GPL-licensed tool on your own infrastructure without shipping it to customers typically doesn't require releasing anything, though AGPL specifically closes part of this gap for network-delivered software.
How common is it to search for open source licenses in languages other than English?
Fairly common — international engineering teams frequently search using local terms (for example, "open source Lizenzen" in German), which is worth knowing if your internal documentation or compliance tooling only covers English-language license text.