Skip to content

An Introduction to Software Licensing

Public repo without a license? That's not open source—that's All Rights Reserved.

Developers push code to public repos and assume that makes it open source. It doesn’t.

Without a LICENSE file, your code defaults to All Rights Reserved. That public repo everyone can see? Legally, nobody can use it. Intent doesn’t matter—the file does.

The “No License” Trap

This is the most common mistake in the developer community. You write something useful, push it to GitHub, and assume others can use it. They can’t. Copyright law doesn’t care about your intentions; it cares about explicit grants of permission.

If you want peers to use your code, you must explicitly grant them the right via a license file.

Permissive vs. Copyleft

Two philosophies, both valid:

Permissive (Apache, MIT, BSD): Freedom for the user. Samsung takes Android, adds proprietary layers, ships it closed. That’s the design. Apache enables corporate adoption at scale.

Copyleft (GPL): Freedom for the code. Derivatives must stay open. The Linux kernel model—if you ship it, you share source. Community compounds.

Android uses both. Apache for userspace flexibility, GPL for kernel integrity. Different tools for different layers.

CLAs and Dual Licensing

Contributor License Agreements let maintainers re-license without chasing down every contributor. That’s why Android, Canonical, and CyanogenMod require them.

Projects like LibreOffice dual-license to give developers options—choose the license that fits your use case.

The mechanics matter less than the principle: pick a license that matches your intent, or the law picks one for you.

Resources

Resources

Save or share this session with your team.

Available for teams and events

Formats
30 min · 45 min + Q&A
Audience
Engineering teams, Open source maintainers
Requirements
Projector.
Get in touch

Previously presented at Meetup talk (GDG Toronto Android) (Aug 2017).