A license can pass every test on the definition and still be unable to share a program with another license that also passes every test. Compatibility is not a measure of openness; it is a separate question about whether two sets of conditions can be satisfied by the same copy of code at the same time. The binder keeps this sheet because the confusion between the two questions causes more real-world trouble than any single clause.

Open source and compatible are not synonyms, and a project that discovers the gap late usually discovers it the hard way, mid-release.

What does combining two licenses actually mean?

Combining means taking code covered by one license and linking, copying, or merging it into a program also covered by another, then distributing the result as one work. The question compatibility asks is narrow: can the resulting distribution satisfy both sets of conditions at once, or does satisfying one necessarily break the other. Two short, permissive licenses almost always combine cleanly, because neither imposes a condition the other forbids. The trouble starts when one license tries to extend its terms to the whole combined work and the other license refuses to be extended.

Why was the Apache License 2.0 once incompatible with the GPL?

The Apache License 2.0, published in 2004, added an explicit patent grant and a patent retaliation clause: anyone who files a patent suit claiming the code infringes loses the patent license the text had granted them. The Free Software Foundation's own license list records that this requirement was not present in the GNU General Public License version 2, and the older GPL text does not let a redistributor attach conditions the GPL itself does not state. The two licenses were each considered free software on their own terms, and still could not be merged into one distributed work, because satisfying Apache's patent clause meant imposing a term GPLv2 had no mechanism to carry.

How did GPLv3 fix it?

The Free Software Foundation wrote the General Public License version 3, released in 2007, with cross-compatibility as an explicit goal, and its own license list states plainly that GPLv3 is compatible with the Apache License 2.0. The fix was not a reinterpretation of Apache's clause; it was a rewritten GPL text built to accommodate patent-retaliation language from other free licenses without treating it as a forbidden extra restriction. A project stuck with Apache-licensed dependencies under GPLv2 had one practical remedy available afterward, and only if its GPL code had been released under "version 2 or any later version": distribute the combined work under GPLv3.

What about the Mozilla Public License?

The Mozilla Public License tells the same story from a different angle. Version 1.1, published in 1999 and in use until 2012, applied its copyleft at the level of the individual file and offered no bridge to the GPL family, so a project under MPL 1.1 could not simply fold GPL code into the same file and distribute it. Version 2.0, published in 2012, added a mechanism the license text calls Secondary Licenses: the GPL 2.0, the LGPL 2.1, the AGPL 3.0, or any later version of them. MPL 2.0 code combined with code under one of those licenses may also be distributed under its terms, so the two copyleft families can finally share one distribution, unless the author has attached the notice that marks the file "Incompatible With Secondary Licenses". Before that rewrite, the incompatibility was not a bug anyone could patch from outside; it had to be fixed in the license text itself, the same way Apache and GPLv2 were.

Why the binder files this apart from the definition

None of this touches whether a license counts as open source. Apache 2.0, GPLv2, GPLv3, and both versions of the MPL all pass the ten-point test the binder keeps on file elsewhere. Compatibility is a second, independent axis: not whether a license is open, but whether its conditions can be satisfied simultaneously with another open license's conditions inside one piece of distributed software. A maintainer who checks only the first axis and skips the second can build a project that is legally unshippable the moment two of its dependencies disagree.

What a maintainer actually has to check

In practice this means reading the compatibility notes the license's own stewards publish, not just the license text in isolation, because compatibility is usually decided by one side rewriting itself to accommodate the other rather than by a court settling the question. The Free Software Foundation keeps a running list of which licenses it considers GPL-compatible and why; it is the closest thing the shelf has to an authoritative compatibility map, and it is also, by its own admission, a moving document that changes every time a license is revised.

What the text grants

Nothing by itself; compatibility is a relationship between two license texts, decided clause by clause, not a property either one has alone.

What a reader should check

Whether the licenses involved have a published compatibility statement, and whether either text has been revised since that statement was written.

The limit of this reading

Compatibility findings come from the license stewards themselves, not from courts; two parties can still read the same pair of texts differently.