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.

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 LICENSE file 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.