Open-source licenses explained: best practices explained

Why licenses matter before you publish

You've built something useful. You're ready to push it to GitHub. Then someone from another team emails asking if they can use your code in their project. Without a license, the answer is legally complicated. Open-source licenses explained: best practices explained is not just about choosing a badge for your README—it's about defining what other developers can and cannot do with your work, protecting yourself legally, and ensuring your dependencies won't create compliance headaches down the line.

In our experience across teams shipping SaaS platforms, fintech systems, and trading applications, we've seen projects stall because of license conflicts, and we've watched teams accidentally violate copyleft terms by not checking their dependency tree. This guide covers the decisions you need to make before publishing, and the checks you need to run before using someone else's code.

Common licenses: permissive vs copyleft

Open-source licenses fall into two broad categories: permissive and copyleft. Understanding the difference shapes every licensing decision you'll make.

Permissive licenses

Permissive licenses let others use, modify, and redistribute your code with minimal restrictions. The trade-off is simplicity: others can take your work commercial without contributing back.

MIT License is the most permissive of all. It's a few lines long. Anyone can use your code for any purpose—commercial, private, whatever—modify it, distribute it, and sublicense it. Your only obligations: include a copy of the license and a copyright notice. No warranties, no liability on your side. It's popular for libraries, utilities, and frameworks because the low barrier to adoption means wider use.

Example use case: you wrote a utility for parsing webhook payloads from a payment provider. MIT means a SaaS competitor can bundle your code into their platform without ever talking to you.

Apache 2.0 is permissive but adds something crucial: an explicit patent grant. If you hold patents related to your code, Apache 2.0 grants users a royalty-free license to use those patents. It also requires that if someone modifies your code and distributes it, they must document what changed. This matters in industries where patent licensing is a real concern—fintech, healthcare, infrastructure.

Example: you build a cryptographic library. Apache 2.0's patent clause means users won't later be sued because you hold a patent they inadvertently infringed.

BSD licenses (2-Clause and 3-Clause variants) are also permissive. They're similar to MIT but with slightly different warranty language. Less common now than MIT or Apache, but still widely used in systems software.

Copyleft licenses

Copyleft licenses protect the freedom of the code itself. If you use copyleft code, any derivative work you create must also be open source under the same license. This "viral" property ensures the code stays free forever.

GPL (GNU General Public License) is the most famous copyleft license. GPLv2 and GPLv3 are the active versions. If you link to GPL code, your entire program must be GPLv3. If you distribute it, you must provide source code. This is powerful for community-driven projects—Linux, Git, GCC—but it creates hard constraints in commercial environments.

Example: you're building a trading platform. A core algorithm you'd like to use is GPLv3. Adopting it means your entire trading system must be open source too. Most firms won't accept that.

LGPL (Lesser GPL) softens this. You can link to LGPL libraries from proprietary code as long as you allow users to swap in a modified version of the LGPL library. It's common for foundational libraries where you want some freedom but don't want to force everything open.

AGPL (Affero GPL) extends GPL to network services. If you run an AGPL program on a server and users access it over the network, you must provide source code to those users. This matters for web applications and SaaS—using AGPL means your server code has to be open source too.

No license means no permission

This is the critical point many developers miss. If your repository has no license file, the code is copyrighted by default. Others cannot legally use it, even in permissive ways.

GitHub shows a warning icon on unlicensed repositories. The legal reality: every line of code is protected. You own it. No one else has permission to copy, modify, or distribute it without explicit consent.

We've seen teams assume that publishing on GitHub makes code public and therefore free to use. It doesn't. Public visibility is not the same as permission to use. A contractor once asked us if they could reuse a utility module from an internal repository we'd hosted. We checked the repo—no license. The answer was no, not without legal paperwork, even though the code was sitting on GitHub for months.

The fix is straightforward: add a LICENSE file to your repository before you push to GitHub. Choose a standard license from https://choosealicense.com, copy the text into a file named LICENSE (or LICENSE.md), commit, and push. That single file transforms your repo from "you can't touch this" to "you can use it under these terms."

curl https://opensource.org/licenses/MIT -o LICENSE
git add LICENSE
git commit -m "Add MIT license"
git push

Check dependencies for license compatibility

Licensing gets complex when you have dependencies. Every package in your package.json, go.mod, or pubspec.yaml has a license. If you publish your code under MIT but use three GPL libraries, you may have violated those licenses—or you may need to relicense your entire project as GPL.

Compatibility means: can you legally combine these licenses? Permissive + permissive usually works fine. Permissive + copyleft often forces you to adopt the copyleft license. Copyleft + copyleft requires they're the same version or compatible variants.

Scanning tools

Use automated tools to audit dependencies. For Node.js projects, npm ls shows the dependency tree with versions. Several tools check licenses specifically:

• license-checker (npm): scans node_modules and reports all licenses
• licensecheck (Go): similar for Go modules
• FOSSA (cloud service): comprehensive scanning across languages
• Black Duck (Synopsys): enterprise-grade license and vulnerability scanning

Example workflow for a Node.js project:

npm install -g license-checker
license-checker --json > licenses.json
# Review licenses.json for GPL, AGPL, SSPL, or conflicting terms

In a fintech backend we worked on, the license scan revealed that a utility library depended on an AGPL package buried three levels deep. We hadn't known. The scan caught it before we published. We either had to remove that dependency, seek a commercial license from the maintainer, or accept AGPL for the whole system. We chose to replace it with an MIT alternative.

Run this check every time you add a major dependency. Make it part of your CI/CD pipeline so violations surface automatically, not in a code review after everything is merged.

Ask legal for business use

Licenses have real obligations. They're not just academic. If your company is building commercial products, especially in regulated industries—fintech, healthcare, insurance—you need legal review before adopting copyleft or unusual licenses.

Common issues legal teams flag:

• GPL requires source disclosure. If your trading platform uses GPL code and you distribute it (even to a partner), you must provide source. Many firms can't accept that.
• AGPL affects SaaS. If your application runs on your servers and users access it over the network, AGPL forces you to publish your server code. This is a deal-breaker for most commercial SaaS.
• Patent indemnification varies. Apache 2.0 has explicit patent grants. MIT doesn't. If patents are a concern in your domain, the choice matters.
• Warranty disclaimers matter. Most open-source licenses disclaim warranties. Your company may want to add its own layer of liability coverage or indemnification if you're relying on third-party code.
• License compatibility chains. If you use library A (Apache 2.0) which depends on library B (GPL), you inherit GPL's obligations for the combination.

We've seen projects delayed by weeks because someone chose a license without checking with legal. In a SaaS CRM we shipped, the frontend used a component library under AGPL. Legal asked us to either relicense the entire application as AGPL or replace the component. We replaced it. The delay cost us a sprint, but the alternative was open-sourcing our entire product.

Get legal involved early. Most companies have standard acceptable licenses (often MIT, Apache 2.0, BSD) and a process for exceptions. Knowing your company's policy before choosing a license saves time later.

Common mistakes

Publishing without a license. Every day, repositories go public without a LICENSE file. The code is legally protected but unusable by others. Add a license before sharing.

Assuming permissive everywhere. Developers often adopt MIT for everything because it's simple. If you have patents, or if you want attribution, or if you want derived works to stay open, MIT might not be the right choice. Evaluate each project's needs.

Ignoring transitive dependencies. You checked the licenses of your direct dependencies but not their dependencies. A GPL package three levels deep still obligates you. Automate the scan so nothing slips through.

Mixing licenses without a plan. Using MIT code and GPL code in the same project without understanding the implications creates legal risk. Know the rules before combining.

Copying license text by hand. Use choosealicense.com or `curl` to get the official text. Typos or omissions in copied text can create ambiguity.

Not updating LICENSE when you relicense. If a project starts under MIT and later adds GPL dependencies, the old MIT license in the repository is no longer accurate. Update it to reflect the actual license obligations.

Key takeaways

• Every project needs a license before publication. No license means no permission for others to use your code, even if it's on GitHub.
• Permissive licenses (MIT, Apache 2.0, BSD) allow commercial use and modification with minimal obligations. Copyleft licenses (GPL, AGPL, LGPL) require derivative works to stay open source.
• Apache 2.0 adds an explicit patent grant, making it stronger than MIT for patent-sensitive domains like fintech and cryptography.
• AGPL forces disclosure of server code if your application runs as a service, making it unsuitable for most commercial SaaS without legal review.
• Always scan dependencies for license conflicts before publishing. Use license-checker, FOSSA, or equivalent tools, and integrate scanning into CI/CD.
• Involve your legal team before adopting copyleft or unusual licenses, especially in regulated industries or if your business model depends on keeping code proprietary.
• Choose one standard license per project. Mixing licenses across the same codebase creates ambiguity and legal risk.
• Compatibility matters: permissive + permissive works; permissive + copyleft often forces copyleft; GPL + AGPL creates additional constraints.