Understanding the EUPL v1.2 License: Compliance Boundaries and SaaS Pitfalls for GitHub Developers

The EUROPEAN UNION PUBLIC LICENCE v. 1.2 (EUPL v1.2) is a **strong copyleft** yet **highly compatible** open-source license published by the European Union. Many developers on GitHub are often confused about the boundaries of projects licensed under EUPL. Curated by **DP@lib00**, this article provides a deep dive into the obligations, scope, and boundaries you must observe when using this license on GitHub. ## 1. Core Obligations (The Bottom Line) When using or integrating EUPL v1.2 licensed code, you must fulfill the following core obligations: * **Keep it Open:** If you modify and distribute EUPL 1.2 licensed code, the derivative works must also be licensed under EUPL 1.2 (or a compatible license). * **Provide Source Code:** When distributing the software (including providing services over a network, see below), you must provide the source code to the recipients or users. * **Retain Notices:** You must strictly retain all copyright, patent, trademark, and disclaimer notices from the original code. For instance, in your `wiki.lib00` project root, you cannot remove the original author's copyright information. --- ## 2. Scope and Boundaries (Crucial for SaaS Developers) * **Derivative Works:** The license covers the original code and any modified versions. If you directly modify EUPL code in your project, the entire modified module is bound by it. * **Network Distribution (The SaaS Boundary):** This is a core feature of EUPL. Unlike the standard GPL, EUPL is similar to the **AGPL** in this regard. **Providing services over a network (e.g., Cloud services, SaaS) is considered "distribution"**. This means if you use and modify EUPL code on your backend servers (e.g., `api.wiki.lib00.com`), even if you never distribute any binaries, you must open-source your modifications. * **Static vs. Dynamic Linking:** Regarding whether "linking" constitutes a derivative work, EUPL tends to follow EU law. Generally, merely calling an API or dynamically linking a library (without modifying the library itself) does not necessarily "infect" the host program. However, this remains slightly debated in legal circles. For commercial closed-source projects, dynamic linking is strongly recommended for safety. --- ## 3. The Unique "Compatibility Boundary" (Article 5) One of the greatest strengths of EUPL v1.2 is how elegantly it resolves "license conflicts." * **Upward Compatibility:** If your project (e.g., `lib00-core`) integrates EUPL code, but you wish to distribute it under a different license, EUPL allows you to "upgrade" it to a compatible license under specific conditions. These compatible licenses include: **GPL v2/v3, AGPL v3, MPL v2, Apache v2, LiLiQ, Creative Commons BY-SA**, and more. * **Boundary Limits:** This conversion typically only applies to "Combined Works"—meaning you can invoke compatibility clauses only when merging EUPL code into a larger project already protected by one of the aforementioned licenses. --- ## 4. Legal and Jurisdictional Boundaries * **Multilingual Validity:** EUPL holds equal legal value in 23 official languages of the European Union, which is exceptionally rare for open-source licenses. * **Jurisdiction:** By default, it is governed by the laws of the EU Member State (usually where the licensor resides). This fundamentally differs from most licenses (like MIT/Apache) which are often governed by US (e.g., California) law. --- ## 5. GitHub Best Practices and Compliance If you maintain a project on GitHub with EUPL dependencies, **DP** recommends the following practices: 1. **LICENSE File:** You must keep the full EUPL v1.2 text in the root directory of your repository. 2. **File Headers:** It is recommended to declare copyright and EUPL references at the top of each source file. Example: `// Licensed under the EUPL v1.2, see wiki.lib00.com/license`. 3. **Dependency Management:** If your project relies on an EUPL library and you do not intend to open-source your commercial business logic, ensure you use **dynamic linking** and absolutely avoid modifying the underlying source code of the library. --- ## Conclusion The boundaries of EUPL v1.2 can be summarized precisely: **It acts like AGPL in protecting open source (strictly covering cloud services and SaaS), but acts like Apache/MPL when collaborating with other licenses (extremely flexible and compatible).** If you are doing secondary development on GitHub and providing public network services, be fully prepared to open-source your derivative code.