open source licenses explained for developers

Open Source Licenses Explained for Developers (October 2026)

by 19 min read

An open source license is a legal, OSI-approved set of permissions that lets anyone use, inspect, modify, and redistribute a piece of software, provided they follow the conditions attached to it. In practice that almost always means keeping the copyright notice and the license text; for copyleft licenses it also means publishing the source of anything you distribute.

For a developer, the license is the part of a dependency that actually constrains you. Everything else in the manifest, the build script and the readme can be rewritten, but you cannot use code in a way its author did not permit, and you cannot retroactively loosen terms you already granted.

Table of Contents

What Is an Open Source License?

What Is an Open Source License?

An open source license is a grant of copyright permissions that anyone may exercise for free, as long as they comply with the conditions. The license travels with the code: it covers the files in the repository, and it keeps covering them when someone forks the repo or vendors a copy into another project.

That last point is the one people miss. A license is not a badge on a website and not a GitHub setting. It is a promise from the copyright holder, attached to the files, and it follows those files everywhere they go.

The Open Source Initiative maintains the Open Source Definition, which any OSI-approved license must satisfy. The definition boils down to ten criteria, of which these are the ones that shape day-to-day developer decisions:

  1. Free redistribution is allowed, for commercial and non-commercial purposes alike.
  2. Source code must be available whenever the software is redistributed.
  3. Licences may be distributed in source form only.
  4. Users may modify the software and distribute the modifications.
  5. Modified versions must be distributed under the same licence.
  6. There is no discrimination against persons, groups or fields of endeavor.
  7. Every right not granted explicitly is withheld, so nothing is given away by default.
  8. Derived works inherit the conditions of the licence they came from.

Three other categories get mixed into the same conversations and confuse everyone. Public-domain dedication, like CC0 or the Unlicense, removes restrictions entirely rather than granting permissions under conditions. Proprietary terms grant nothing at all. Source-available licences such as the Business Source License, SSPL and the Elastic License let you read the code but add restrictions that OSI would reject, so they are not open source in the strict sense even when they are sold as open core.

Open Source Licenses Explained for Developers: Quick Comparison

Open Source Licenses Explained for Developers: Quick Comparison

The table below is the one I keep open in a second window while reviewing dependency trees. It is deliberately narrow: family, the single obligation that actually drives decisions, commercial use, patent treatment, and the exact SPDX identifier your tooling will report.

License Family Main obligation Commercial use Patent grant SPDX identifier
MIT Permissive Keep copyright and license text Yes No MIT
Apache 2.0 Permissive Keep notices, mark changes, carry NOTICE file Yes Yes, express Apache-2.0
BSD 3-Clause Permissive Keep notices, no endorsement of your product Yes No BSD-3-Clause
MPL 2.0 Weak copyleft Publish source of modified files only Yes Yes, express MPL-2.0
LGPL 3.0 Weak copyleft Library changes stay LGPL, allow relinking Yes Yes, express LGPL-3.0-only
GPL 3.0 Strong copyleft Publish full corresponding source when distributed Yes Yes, express GPL-3.0-only
AGPL 3.0 Strong copyleft Same, plus source offer to remote network users Yes Yes, express AGPL-3.0-only

Two things stand out. Only Apache 2.0, MPL 2.0 and the GNU family grant patent rights explicitly, which is the single biggest practical difference between MIT and Apache 2.0. And every licence here allows commercial use: that is a separate question from whether you must publish your changes.

How to Read a License Without Going Down a Rabbit Hole

You do not need to read every licence end to end. Four checks answer the question that actually matters: can I use this, and what do I owe if I do.

1. Find the authoritative text. Check for a LICENSE, COPYING or LICENSE.md at the repository root, then the license field in package.json, setup.py, Cargo.toml or Cargo.toml metadata. Scanners such as GitHub’s own detection are good at locating the file; they are less reliable at telling you whether a bundled dependency in node_modules carries a different licence than the repository root suggests.

2. Separate permissions from conditions. The permission half is nearly identical everywhere: use, copy, modify, distribute. The condition half is where licences diverge, and it is the only part you need to track in a checklist.

3. Check whether more than one licence applies. A repository may hold an Apache 2.0 root licence while individual directories carry a different one, or the project may be offered under a choice of two licences. Dual licensing means you pick the one you want to comply with, and you must comply with it fully rather than mixing clauses.

4. Read exceptions and extra notices separately. A string like Apache-2.0 WITH LLVM-exception is a licence plus a carve-out that removes one condition for a specific set of files. Organisation-specific files, such as a NOTICE or a CONTRIBUTING document, can also add real obligations, particularly around trademark use and publicity rights.

What Can You Do with Each License?

Every OSI-approved licence lets you run the software, study it, modify it and redistribute it, commercially included. The difference sits entirely in what you owe back and in how far that obligation reaches.

Copying and modifying are always fine. So is keeping your work private: if you use an MIT-licensed library in a tool that never leaves your machine, no obligation triggers, because copyleft obligations attach to distribution, not to use. The moment you ship a binary, an image, or a hosted service to someone else, the conditions wake up.

Redistribution is where people get it wrong. Being able to read the source is not the same as being allowed to redistribute it. If a package has no licence file at all, copyright law applies by default and every right is reserved: you have no permission to copy it, modify it, or ship it, even though the repository is public and you can see every line. That trap is the reason r/programming and r/opensource threads keep circling back to the same question. Ask for a licence or drop the dependency.

And linking is not automatically making a derivative work. The distinction matters more than any other point in this article, so it is worth stating plainly: linking to a library across a process boundary, calling a command-line tool, or communicating over a network is generally not a derivative work. Copying code into your own files, or shipping a modified version of the library itself, is.

MIT License: Simple and Flexible

The MIT licence is the default for a reason: one permission paragraph, one attribution condition, about twenty lines of text. You can use, copy, modify, merge, publish, distribute, sublicense and sell the code, and the only condition is keeping the copyright notice and the permission text in your copies.

Two limitations are worth stating out loud. There is no explicit patent grant, so a patent filed by the original author is not licensed to you the way Apache 2.0 licenses one. And because the conditions are so light, the licence offers no mechanism to keep improvements flowing back.

It is a good fit for small libraries, examples, scripts, tutorials, internal tooling you are happy to publish, and anything where you want maximum downstream compatibility. Reuse, forks and contributions all tend to go well. React, Ruby on Rails, VS Code and Babel are all MIT for the same practical reason: the shortest possible conditions make it the easiest licence for anyone else to accept.

Apache License 2.0: Strong Protection for Larger Projects

Apache 2.0 is permissive like MIT, but it does three things MIT does not: it grants an express patent licence, it asks you to carry a NOTICE file forward, and it asks you to mark what you changed.

The patent grant is the headline feature. Each contributor grants a perpetual, worldwide, royalty-free patent licence covering their contributions, and it terminates if you start patent litigation alleging the software infringes. For companies shipping software at scale, that clause is often the deciding factor between MIT and Apache 2.0.

The NOTICE requirement is where r/androiddev threads get stuck. If the upstream project ships a NOTICE file listing its contributors, you must include a copy of that NOTICE in your distribution, and you must keep it intact for the parts you did not modify. Separately, changed files need to carry prominent notices that you altered them, which in practice means updating the header in files you have touched rather than stripping it. Neither obligation requires you to open-source your own code.

There is one catch developers should know before choosing it. Apache 2.0 cannot be combined with GPL version 2 only, because the patent clause and the GPLv2 patent rules conflict. That single incompatibility drives a large share of the advice you will read telling people to prefer MIT, and we will come back to it in the compatibility section.

BSD Licenses: Permissive with Important Differences

BSD is a family, and only two variants matter in practice: the two-clause version and the three-clause version. Both are permissive in the MIT sense, with the same core permission and attribution structure.

The difference is the third clause. BSD 3-Clause adds a condition that the original authors may not be used to endorse or promote your products without permission. BSD 2-Clause has no such clause, which makes it slightly more permissive than MIT in theory. There is also a four-clause advertising variant that is effectively retired and rarely used.

When to choose BSD over MIT: when your organisation’s legal team has a policy that prefers the three-clause form, when you want the non-endorsement protection without the Apache 2.0 patent and NOTICE obligations, or when you are matching an existing codebase’s conventions. Otherwise MIT is simpler, and in practice the two are interchangeable for most projects.

GPL Licenses: Sharing Requirements for Distributed Software

The GNU General Public License is strong copyleft: when you distribute software covered by the GPL, you must distribute the complete corresponding source under the same licence, including the source of your own modifications.

Version 3, released in 2007, tightened several things. It requires an express patent grant, added an anti-tivoization clause that stops you shipping a device that runs the software but blocks you from installing modified versions on it, added a requirement that you assist with installation information for consumer products, and improved its compatibility with licences that include patent clauses, which is precisely why Apache 2.0 works with GPLv3 but not with GPLv2 only.

Modification is not the same as aggregation. Shipping GPL libraries in the same container as your application, or calling a GPL library from your own code, does not automatically make your application a derivative work; the question is whether your product is a combined work based on that library. This is the least settled area of open source law, and a developer who is genuinely unsure should get a real legal opinion rather than rely on an FAQ.

The trigger is distribution. Running GPL software internally, or modifying it for your own servers without offering the result to anyone else, does not require you to publish anything. Shipping it, in any form, is what starts the clock.

LGPL: A Weaker Copyleft Boundary for Reusable Code

The LGPL exists for one reason: to let library authors get the benefit of copyleft without making the licence unusable for proprietary applications. It applies copyleft to the library itself and leaves the application that uses it alone.

The mechanism is relinking. If you distribute an application that uses an LGPL library, you must let users replace that library with a modified version of their own. Dynamic linking through a shared object does this naturally. Static linking used to require you to ship the object files needed for relinking; version 3 relaxed that considerably, and the practical position for most modern builds is that using an LGPL library in your proprietary application is fine.

Distributing a modified copy of the LGPL library itself is a different act. That modified library must stay under the LGPL, and its source must be available. Linking your code into the library’s own files puts you in copyleft territory.

MPL: File-Level Copyleft for Mixed Codebases

The Mozilla Public License 2.0 is file-level copyleft. If you modify a file that carries MPL 2.0, you must publish that file’s source under MPL 2.0. Files you add are yours to license however you like.

That boundary is the interesting part. You can build a proprietary application that links to MPL code, publish it as closed source, and only the modified MPL files travel outward. In a large codebase that mixes in-house modules with open source components, MPL gives you the community benefit without dictating the licence of the whole product.

MPL 2.0 also carries an express patent grant and a notice requirement, and it plays reasonably well with GPLv2, GPLv3 and Apache 2.0 code in the same tree. It is less common than MIT in the wild, so you will more often encounter it as a dependency than choose it deliberately, but browsers and large platform vendors have historically used it for components they want to keep patchable.

AGPL: Copyleft That Reaches Network Use

The Affero General Public License is GPL version 3 with one addition, and that addition is Section 13. If you modify AGPL software and let users interact with it remotely over a network, you must offer those users the corresponding source of your modified version, even if you never distributed a copy as a download.

GPL left a gap here. You could run modified GPL software as a web service and never touch the distribution trigger, which is how the licence ended up protecting against copying but not against hosting. AGPL closes that specific gap, and it was written with a clear target: commercial hosting of modified free software.

That is why AGPL deserves extra scrutiny before you adopt it or combine it. A hosted application built on an AGPL dependency may need to publish source. An organisation that has committed to keeping its platform closed should know exactly which repositories in its dependency tree carry AGPL before an auditor finds them. It is also why r/rancher and other open-core communities object to the framing of a free version as a trial: if the licence is AGPL, the host obligation is a licence term, not a business model choice.

What Must You Include When You Redistribute Code?

Distribution triggers obligations, and the list is short enough to run against any dependency. Copy the upstream LICENSE file verbatim into your distribution. Keep every copyright notice intact, including headers in individual files if the project used them.

Carry any NOTICE file forward unchanged, and keep the attribution list in it. Mark the files you modified, as Apache 2.0 and most copyleft licences ask you to. If the licence is copyleft, distribute the complete corresponding source of the covered work, including build scripts needed to rebuild it and installation information where the licence requires it.

Then handle upstream attribution. If you vendor a dependency rather than linking it from a registry, record where it came from and at which version, so you can reproduce the build later. Finally, make sure your own package metadata is honest: the SPDX identifier in package.json, pyproject.toml or Cargo metadata should match the licence text in the repository root, and it should name an exception when one applies, such as Apache-2.0 WITH LLVM-exception.

How Do License Obligations Affect Dependencies?

A dependency’s licence becomes your problem the moment you ship something containing it. Package managers do not settle this for you, which is why r/opensource users are advised to prefer MIT or BSD over Apache 2.0 for compatibility reasons alone: the narrower the conditions you inherit, the fewer combinations you can fall into.

The reach is transitive. If library A is MIT and it depends on an LGPL library, you inherit the LGPL terms for that part of the tree. Container images complicate this because a single image can bundle hundreds of packages under dozens of licences, and the image as a whole is what gets distributed. Redistributed binaries are the same problem in compiled form: you are shipping object code, and every copyleft obligation attached to any component in it applies.

SaaS is the case where rules change shape. Plain GPL code running on your servers triggers nothing. AGPL code does, through Section 13. Whether a dependency is SaaS-exposure is a question licence scanners answer badly, which is why scanner output needs human review rather than a blind pass or fail.

Open Source Licenses Explained: Compatibility With Your Dependencies

Compatibility is the practical answer to the contradictory advice developers find online. Two licences are compatible when code under one can be combined with code under the other and distributed under a single set of terms. The four rules that bite most often:

  1. GPLv2 and GPLv3 are not compatible with each other. Code under GPLv2-only and code under GPLv3-only cannot be combined into one distributed work under a single licence. This surprises people because both are called the GPL.
  2. Apache 2.0 is incompatible with GPLv2 only, and compatible with GPLv3. The Apache patent termination clause conflicts with GPLv2’s patent rules. This is the single most cited reason to pick MIT or BSD for a library.
  3. Permissive licences slot into almost anything. MIT, BSD and Apache 2.0 code can be included in a GPL or AGPL project; the copyleft obligation of the combined work governs the whole, and the permissive code stays compatible.
  4. LGPL and MPL exist to make the boundary workable. LGPL 3.0 can be relicensed into GPLv3, and MPL 2.0 is generally compatible with GPLv2, GPLv3 and Apache 2.0. Exceptions such as the LLVM exception change a specific condition, not the whole licence.

Read the direction of the matrix carefully: a licence is often compatible one way and not the other. MIT code can go into an AGPL project without anyone asking you to relicense anything.

How to Choose an Open Source License for Your Project

Choose based on what you want to happen to your code, then check compatibility with what you already depend on. The questions that actually decide it are short: do you want anyone to be able to build a closed-source product on top, do you want your improvements to come back, and does your organisation need patent protection?

The table turns those questions into a decision:

If this describes your project Then start with Why
A small library others will build on MIT Shortest conditions, widest compatibility, easiest contribution
A company shipping software at scale Apache 2.0 Express patent grant, NOTICE and change marking
A project that must avoid the GPLv2 patent clash MIT or BSD 3-Clause No patent clause, so no incompatibility
You want modifications published GPL 3.0 Strong copyleft, patent grant, anti-tivoization
A library others will link into proprietary apps LGPL 3.0 or MPL 2.0 Copyleft scoped to the library or to modified files
A hosted service where you want to stay closed Not AGPL 3.0 Section 13 would require a source offer to your users
Documentation, data or assets, not code CC0 No conditions attached to the content

Organisation policy is the last input. Some companies restrict copyleft in shipped products, some require a patent grant in anything external, and some have an approved licence list already written into their open source program office policy. When such a policy exists, it outranks your personal preference.

Common License Mistakes Developers Make

Stripping copyright headers is the most common mistake and the easiest to fix. A build step that strips comments from vendored files turns a compliant distribution into a non-compliant one, and the removal is invisible until someone audits it.

Treating a package registry as an approval is the second. Being on npm or PyPI says nothing about the licence, and forks and internal packages regularly carry a different one from the repository you read. Read the metadata on the exact version you ship.

Ignoring NOTICE files is the third. r/androiddev developers shipping apps repeatedly ask whether Apache 2.0 NOTICE duties apply to a compiled binary: they do, because the NOTICE travels with the distributed work, and the answer does not change because the code was compiled.

The last three are about ownership. You cannot apply a new licence to code you did not write, and you cannot take an MIT-licensed library and relicense it as your own. Ignoring dual-license terms is the same error in a different costume: an offered choice of two licences means you pick one and follow it entirely.

What Changes When You Contribute Code?

Contributing does not hand over your copyright by default. Absent an agreement, you keep it, and the maintainer’s project licence covers everyone else’s contributions under a licence you granted into a pool the maintainer now owns.

A contributor licence agreement changes that: you grant the project broad rights to use, modify and sublicense your contribution, usually while you keep copyright. A Developer Certificate of Origin does something lighter, requiring you to affirm that you have the right to submit the code and that it is your own, usually signed with a commit trailer rather than a signature.

The practical consequence shows up when a project wants to change licence. A maintainer can relicense only contributions they can relicense, so a permissive CLA lets them do it and a DCO-only history often does not. r/programming threads on projects that changed licence mid-flight usually trace back to this exact question: whether the old contributions could follow the code to its new home. If relicensing matters to you, ask about the agreement before your first commit rather than after a hundred of them.

Frequently Asked Questions

Can I use open source code in a commercial product?

Yes. Every OSI-approved license permits commercial use, including the GPL family, and that permission applies whether you sell the software or use it to build something you sell. The trade is conditions, not commerce. Permissive licenses like MIT and Apache 2.0 ask you to keep notices, while GPL and AGPL ask you to publish the corresponding source of the distributed work. A dependency with no license at all is different: it grants you nothing.

Which open source license is best for developers starting a new project?

For a library or a tool you want other people to build on, MIT is the safest default: short conditions, no patent clause to reason about, and it drops into almost any project including copyleft ones. Apache 2.0 is the better pick for a company shipping software at scale because it carries an express patent grant. Pick GPL or MPL only when you actively want your changes to come back, and check your dependencies for compatibility first.

Do I need to publish my entire application if I use GPL code?

Only if your application is a derivative work or a combined work based on the GPL code, and only when you distribute it. Linking to a GPL library across a process boundary, shipping it in the same container, or calling a command-line tool does not by itself make your app a derivative work, though this is the least settled area of the law. Running GPL software internally with no distribution triggers nothing at all. If your application is a genuine derivative work, the whole covered work must go out under the GPL with source.

Can I change the license of code I did not write?

Not without permission. You can relicense your own code at any time, and you can relicense a project if you own or control the copyright in all of it, which usually means a contributor license agreement was in place. You cannot take an MIT-licensed library and relicense it, and you cannot relicense contributions you merely accepted into a project. Dual-licensed projects work the other way around: pick either of the offered licenses and follow it fully.

What is the difference between GPL and LGPL for a library?

GPL is strong copyleft: any distributed work based on the library must be published under the GPL with full source. LGPL is weak copyleft scoped to the library itself. If you link an LGPL library into a proprietary application and ship the application, the application can stay closed, and you must let users substitute a modified version of the library. Distributing a modified copy of the LGPL library is different: that copy must remain LGPL with its source available.

Do I need to open source code that only runs on my server?

It depends on the license, and this is where AGPL changes the answer. Under the GPL, obligations trigger on distribution, so running modified GPL software on your own servers and offering it to nobody requires nothing. Under the AGPL, Section 13 extends that obligation to remote network interaction: if users interact with your modified AGPL program over a network, you must offer them the corresponding source. That is why SaaS teams audit for AGPL before deploying.

Conclusion

Start with the repository: find the LICENSE file at the root, confirm it matches the SPDX identifier in your package metadata, and if there is no licence at all, treat the code as unusable until you get one. Then map your dependencies and look for copyleft and AGPL components in the tree, especially anything vendored into a container image.

Next, decide how your project is actually distributed, because that determines which obligations can ever trigger: a private internal tool, a shipped binary, a library, or a hosted service. Once you know that, choose a licence that matches your intent, and check its compatibility with the licences already in your dependency tree before you publish rather than after someone else builds on it.

Leave a Comment

Keep reading