Chapter 5: Licensing and Legal Foundations
Licensing is what makes a project legally open source.
Without a license, a public repository is not open source, even if the code is visible.
This chapter explains how licensing works, why it matters, and how to choose a license that aligns with your goals.
Why Licensing Exists
A license defines:
- how others can use your code
- what they are allowed to modify
- how they can redistribute it
- what obligations they have
By default, copyright law applies.
This means that without a license, no one is allowed to legally use, copy, or modify your code.
A license is not a restriction — it is a permission.
Licenses as Trust Infrastructure
Licenses create trust between:
- authors
- contributors
- users
- organizations
They reduce ambiguity and legal risk, making collaboration possible at scale.
Clear licensing encourages adoption.
Open Source Licenses vs Source-Available
Not all public code is open source.
Open source licenses:
- grant usage, modification, and redistribution rights
- comply with Open Source Initiative (OSI) definitions
Source-available licenses:
- allow code viewing
- restrict usage, modification, or redistribution
Being explicit avoids confusion.
The Role of the Open Source Initiative
The Open Source Initiative (OSI):
- defines what qualifies as open source
- maintains an approved license list
- promotes open source standards
Using an OSI-approved license ensures compatibility and clarity.
Common License Families
Open source licenses generally fall into two broad categories.
Permissive Licenses
Permissive licenses allow broad usage with minimal restrictions.
They generally:
- allow commercial use
- allow modification
- allow redistribution
- require attribution
MIT License
- Simple and permissive
- Minimal requirements
- Widely used
Commonly chosen for:
- personal projects
- startups
- libraries
- tooling
Apache License 2.0
- Similar to MIT
- Includes explicit patent protection
- More detailed terms
Often used by:
- companies
- large-scale projects
- enterprise tooling
Copyleft Licenses
Copyleft licenses require derived works to remain open source.
They:
- enforce openness downstream
- prevent proprietary forks
- prioritize community continuity
GPL (General Public License)
- Strong copyleft
- Derivatives must use the same license
- Commercial use is allowed, but openness is enforced
Common in:
- community-driven projects
- ideological open source
- long-lived infrastructure
Weak Copyleft Licenses
Some licenses apply copyleft more selectively.
Examples include:
- LGPL
- MPL
These allow linking or partial use without enforcing full openness.
Choosing a License Intentionally
License choice should be intentional, not accidental.
Consider:
- Do you want maximum adoption?
- Do you want derivatives to stay open?
- Do you care about patent protection?
- Will companies use this project?
Different goals lead to different licenses.
A Practical Decision Framework
If your goal is:
- simplicity and adoption → permissive license
- protecting openness → copyleft license
- corporate compatibility → Apache-style license
There is no universally “best” license.
License Compatibility
Not all licenses are compatible with each other.
When combining dependencies:
- check their licenses
- ensure compatibility
- avoid conflicting terms
Ignoring compatibility can create legal issues.
Where to Declare a License
Licensing should be explicit and visible.
Best practices:
- add a
LICENSEfile at the root - mention the license in the README
- ensure consistency across documentation
Clarity matters more than verbosity.
Changing a License Later
Changing a license is possible, but complex.
It often requires:
- agreement from all contributors
- clear ownership history
- careful communication
Choosing wisely early avoids future friction.
Licensing and Contributors
Contributors implicitly agree to your license when they contribute.
Some projects:
- require Contributor License Agreements (CLAs)
- use Developer Certificate of Origin (DCO)
These add clarity but also friction.
They should be introduced deliberately.
Legal Confidence Without Legal Complexity
You do not need to be a lawyer to open source a project.
You do need to:
- choose a standard license
- apply it consistently
- be transparent about expectations
Standard licenses exist to simplify this process.
Reflection
Think about:
- how you want others to use your work
- how much control you want to retain
- how you feel about commercial usage
Licensing reflects values as much as legal terms.
You've Completed Chapter 5
Well done! You've learned about licensing and legal foundations.