Open Source Licensing
An open-source license is the legal document that grants everyone permission to use, modify, and distribute a piece of software — and sets the conditions for doing so. It's easy to treat licensing as boilerplate, but it has real consequences: the license determines whether you can use a library in a commercial product, whether you must share your own modifications, and whether two dependencies can even legally coexist. Choosing a license for your project, and respecting the licenses of your dependencies, is a responsibility every developer eventually faces.
⚠️ The single most important fact: **code with no license is not open source.** Without a license, default copyright law applies and nobody has permission to use it. Posting code publicly on GitHub does not, by itself, grant any rights.
The licenses split into two broad families — permissive (do almost anything, just keep the notice) and copyleft (you may use it, but derivative works must stay open) — and understanding that distinction covers most practical decisions.
TL;DR
- A license grants permission to use, modify, and distribute — and sets conditions.
- No license = not open source (default copyright; nobody may use it).
- Permissive (MIT, Apache) — minimal conditions; copyleft (GPL) — derivatives must stay open.
- Check dependency licenses for compatibility and compliance, especially in commercial products.
Quick Example
The practical question every license answers:
Permissive vs Copyleft
- Permissive (MIT, BSD, Apache 2.0) — use the code almost however you like, including in proprietary products, as long as you preserve the copyright/license notice. Minimal obligations; maximally business-friendly.
- Copyleft (GPL, LGPL, AGPL) — you may use and modify the code, but if you distribute a derivative work, you must release it under the same license (keep it open). Designed to keep software free; imposes a "share-alike" obligation.
The distinction is what you owe back: permissive asks for attribution; copyleft asks for reciprocity.
The Major Licenses
💡 MIT and Apache 2.0 are the most common permissive choices; Apache 2.0 is often preferred for its explicit patent protection.
Choosing a License for Your Project
- Want maximum adoption / business-friendly → MIT or Apache 2.0 (Apache if you want patent protection).
- Want derivatives to stay open → GPL family (AGPL if you care about SaaS/network use).
- No preference but want it usable → MIT is the simple default.
- Always include a
LICENSEfile — without it, your "open" project legally isn't.
Compliance Basics
Using open-source dependencies comes with obligations:
- Preserve notices — keep copyright and license text for the libraries you use.
- Check compatibility — some licenses can't be combined (e.g. you generally can't include GPL code in a proprietary product you distribute).
- Watch copyleft in distributed software — GPL/AGPL can require you to open-source your code; understand the trigger (distribution vs network use).
- Scan dependencies — tools (FOSSA, license checkers, GitHub's dependency insights) flag license risks across your tree.
Best Practices
- Always add a
LICENSEfile to projects you publish — no license means no rights. - Default to MIT or Apache 2.0 for permissive, business-friendly projects.
- Know your dependencies' licenses — especially copyleft, in commercial/distributed software.
- Preserve attribution/notices for code you use.
- Consult a lawyer for high-stakes commercial licensing questions — this page is orientation, not legal advice.
Common Mistakes
Publishing code with no license
Ignoring copyleft obligations in a product
FAQ
What's the difference between permissive and copyleft licenses?
Permissive licenses (MIT, BSD, Apache 2.0) let you do almost anything with the code — including using it in closed-source commercial products — as long as you preserve the copyright and license notice. They impose minimal obligations. Copyleft licenses (GPL, AGPL) let you use and modify the code but require that distributed derivative works be released under the same open license ("share-alike"). The core difference is reciprocity: permissive licenses just want attribution; copyleft wants you to keep derivatives open. Which you choose (or can use) depends on whether keeping software free or maximizing adoption matters more.
Is code on GitHub automatically open source?
No — and this is a critical, widely misunderstood point. Posting code publicly does not grant anyone permission to use it. Without an explicit open-source license, default copyright law applies, meaning the author retains all rights and no one else may legally use, modify, or distribute the code (beyond what platform terms allow for viewing/forking on the platform). To make a project genuinely open source, you must add a license (a LICENSE file). "Public" and "open source" are different things; the license is what grants the rights that make it open.
Which license should I choose for my project?
If you want maximum adoption and to allow use in commercial/proprietary software, choose a permissive license — MIT for simplicity, or Apache 2.0 if you also want an explicit patent grant (valuable protection for both you and users). If you want to ensure that anyone who builds on your code keeps their derivatives open, choose a copyleft license — GPL, or AGPL if you also want to cover networked/SaaS use. MIT is the safe default when you just want your code to be freely usable. Whatever you pick, include the LICENSE file.
Can I use GPL-licensed code in my commercial product?
It depends on what "use" means and whether you distribute. The GPL is copyleft: if you distribute software that incorporates GPL code as a derivative work, you generally must license your distributed software under the GPL too — open-sourcing it. That's usually incompatible with a proprietary product. Some nuances exist (LGPL allows linking from proprietary code; AGPL extends obligations to network/SaaS use; "mere aggregation" and internal-only use have different treatment), and the details are legally fact-specific. For commercial products, prefer permissively-licensed (MIT/Apache) dependencies, and consult a lawyer when GPL/AGPL code is involved — this is orientation, not legal advice.
Related Topics
- Contributing to Open Source — Know the license before contributing
- Building OSS Projects — Choosing a license for your project
- Package Managers — Dependency license compliance
- Open Source — The hub
- Secrets Management — Don't publish secrets with your code