Licensing for people who publish things
MIT, GPL, Apache — what the choice actually decides, and why shipping without a licence is a decision you already made badly.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer
The first time I published code, I skipped the licence file — it felt like paperwork for projects bigger than mine. That was already a decision: no licence means all rights reserved, which means nobody legally can use what I published for them.
What a licence actually decides
A licence is the answer to one question: what may strangers do with this? Run it, study it, modify it, redistribute it — and under what conditions. Everything else is detail.
The short field guide
- MIT — the handshake licence: do almost anything, keep the notice, no warranty. The default for small tools that want maximum adoption.
- Apache 2.0 — MIT plus explicit patent grant. For projects where patents could matter.
- GPL family — the viral licence: users get freedom, and derivatives must pass it on. A philosophical choice, not just a legal one.
- CC-BY — for content (like writing), not code.
How I choose
For tools I want spread widely: MIT. For anything where I want downstream work to stay open: GPL. The specific answer matters less than making one deliberately — a repo without a licence isn't neutral, it's closed, published by accident.
One more practical point: licence files belong in every repository, including small ones. Especially small ones. That's the version of you that will be grateful.
One email when a post lands
No schedule, no spam. Just the posts worth reading — new writing on software, AI, products, and the Pharmacy × Tech life.
Prefer a feed reader? Grab the RSS feed.
Keep reading
Open sourceYour first open source contribution doesn't need code
Docs, reproduction steps, and tested bug reports are contributions. The barrier you imagine is lower than the one that exists.
Open sourceReading the issue tracker: the skill nobody teaches
Issue trackers are where projects tell the truth. Learning to read them well reveals what to contribute and what to avoid.
Open sourceThe anatomy of a pull request that gets merged
Small scope, clean description, tests, and the maintainer's style. What separates merged PRs from the ones that die open.