Whether an extension had to be GPL was the fight

The question that predated the project

When the Joomla development team left Mambo in August 2005 and registered Open Source Matters to hold the new project's assets, they inherited a codebase licensed under the GNU General Public License. The GPL was not a technicality. It was the founding condition: anyone who distributed software that was a derivative work of GPL code had to distribute that derivative under the same terms. The question of whether a Joomla extension — a component, a module, a plugin — constituted a derivative work of Joomla's core was therefore not a philosophical argument. It was a legal and commercial one, and the project's answer to it determined what the entire extension economy could look like.

The answer was not obvious to everyone who was building things. In the PHP ecosystem of the mid-2000s, it was common to treat a web application as a platform and a plugin as a product, owned and licensed separately. WordPress and Drupal were having versions of the same argument. A developer who invested months in a component naturally wanted to control how it was distributed, and "must release under GPL" felt, to many of them, like the project expropriating private work. That framing was wrong in the project's reading of the law, but it was widespread in forums, and it did real commercial damage to the argument for a moment.

What the GPL actually requires and why extensions probably trigger it

The GNU General Public License ↗ defines derivative work by the standard of linking and program combination, not by the more colloquial sense of copying. A PHP extension that uses Joomla's APIs, is loaded by Joomla's application object, runs inside Joomla's process space, and cannot function without the core is, by the GPL's logic and by the interpretation of organisations such as the Free Software Foundation, a derivative work. The extension does not copy Joomla's code. It does not have to. It is combined with it at runtime, which is the relevant test.

The nuance that generated years of argument was whether a clean-room extension that made no use of Joomla's libraries — using, say, only standard PHP functions — could be considered independent. Legally this was at least arguable. Practically, it was nearly impossible: Joomla's framework is the mechanism through which any extension reaches the database, the user session, the template layer, the installer, the access control list. You could write a PHP class that did arithmetic, but you could not write a Joomla extension without touching Joomla.

Brian Teeman, one of the project's most visible communicators, spent years explaining this publicly — at conferences, in documentation, in forum threads — because the argument kept recurring in the same forms. The position was not asserted by Joomla as a matter of preference; it reflected the FSF's own analysis of how the GPL propagates through combined works in a dynamic language runtime. That distinction mattered: the project was not making a claim about what it wanted; it was reporting what the licence said.

The Software Freedom Law Center opinion

The most significant step in settling the argument publicly was the decision to ask outside counsel. The Software Freedom Law Center, founded by Eben Moglen and functioning as the legal arm of the free software movement, was approached to give a formal opinion on whether Joomla extensions were derivative works under the GPL. The SFLC's conclusion supported the project's position: extensions that link to and operate through Joomla's core are derivative works and must be distributed under GPL-compatible terms.

The SFLC's involvement mattered for two reasons. First, it removed the question from the category of "what the project claims" and placed it in the category of "what qualified legal analysis says." Second, it was published. The opinion was not kept internal. Making it part of the public record meant that any developer, any commercial vendor, any lawyer advising an extension business could read the reasoning and assess it. Governance-by-publication is a recurring pattern in the Joomla record, and this instance of it was unusually consequential.

Andrew Eddie, one of the founding developers who had been part of the original walkout from Mambo and who had deep involvement in the framework's architecture, understood better than most why the GPL propagation argument was technically well-grounded. The extension loading mechanism he and Louis Landry built into the Joomla 1.5 framework — the application object, the component dispatcher, the plugin event system — was not a loose interface. It was close integration. The architecture itself answered the derivative-work question in practice, whatever one argued in theory.

The answer was not obvious to everyone who was building things.

What the directory policy encoded

The argument could have remained theoretical. What made it consequential in practice was the Joomla Extensions Directory ↗, the project's official catalogue of third-party software. Directory listing rules became the enforcement mechanism. An extension submitted to the JED had to comply with the GPL. Extensions distributed under proprietary licences, or using encoding tools such as ionCube to ship PHP in obfuscated form, did not qualify for listing in the GPL-compliant section of the directory. The directory was the principal channel through which most users found extensions, which made exclusion from it commercially significant.

The encoding question deserves a moment: ionCube and Zend Guard encoding allowed a vendor to ship a PHP extension in a form that ran on a server but could not be read. This was used to protect commercial code from copying, and it was widespread. The JED's position was that encoded code could not be verified to be GPL-compliant — you could not read it to confirm the licence terms were met — and extensions distributed this way were categorised separately. The commercial market for encoded extensions existed and was not negligible, but it sat outside the directory's primary listing tier and aged badly as the argument for GPL compliance became more settled.

What settled and what did not

By the time Joomla 1.5 was released in 2008, the project's position on the GPL and extensions was formalised, documented, supported by outside legal opinion, and enforced through directory policy. That did not end all argument. Developers continued to debate dual-licensing arrangements — distributing under GPL while selling a separate commercial support agreement or a licence for a closed companion product. Dual licensing was not prohibited and became the dominant commercial model: release the extension source under GPL, sell the installation support, documentation, priority support contract, or a closed add-on that extended functionality.

The architecture itself answered the derivative-work question in practice, whatever one argued in theory.

This model, which WordPress's own GPL enforcement later echoed ↗, turned out to be a viable commercial structure. It required accepting that code, once distributed, could be shared. It meant commercial differentiation moved to service, documentation, and ongoing development rather than code secrecy. Companies that built around this model — selling access, support, and bundled service contracts — generally fared better in the long run than those that bet on obfuscation. The companies that bet on obfuscation mostly disappeared when the hosting environment moved on.

The argument was not clean. It ran for years, it recurred whenever a new commercial vendor arrived with a new theory, and it was never fully resolved in the sense of ending all disagreement. What it produced was a settled project position, a documented legal rationale, a directory policy that operationalised that position, and an extension economy that mostly accepted the terms. That combination — position, rationale, mechanism, market adaptation — is what governance through a licence actually looks like in practice.