Understanding software licences
Permissive, copyleft, source-available — pick on purpose.
The MIT/BSD/Apache trio, GPL's copyleft, the rise of source-available licences, and the no-LICENSE-file default that means "all rights reserved".
No licence = all rights reserved.
Code without an explicit licence is copyrighted by default. Other people may read it on GitHub but cannot legally use, modify, or redistribute it. The widespread habit of treating any public repo as fair-use is wrong, even if rarely enforced. Adding a LICENSE file is what makes a project legally usable. Without one, you've published source code you've also forbidden anyone to run.
Permissive: MIT, BSD, Apache.
Permissive licences let anyone do almost anything with the code — use, modify, redistribute, sell — as long as the copyright notice and licence text travel along. MIT (1988) is the shortest, ~170 words. BSD 2-clause and 3-clause are similar; the 3-clause adds a no-endorsement clause. Apache 2.0 adds an explicit patent grant and requires a NOTICE file. Modern libraries default to MIT or Apache; Apache for anything that might have patent risk.
Copyleft: GPL and friends.
GPL (Gnu Public License) requires that any distributed derivative work also be released under GPL. The "viral" property — if you link to GPL code in a product you ship, your product becomes GPL — is the reason GPL fell out of fashion for libraries. LGPL is GPL with a linking exception, allowing closed-source software to link against LGPL libraries. AGPL extends GPL's reach to network-accessed software ("if your users use the modified code over a network, you must share source"). AGPL is what companies use when they want to be open-source but block hosted SaaS competitors.
Source-available: BSL, Elastic, SSPL.
A newer category. Source-available licences publish the code but restrict commercial use — typically forbidding hosted-as-a-service offerings. Examples: BSL (Business Source License, MariaDB), ELv2 (Elasticsearch), SSPL (MongoDB). These are not open-source by the OSI definition (which requires no field-of-use restrictions), but the source is available, and most non-cloud users can use them freely. They're how companies respond to AWS forking their projects.
A worked choice.
A new utility library, want maximum adoption: MIT. A new utility library with patent risk: Apache 2.0. A new server product, want to allow self-hosting but block AWS from packaging it as a managed service: AGPL or SSPL. A closed-source corporate project that publishes code for transparency but doesn't grant rights: source-visible (custom terms). A research artefact you want to be used and cited: MIT plus a citation requirement in the README.
Pick a licence
goal → licence
Match the licence to the strategic constraint.
library → MIT/Apache ; server → AGPL/SSPL
= Pick on purpose
Compatibility is real.
Mixing licences in one project is allowed only if they're compatible. MIT and Apache can be combined freely. GPL can absorb MIT (the combined work is GPL). Apache cannot be combined into GPLv2 (patent-clause incompatibility); it works with GPLv3. SSPL is incompatible with most copyleft licences. Before bringing in a dependency, check the licence matrix — a single GPL dependency in an MIT product silently relicences the combined work.