Skip to main content

ADR-0003: EUPL-1.2 with Plugin Exception

Accepted

Context​

Ideal needs a single, consistent license for all its source code components. The license must:

  • Protect the openness of the core: modifications to the toolkit, shell, and libraries must remain open source.
  • Allow a free plugin ecosystem: third-party plugins — whether scripting, WASM, or native — must be distributable under any license, including proprietary.
  • Be legally robust in the European Union, the project's primary jurisdiction.

The plugin architecture introduces a specific tension: the core is designed to be extended through plugins that load dynamically or run sandboxed. A pure copyleft license would create ambiguity about whether plugins constitute derivative works, potentially discouraging third-party development.

Decision​

All Ideal source code components will be licensed under the European Union Public License 1.2 (EUPL-1.2), with an additional plugin exception that explicitly excludes plugin software from the copyleft obligation.

The plugin exception reads:

As a special exception to the terms of the EUPL-1.2, software that interacts with the Work exclusively through its published plugin interfaces — including but not limited to scripting APIs, WebAssembly module interfaces, and native plugin APIs — is not considered a Derivative Work, regardless of how it is loaded or linked. Such software may be licensed under any terms chosen by its author.

This exception does not apply to modifications of the Work itself.

Each component repository will include a LICENSE file containing the full EUPL-1.2 text followed by the plugin exception, and a copyright notice identifying the Ideal project.

Alternatives Considered​

GPL v3. The most widely recognized copyleft license. However, it is US-centric in its legal language, does not include a plugin exception by default (would need to add one just like with EUPL), and its compatibility terms are more restrictive — EUPL's compatibility clause allows downstream redistribution under GPL, but not vice versa.

LGPL v3. Designed specifically for libraries, with explicit provisions for dynamic linking. This would solve the plugin problem without an exception, but LGPL's scope is narrower than what Ideal needs — it is a library license, not suitable for applications like the desktop shell. Using LGPL for libraries and another license for applications would add unnecessary complexity.

MPL 2.0. File-level copyleft: modifications to existing files must stay open, but new files can be proprietary. A pragmatic middle ground, but weaker protection than desired for the core. A proprietary fork could replace core files one by one over time.

MIT / BSD. Maximally permissive, which would allow proprietary forks of the core itself. This conflicts with the goal of keeping foundational infrastructure open.

Consequences​

  • All components share one license, simplifying contribution and compliance.
  • The copyleft ensures that improvements to the core flow back to the project.
  • The plugin exception removes legal ambiguity for third-party developers: plugins of any kind are explicitly free to use any license.
  • EUPL-1.2 is recognized by the OSI, the FSF (as a free software license), and the European Commission. Its compatibility clause allows downstream redistribution under GPL v2/v3, LGPL, MPL, AGPL, and others.
  • EUPL-1.2 is legally binding in all EU official languages, which is an advantage for a project targeting the European market.
  • The compatibility clause means a third party could redistribute the code under GPL v3, which does not have reciprocal compatibility. This is an accepted trade-off: the code remains open regardless of which compatible license it is redistributed under.