Reading a License Without a Lawyer

01Permissive Licenses: Borrow Freely, Credit Lightly

Most software you pull from a package manager or copy from a README carries one of a handful of licenses. They look like legal boilerplate, but the practical differences are narrow enough to hold in your head without a law degree.

GPL, MIT, Apache, copyleft vs permissive.

The MIT License is the shortest of the common ones — a few sentences. It says: do whatever you like with this code, but keep the copyright notice attached and don't hold the author liable if it breaks something. That's almost the entirety of it. You can bundle MIT-licensed code into a proprietary product, sell that product, modify the source without publishing your changes, and nobody can stop you. The only obligation is attribution: somewhere, the original copyright line stays visible.

The Apache License 2.0 is longer but adds one meaningful extra: patent rights. If a contributor holds a patent on something in the code, Apache 2.0 grants you a license to use it and explicitly says that license is revoked if you sue contributors over patents. For organisations building products on top of open-source libraries, this clause matters more than anything else in the document. Otherwise, Apache 2.0 behaves much like MIT — permissive, attribution-required, no requirement to share changes.

The BSD family (two-clause, three-clause, Zero-Clause) lives in the same neighbourhood as MIT, with minor wording differences. Zero-Clause BSD comes closest to public domain — it doesn't even require attribution. Many Linux distributions release some of their own tools under BSD and MIT-style licenses; Canonical and Red Hat both use permissive licenses for large portions of their tooling.

02Copyleft Licenses: Share-Alike, or Else

Copyleft licenses flip the logic. Instead of "do what you like," they say "if you distribute changes, release them under the same license." The freedom is guaranteed to all downstream users, not just the first recipient.

The GNU General Public License (GPL) is the canonical example. The GPL v2 — still carried by the Linux kernel — requires that any distributed binary built from GPL source must come with that source, or an offer to provide it. The GPL v3 adds protections against tivoisation (embedding GPL software in hardware that won't run modified versions) and strengthens the patent clause. The practical upshot for developers: if your code links against a GPL library and you ship it to users, you must release your source. Many companies avoid GPL code for precisely this reason; others build entirely around it.

The GNU Lesser GPL (LGPL) is a softer variant. It allows proprietary software to link against an LGPL library dynamically without triggering the share-alike requirement — only modifications to the library itself must be released. Distributions such as Debian go further and sort their repositories by licensing terms, so users can see which packages meet their definition of free software.

The GNU Affero GPL (AGPL) closes what's sometimes called the "SaaS loophole." Under the GPL, running software on a server and offering it as a service isn't "distributing" it — so source release isn't triggered. The AGPL says that if users interact with the software over a network, that counts as distribution. A growing number of infrastructure tools ship AGPL for exactly this reason.

03The One-Line Guide

For most personal use, the license barely matters — you're not distributing anything. When you are shipping software, one question decides which family applies: are you sharing the compiled result with someone outside your organisation? If yes, check for GPL. If the dependency chain is MIT or Apache all the way down, you're free. If a GPL library is in there, your source goes with the binary. Everything else is commentary.