Open Source Licensing in 2026: A Practical Guide for Developers
I’ve seen projects die because of a license.
Not because the code was bad. Not because the community was toxic. But because the founder picked the wrong license and couldn’t undo it. Once you release code under a permissive license, you can’t revoke it. Ever.
Outsourcing Software in 2025: Why Vietnam Is Winning the Offshore Engineering Race
TL;DR – Outsourcing software to Vietnam delivers 30–50% cost savings, 95% developer retention, and 3-hour time zone overlap… ...
In 2026, with AI models training on open source code and companies aggressively monetizing community projects, understanding licensing isn’t optional. It’s survival.
Here’s what I’ve learned from maintaining repos with 10k+ stars, contributing to several Apache foundations projects, and working with developers in Ho Chi Minh City and Can Tho who build open source tools for global clients.
The Open Source PR Review That Almost Broke Us: How We Fixed It with a Vietnamese AI-Augmented Team
The Open Source PR Review That Almost Broke Us: How We Fixed It with a Vietnamese AI-Augmented Team… ...
Why Licensing Matters More Now Than Ever
Three years ago, most developers slapped an MIT license on their repo and moved on. Today, the landscape has shifted:
- AI training data lawsuits are making companies paranoid about code provenance.
- Large corporations now have strict policies: they won’t touch GPL code for internal tools.
- Monetization models like Open Core and source-available licenses are becoming mainstream.
So the question is: what license should you choose for your next open source project?
Honestly, it depends on your goal. Let’s break it down.
The Big Three: MIT, Apache 2.0, and GPLv3
| License | Permissive? | Patent Protection? | Copyleft? | Best For |
|---|---|---|---|---|
| MIT | Yes | No | No | Libraries, small tools, maximum adoption |
| Apache 2.0 | Yes | Yes | No | Projects used by corporations |
| GPLv3 | No | Yes | Strong | End-user applications, ethical software |
MIT – The Default Choice
MIT is the simplest. You give permission to anyone to do anything with your code, as long as they include the original copyright notice.
When to use it: You want the widest possible adoption. You don’t care if companies fork your work and never contribute back.
When to avoid it: You want to prevent patent litigation. MIT has no explicit patent grant. If a contributor holds a patent on something in your code, they could sue users later.
Apache 2.0 – The Corporate Favorite
Apache 2.0 is MIT plus an explicit patent grant. That means contributors grant a license to any patents they hold that cover the code.
Why it matters: In 2026, every Fortune 500 company runs a patent troll audit before adopting open source. Apache 2.0 passes that audit. MIT sometimes doesn’t.
At ECOAAI, we use Apache 2.0 for all our open source tooling. Our clients in the US and Europe demand it.
GPLv3 – The Freedom Fighter
GPLv3 forces anyone who distributes your code (even modified) to release their changes under the same license. It’s “copyleft.”
The trade-off: You’ll get fewer contributors. But your code stays free forever.
Real story: Last year, a startup in Vietnam built a CI/CD tool on top of a GPLv3 project. They tried to sell it as a proprietary SaaS. The original maintainer sent a cease-and-desist. The startup had to rewrite 40% of their codebase.
What About Lesser-Known Licenses?
BSD 2-Clause vs MIT
BSD 2-Clause is nearly identical to MIT. The difference? BSD explicitly prohibits using the project’s name to endorse derived products without permission. MIT is silent on that.
LGPLv3 – The Library Exception
LGPL lets you link to a library from proprietary code without forcing the rest of your app to be open source. But if you modify the library itself, those changes must be shared.
Use case: You build a UI component library. You want companies to use it in commercial apps, but you want improvements to the library itself to flow back.
SSPL – The Controversial One
The Server Side Public License (SSPL) was created by MongoDB. It says: if you offer the software as a service, you must open source your entire service code.
Cloud giants hate it. The Open Source Initiative (OSI) rejected it. But some projects still use it to prevent AWS from packaging and selling their work.
My take: SSPL is not open source by the official definition. Don’t use it if you want your project to be called “open source.”
How to Add a License to Your GitHub Repo
It’s trivial, but I see repos with no license every day. That’s dangerous. Without a license, the default copyright law applies: nobody can use, copy, or modify your code.
Here’s the right way:
- Create a file called `LICENSE` in the root of your repo.
- Paste the full license text. (GitHub provides templates when you create a new repo.)
- Add a header comment to your source files.
Example for Apache 2.0:
Copyright 2026 Your Name
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.Pro tip: Use a tool like `licensee` (GitHub’s own) to validate your license file. It checks for common formatting errors.
Common Licensing Mistakes Developers Make
1. Mixing Incompatible Licenses
You can’t combine GPLv3 code with MIT code in the same project and distribute it. The GPLv3’s copyleft infects the whole work.
How to avoid: Check every dependency’s license. Use `license-checker` (npm) or `cargo-license` (Rust) to generate a dependency license report.
2. Forgetting Contributor License Agreements (CLAs)
If you accept contributions from others, you need them to agree to license their contributions under your project’s license. Without a CLA, a contributor could later claim you used their code without permission.
We use CLA Assistant (a GitHub app) for all our repos. It’s free and automates the process.
3. Assuming “Open Source” Means “No Copyright”
It doesn’t. Open source licenses are copyright licenses. You still own the copyright. You’re just granting permission to others.
The Future of Open Source Licensing
Two trends to watch:
- Dual licensing: Offer the project under GPL (free) and a commercial license (paid) for companies that want to embed it in proprietary software. MySQL and Qt do this.
- Fair-code licenses: Like the BSL (Business Source License). Code is free for a limited time (e.g., 4 years) then converts to Apache 2.0. This allows projects to monetize their early growth.
In Vietnam, where we build software for international clients, dual licensing is gaining traction. It lets local dev shops contribute to open source while still making a living.
Final Advice
Pick the license that matches your goal, not the one everyone else uses.
- Want adoption? MIT.
- Want corporate adoption? Apache 2.0.
- Want to protect your code from being closed? GPLv3.
- Want to monetize later? Consider dual licensing.
And for the love of God, put a license file in your repo before you share it on Hacker News.
—
Frequently Asked Questions
Can I change the license of my open source project after publishing?
You can change the license for future versions, but you cannot revoke the license for existing copies. Anyone who already forked or downloaded your code under the old license can continue using it under those terms. This is why choosing upfront matters.
Do I need a license if I only publish code on GitHub without any explicit permission?
Yes. Without a license, the default copyright laws apply. Nobody can legally use, modify, or distribute your code. GitHub even shows a warning: “You’re under no obligation to choose a license, but doing so will help others use your project.”
What happens if a contributor doesn’t sign a CLA?
Their contribution is technically unlicensed. You cannot legally distribute their code. If you merge it anyway, you risk copyright infringement. Always require a CLA before merging, or at least ensure contributors agree to the project’s license in the PR description.
Is the MIT license safe for AI training data?
In 2026, this is a hot topic. MIT permits reuse, including for training AI models, as long as the copyright notice is included. However, some argue that training a model on MIT code doesn’t constitute “distribution” of the code itself. The legal landscape is still evolving. If you want to explicitly prohibit AI training, consider using a license like the “AI Training Opt-Out” variant, but be aware it’s not OSI-approved.
Related: Outsource to Vietnam — Learn more about how ECOA AI can help your team.
Related: Vietnam software outsourcing — Learn more about how ECOA AI can help your team.
Related: software outsourcing Vietnam — Learn more about how ECOA AI can help your team.
Related reading: Outsourcing Software Development: The Real Playbook for Tech Leaders in 2024
