Choosing the Right Open Source License

Why Licensing Matters

You’ve built something useful. You want to share it with the world. You create a GitHub repository, push your code, and… wait. What license should you choose?

This decision might seem trivial, but it has profound implications. Your license determines:

• Who can use your code
• Whether they must share modifications
• If they can use it commercially
• Your liability and warranty obligations
• Whether others can patent derivatives

Choose wrong, and you might find your code used in ways you didn’t intend, or worse, not used at all because companies can’t legally touch it.

This guide helps you make an informed choice that aligns with your goals.

Understanding Open Source Licenses

Before choosing a license, understand what open source actually means.

What Makes a License “Open Source”

The Open Source Initiative (OSI) defines ten criteria for open source licenses:

1. Free Redistribution: No restrictions on selling or giving away the software
2. Source Code: Must be available
3. Derived Works: Modifications and derived works must be allowed
4. Integrity of Author’s Source Code: Can require modified versions to have different names
5. No Discrimination Against Persons or Groups: Can’t restrict specific people
6. No Discrimination Against Fields of Endeavor: Can’t restrict specific use cases
7. Distribution of License: Rights apply to all recipients
8. License Must Not Be Specific to a Product: Rights aren’t tied to a specific distribution
9. License Must Not Restrict Other Software: Can’t place restrictions on other software
10. License Must Be Technology-Neutral: Can’t require specific technology or interface

If a license meets these criteria, it’s OSI-approved open source.

License Categories

Open source licenses fall into two main categories:

Permissive Licenses

• Minimal restrictions on reuse
• Code can be used in proprietary software
• Few requirements for derivative works
• Maximum freedom for users

Examples: MIT, BSD, Apache 2.0

Copyleft Licenses

• Requires derivative works to use the same license
• Ensures modifications remain open source
• “Share-alike” requirement
• Preserves freedom across generations

Examples: GPL, AGPL, MPL

Public Domain

• No restrictions whatsoever
• Relinquish all rights
• Maximum freedom, no guarantees

Examples: Unlicense, CC0

Understanding these categories helps narrow your choice.

Defining Your Goals

Choose your license based on what you want to achieve.

Goal: Maximum Adoption

You want:

• Widespread use
• Easy integration into any project
• No barriers to commercial use
• Simple compliance

Choose: Permissive license (MIT, BSD, Apache 2.0)

Reasoning: Companies prefer permissive licenses because:

• Legal review is straightforward
• No viral obligations
• Can integrate into proprietary products
• Minimal compliance burden

Trade-off: Others can take your code, modify it, and never contribute back. Proprietary forks are possible.

Goal: Ensure Improvements Stay Open

You want:

• All improvements to remain open source
• Prevent proprietary forks
• Build a collaborative ecosystem
• Ensure reciprocity

Choose: Copyleft license (GPL, AGPL, MPL)

Reasoning:

• Forces derivative works to remain open
• Prevents “embrace and extend” strategies
• Creates a commons that grows over time
• Users who benefit must contribute back

Trade-off: Some companies won’t use copyleft-licensed code. Adoption may be slower. Integration with proprietary software is complex.

Goal: Balance Between the Two

You want:

• Reasonable adoption
• Some protection against proprietary forks
• File-level copyleft (not project-level)
• Pragmatic middle ground

Choose: Weak copyleft (MPL, LGPL)

Reasoning:

• Copyleft applies to modified files only
• Can be integrated into proprietary projects
• Offers some reciprocity
• More company-friendly than strong copyleft

Trade-off: More complex than permissive licenses. Less protection than strong copyleft.

Goal: Prevent Patent Issues

You want:

• Clear patent grant
• Protection against patent trolls
• Defensive termination clause
• Explicit patent peace

Choose: Apache 2.0 or GPLv3

Reasoning:

• Explicit patent grants
• Patent retaliation clauses
• Modern license design
• Addresses 21st-century concerns

Trade-off: Slightly more complex than MIT/BSD. May conflict with some GPL-licensed code (Apache-GPLv2 compatibility).

Goal: Prevent Tivoization

You want:

• Prevent hardware lockdown
• Ensure users can modify software on their devices
• Anti-DRM provisions
• Complete user freedom

Choose: GPLv3 or AGPLv3

Reasoning:

• Anti-tivoization clauses
• Ensures freedom to modify deployed software
• Addresses embedded systems concerns

Trade-off: Most restrictive option. Some companies explicitly ban GPLv3. Linux kernel famously stayed on GPLv2.

Goal: Cloud Service Protection

You want:

• Ensure SaaS providers share improvements
• Close the “ASP loophole”
• Apply copyleft to network services
• Prevent exploitation via cloud hosting

Choose: AGPL (GNU Affero General Public License)

Reasoning:

• Copyleft applies to network use
• SaaS providers must share source
• Prevents “internal use” loophole

Trade-off: Most restrictive license. Many companies ban AGPL entirely. Controversial in the ecosystem.

Popular Licenses Deep Dive

Let’s examine the most common licenses in detail.

MIT License

Overview: Short, simple, permissive license.

Key Terms:

Permission is hereby granted... to deal in the Software without
restriction, including without limitation the rights to use, copy,
modify, merge, publish, distribute, sublicense, and/or sell copies...

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY...

Allows:

• Commercial use
• Modification
• Distribution
• Private use
• Sublicensing

Requires:

• Copyright notice and license text in all copies

Forbids:

• Holding author liable

Best for:

• Libraries and tools
• Projects prioritizing adoption
• When you don’t care about proprietary forks

Used by:

• Node.js, React, Rails, jQuery

Apache License 2.0

Overview: Permissive license with explicit patent grant.

Key Terms:

• Grant of copyright license
• Grant of patent license
• Patent retaliation clause
• Trademark protection
• Explicit contributor agreements

Allows:

• Everything MIT allows
• Clear patent rights

Requires:

• Copyright notice
• Copy of license
• State changes made to files
• Notice file if provided

Forbids:

• Trademark use
• Patent litigation (terminates license)

Best for:

• Projects where patents matter
• Corporate-friendly open source
• When you want more protection than MIT

Used by:

• Kubernetes, TensorFlow, Android, Apache projects

GNU GPL v3

Overview: Strong copyleft license ensuring derivatives stay open.

Key Terms:

• Copyleft requirement
• Patent grant
• Anti-tivoization provisions
• Source code availability
• Compatible licenses listed

Allows:

• Commercial use
• Modification
• Distribution
• Patent use

Requires:

• Source code disclosure
• License and copyright notice
• State changes
• Derivative works use GPLv3
• Install information (anti-tivoization)

Forbids:

• Proprietary derivatives
• Sublicensing
• Patent litigation

Best for:

• Preventing proprietary forks
• Building copyleft ecosystems
• Ensuring reciprocity

Used by:

• WordPress, Git, GIMP, Bash

GNU AGPL v3

Overview: GPL with network use provision.

Key Terms:

• Everything in GPLv3
• Network use = distribution
• Must provide source to network users

Allows:

• Same as GPLv3

Requires:

• Same as GPLv3
• Provide source to users interacting over network

Forbids:

• Same as GPLv3
• Using in SaaS without sharing source

Best for:

• Web applications
• SaaS platforms
• Preventing cloud provider exploitation

Used by:

• MongoDB (until license change), Grafana, Mastodon

BSD Licenses (2-Clause and 3-Clause)

Overview: Very permissive, similar to MIT.

Key Differences:

BSD 2-Clause (Simplified BSD)

• Essentially identical to MIT
• Different wording

BSD 3-Clause (New BSD)

• Adds non-endorsement clause
• Can’t use author’s name for promotion

Best for:

• Academic projects
• Maximum freedom
• When you prefer BSD wording over MIT

Used by:

• FreeBSD, Redis, Nginx

Mozilla Public License 2.0

Overview: File-level copyleft license.

Key Terms:

• Copyleft per file, not per project
• Can mix with proprietary code
• Patent grant included
• Compatible with GPL

Allows:

• Commercial use
• Modification
• Distribution
• Mixing with proprietary code (file-level)

Requires:

• Source disclosure for MPL files
• License and copyright notice
• Document changes

Best for:

• Libraries used in larger projects
• Balance between permissive and copyleft
• When you want some reciprocity without scaring companies

Used by:

• Firefox, Thunderbird, LibreOffice

Special Cases and Considerations

Dual Licensing

Offer the same code under multiple licenses.

Common Patterns:

GPL + Commercial

This project is available under:
- GNU GPLv3 for open source use
- Commercial license for proprietary use

Contact sales@company.com for commercial licensing.

Used by: MySQL, Qt, MongoDB (historically)

Benefits:

• Open source community benefits
• Revenue from commercial users
• Sustainable funding model

Challenges:

• Requires copyright ownership
• Complex legally
• Must track contributions carefully

Contributor License Agreements (CLAs)

Legal agreements signed by contributors.

Purpose:

• Grant project rights to contributions
• Enable license changes
• Protect against legal issues
• Clarify patent grants

Types:

Copyright Assignment

• Contributor transfers copyright
• Project has full ownership
• Enables maximum flexibility
• Controversial

Copyright License

• Contributor keeps copyright
• Grants broad license to project
• More contributor-friendly
• Still enables relicensing

Example Projects:

• Apache: Apache CLA
• Google: Google CLA
• FSF: Copyright assignment

Controversy: Some developers refuse to sign CLAs, seeing them as power imbalance.

License Compatibility

Not all licenses work together.

Compatibility Rules:

Permissive + Permissive ✅ Always compatible

Permissive + Copyleft ✅ Compatible (result is copyleft)

GPLv2 + GPLv3 ❌ Incompatible (unless “GPLv2 or later”)

Apache 2.0 + GPLv2 ❌ Incompatible

Apache 2.0 + GPLv3 ✅ Compatible

GPL + Proprietary ❌ Incompatible

MPL + Anything ✅ Generally compatible (file-level)

When Using Others’ Code

Check dependency licenses:

# For Node.js projects
npx license-checker

# For Python projects
pip-licenses

# For Go projects
go-licenses report ./...

Rules of Thumb:

• Using GPL code? Your project must be GPL
• Using AGPL code? Your project must be AGPL
• Using permissive code? Any license works
• Mixing licenses? Check compatibility carefully

The Decision Framework

Use this framework to choose your license.

Step 1: Answer Key Questions

[ ] Who is your primary audience?
    - Individual developers → Permissive
    - Companies → Permissive or weak copyleft
    - Open source community → Copyleft

[ ] What's more important?
    - Maximum adoption → Permissive
    - Ensuring openness → Copyleft

[ ] Are patents a concern?
    - Yes → Apache 2.0 or GPLv3
    - No → MIT or GPLv2

[ ] Is this a library or application?
    - Library → Permissive or LGPL
    - Application → Any license

[ ] Will this be used in SaaS?
    - Yes, and you want reciprocity → AGPL
    - Yes, but don't care → Any license

[ ] Do you want to dual-license later?
    - Yes → GPL + require CLA
    - No → Any license

Step 2: Narrow Down Options

Based on answers:

Maximum adoption, patents matter → Apache 2.0

Maximum adoption, patents don’t matter → MIT

Prevent proprietary forks, application → GPLv3

Prevent proprietary forks, library → LGPLv3

Prevent SaaS exploitation → AGPLv3

Middle ground, library → MPL 2.0

Give away everything → Unlicense or CC0

Step 3: Validate Your Choice

Check that your choice aligns with:

• Your personal values
• Your project goals
• Your community expectations
• Dependency licenses
• Corporate policies (if applicable)

Step 4: Apply the License

Add LICENSE file:

# Use GitHub's license picker or
# Visit choosealicense.com

# Copy full license text to LICENSE file

Add license headers:

/**
 * Copyright (c) 2025 Your Name
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

Update package metadata:

{
  "name": "my-package",
  "license": "MIT",
  "author": "Your Name"
}

Add badge to README:

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

Common Mistakes to Avoid

Mistake 1: No License

Problem: Without a license, code is proprietary by default. Others can’t legally use it.

Solution: Always include a LICENSE file. Even MIT is better than nothing.

Mistake 2: “Do Whatever You Want”

Problem: Not a legal license. Ambiguous and unenforceable.

Solution: Use Unlicense or CC0 if you truly don’t care.

Mistake 3: Custom Licenses

Problem: Untested legally. Companies won’t touch them. Unclear implications.

Solution: Use standard, OSI-approved licenses. They’re standard for a reason.

Mistake 4: Mixing Incompatible Licenses

Problem: Including GPLv2 and Apache 2.0 code in the same project.

Solution: Check compatibility before using dependencies. Use tools to audit licenses.

Mistake 5: Changing Licenses Casually

Problem: Changing licenses requires consent from all copyright holders.

Solution: Choose carefully initially. If you must change, use CLA or “or later” clause.

Mistake 6: Not Understanding Copyleft

Problem: Choosing GPL without realizing it affects dependent projects.

Solution: Read and understand your license choice fully.

Special Topics

Relicensing

Changing your project’s license is difficult.

Requirements:

• Consent from all copyright holders, or
• CLA that grants relicensing rights, or
• Copyright assignment, or
• Rewrite all code from non-consenting contributors

Process:

1. Decide on new license
2. Contact all contributors
3. Get explicit written consent
4. Document approvals
5. Make the change
6. Announce clearly

License Notices in Compiled Code

Some licenses require notices in binaries:

Apache 2.0: Must include NOTICE file contents in distributions

GPL: Must make source available to users

MIT/BSD: Generally just need LICENSE file in distributions

Check your license’s specific requirements.

International Considerations

Different countries have different copyright laws:

• Some countries don’t recognize public domain
• Patent provisions vary by jurisdiction
• “As-is” disclaimers may not be enforceable everywhere

Standard OSI licenses are internationally tested.

Resources for Further Learning

License Selection Tools

choosealicense.com

• GitHub’s license selector
• Simple, clear recommendations
• Covers most common cases

tldrlegal.com

• Plain English license summaries
• Compare licenses side-by-side
• “Can/Cannot/Must” format

SPDX License List

• Complete list of standardized licenses
• Official identifiers
• Legal text

Compliance Tools

FOSSA

• Automated license compliance
• Dependency scanning
• Company-focused

Black Duck

• Enterprise compliance solution
• Detailed analysis

License Checker (npm)

• Node.js license auditing
• CLI tool

Legal Resources

Software Freedom Law Center

• Pro bono legal help for FOSS
• License consulting

Open Source Initiative

• License approval authority
• Educational resources

FSF Licensing Team

• GPL compliance help
• Copyleft expertise

Important: This guide is educational, not legal advice. Consult a lawyer for specific legal questions.

Your Licensing Checklist

Before Publishing:

• Identify your goals and values
• Choose appropriate license using decision framework
• Verify compatibility with dependencies
• Add LICENSE file with complete text
• Add license headers to source files
• Update package metadata
• Add license badge to README
• Document license choice in README

After Publishing:

• Monitor dependency license changes
• Respond to license questions promptly
• Enforce license violations if needed
• Update license in new files
• Educate contributors about license

Conclusion

Choosing the right open source license is one of the most important decisions for your project. It shapes how others can use your work, influences adoption, and reflects your values.

There’s no universally “best” license. The right choice depends on:

• Your goals for the project
• Your stance on proprietary derivatives
• Your target audience
• Patent and legal considerations
• Your personal values

Most projects should use one of the popular, well-tested licenses:

• MIT or Apache 2.0 for maximum adoption
• GPLv3 for preventing proprietary forks
• AGPLv3 for SaaS reciprocity
• MPL 2.0 for middle ground

Choose deliberately, apply correctly, and move forward with confidence. Your open source contribution, properly licensed, can change the world.

Now go forth and license wisely.