‘Open source’ is not a label you can stick on at will: it is verifiable conformance to a document, the Open Source Definition (OSD), maintained by the Open Source Initiative (OSI). A licence is open source if and only if it meets the ten OSD criteria, and the OSI keeps the certified list. For anyone shipping code one thing matters: the terms you pick bind everyone who later receives the software, for good, and from one approved licence to the next the legal obligations are reversed.

The OSD and the OSI’s role

The OSI was founded in February 1998 by Eric Raymond and Bruce Perens. The OSD was not written from scratch: it derives from the Debian Free Software Guidelines (DFSG), which Perens had drafted in 1997 for Debian, with the Debian-specific references stripped out. It is a criteria document, not a licence: it says what a licence must grant, not how to draft one.

The ten criteria require, among other things, free redistribution with no royalty, availability of the source code, permission to make derived works and redistribute them under the same licence, no discrimination against persons or groups, and no restriction on the field of endeavour — criterion 6: the software may not forbid use in, say, commercial settings or genetic research. The tenth criterion, added in 2002, asks the licence to be technology-neutral: it may not presume a particular mode of distribution, for instance by demanding a click-through.

What the OSD does not guarantee weighs as much as the rest. It does not oblige derived code to stay open. A licence that lets you take the source, modify it and redistribute it as a closed product is perfectly OSD-conformant. The OSD sets a floor of freedoms granted to whoever receives the software; how much to impose above that floor is the author’s call.

The three families

OSI-certified licences sit along an axis that comes from one question: what happens to the source of a derived work distributed to third parties? The answers fall into three families.

Strong copyleft. The reference case is the GNU General Public License (GPL), written by Richard Stallman, in version 2 of June 1991. Its operative clause (section 2b) requires that any work ‘based on the Program’ distributed to others go out, as a whole, under the GPL. The mechanism is recursive: the freedom propagates along every link in the chain of derivation. The most argued-over practical consequence concerns linking: combining proprietary code with a GPL library produces, in the Free Software Foundation’s reading, a derived work, hence bound to the GPL. On that reading, firms wishing to keep their own code closed avoid linking GPL libraries.

Weak copyleft. The GNU Lesser General Public License (LGPL), version 2.1 of February 1999, exists precisely for that problem. It keeps copyleft on the library’s code — modify it and you must release the changes under the LGPL — but explicitly allows a proprietary program to link the library without becoming LGPL itself. The obligation stops at the library boundary. The Mozilla Public License (MPL) 1.1, of 1999, applies the same principle at single-file granularity: files born as MPL stay MPL even when combined with proprietary code, but the combined whole is not bound.

Permissive. The BSD and MIT licences ask for the minimum the OSD allows: keep the copyright notice and the licence text. No obligation on derived code, which may be closed. The old ‘four-clause’ BSD carried an advertising clause, that is, a requirement to credit the author in all promotional material; Berkeley retired it in 1999 at the Free Software Foundation’s request, and out came the ‘three-clause’ BSD now recommended. Apache’s current licence, the Apache License 1.1 (2000), is a three-clause BSD with the names changed plus a clause on use of the ‘Apache’ mark.

Compatibility

The least intuitive consequence is that two licences both certified by the OSI can be incompatible with each other: code under one cannot be combined and distributed under the other. The GPL is the strictest case. Its section 6 forbids adding restrictions beyond the GPL’s own, so code under a licence that imposes any extra obligation — however small — cannot be merged with GPL code into a single distributed work.

The old four-clause BSD’s advertising clause is the textbook case: by requiring a credit in promotional material it added a restriction the GPL does not allow, and made the two bodies of code incompatible. It is one of the technical reasons Berkeley removed it. The Apache License 1.1, although it dropped that advertising clause already present in Apache 1.0, remains in the Free Software Foundation’s view incompatible with GPLv2: it adds attribution and naming terms the GPL does not allow.

Compatibility is therefore a property of a pair, not of a single licence, and it only comes into play when code of different provenance is combined into one distributed work. For a single-licence program the problem does not arise; it surfaces the moment you link third-party libraries.

What changes for whoever ships code

Choosing a licence is a technical decision with irreversible effects on already-published code: future versions can be relicensed, but every copy already shipped stays under the terms it went out with. Three operational consequences:

  • A library meant to be adopted by proprietary software too cannot sit under the GPL; that leaves LGPL, MPL or a permissive licence.
  • To combine third-party code you check compatibility pairwise, not that each individual licence is ‘open source’. Two approved licences are not enough to guarantee a distributable result.
  • A permissive licence maximises adoption, but does not guarantee that derivatives stay open; a copyleft licence guarantees open derivatives, but restricts who can integrate the code.

Limits

The OSD certifies licences; it does not decide the edge cases. The dynamic-linking-versus-GPL question has, to date, no ruling that settles it: the Free Software Foundation’s reading is authoritative, but it is not established case law. Likewise, the ‘open source’ qualification is about the licence terms, not the actual availability of a repository, a community or contribution processes: a project can hold an OSI licence and code nobody maintains. The OSD answers one single question — which freedoms the licence grants — and should be read knowing that is the one.

https://opensource.org/docs/definition.php https://www.gnu.org/licenses/gpl.html https://www.gnu.org/licenses/lgpl.html https://www.gnu.org/licenses/license-list.html https://www.apache.org/licenses/LICENSE-1.1 https://www.mozilla.org/MPL/MPL-1.1.html https://www.debian.org/social_contract#guidelines https://www.noze.it/en/insights/licenze-oss-osi/

Cover image: Open Source Initiative logo: a stylized green keyhole with a dark green outline, merging the letter O with the shape of a keyhole — logo by Colin Viebrock, CC BY 2.5 — https://commons.wikimedia.org/wiki/File:Open_Source_Initiative_keyhole.svg