Thoughts on the EUPL

Full text of the EUPL
Full text of the AGPL

¶ Baseline Considerations

I am concerned about enclosure in software development. In some instances, organizations will use the "Software as a Service" model to take advantage of software licensed under, for example, the GPL in order to keep improvements secret even as they use the work in a public manner. In other instances, organizations will use the "Open Core" model to bait people with a small amount of freely available code in order to draw in customers and generate free labor to improve their product. These concerns are why I have generally defaulted to using the AGPL when publishing source code.

However, I am also concerned about the long-term well being of the free software community. This requires that we are able to work in harmony with each other in spite of differences which may be essential or incidental. One challenge which the AGPL does not do a great job of handling is license compatibility. There are some other licenses which try to provide similarly strong protections, but are incompatible with the AGPL.

Due to these problems, so-called "permissive" licenses have become popular. The Rust programming language, which is a significant technical achievement and whose community appears to earnestly believe in free software, is dual-licensed under the Apache and MIT licenses. Many popular Rust projects follow suit or publish under the MIT license alone. This makes it vulnerable to enclosure. There are no signs that this will happen any time soon - not within my lifetime and perhaps not the next - but leaving such an obvious vulnerability intact makes me uncomfortable.

¶ Strengths of the EUPL

The EUPL seems well designed to handle both of the above challenges effectively. It has strong copyleft protections on its own: source code must be shared whenever the compiled work is shared, and its definition of sharing includes Software as a Service (comparable to the AGPL). However, it also explicitly states compatibility with certain licenses so that we can work together in harmony in spite of differences which should not divide us so greatly. Particularly when those differences are born of historical accidents and the difficulty of changing legal documents. It also provides legally binding translations which is good for harmony throughout the community. It would be nice if they added non-European languages to the list, though I understand why this is a difficult ask. (Maltese is complicated.)

There is also an underlying attitude coming from the EUPL and its proponents which I believe is beneficial to the movement, even though I do not believe this was their intention. The preamble to the EUPL v1.0, the motivation for the EUPL is to make sure that software produced by EU governments is interoperable. It also seeks to protect the openness of the code moving forward, as this protects interoperability over time. As described in the "Discussion on 'Linking'" section of this statement, the EUPL was crafted in a time of legal uncertainty about how European courts would determine whether or not a work was derivative. This led the authors to craft a license that would protect the EU's source code regardless of whether combined works are considered derivative or not. This leads to a familiar strategy: be conservative in how you license internal code, be liberal in what licenses you accept from external code.

¶ Aside: On Linking

The linking topic is an important and contentious point so I think it deserves elaboration. In our current situation, every time 2 projects try to collaborate there is a potential point of conflict: whose license do we use? This conflict only occurs because we have decided that the final program must have a single license which covers the entire work, even if it is made from multiple components which have different licenses. The people who distribute the resulting executable should have to comply with each license: if some of the sources were offered under the AGPL they should have to publish those source files under the terms of the AGPL. But if others offered their code under the terms of the MIT license, it is not right for me to use the legal system to force their code to use the terms of the AGPL instead. I did not perform that work. I have no right to control it even if I have a right to use it. I think that most people who choose permissive licenses are concerned with ensuring harmony on the ground, and are willing to sacrifice legal protections in order to achieve it. By following the EU's application of the robustness principle, we promote harmony within the community and strengthen the movement. I want free software to be a shining beacon of hope for the world that demonstrates how strong and prosperous we can be when we work together in harmony and stubbornly respect all rights, whether individual or collective.

¶ Concerns about EUPL

I do have 2 concerns about the EUPL.

My first concern is article 4, which is mainly a concern because I don't know what it means. The language sounds like it protects software patents, but it is titled "Limitations on Copyright".

The other concern is clause 12, which states that the license is automatically terminated upon breach. My understanding is that it is not uncommon for accidental breaches of the xGPL family of licenses to occur, and it would be problematic to automatically revoke it upon breach. Clause 8 of the AGPL states that the license remains valid so long as breaches are cured within 30 days of notice, which sounds reasonable.

¶ Conclusion

I am leaning towards dual-licensing future work under the AGPL and EUPL. Generally I think that the EUPL does a better job of representing my interests. However, I also think it will be useful to offer the AGPL as an option as it is more widely known and used in the USA.

By stating a preference for the EUPL I mean no disrespect for the pioneering work of Stallman or the continued work organized by the Free Software Foundation. Notably, in one document produced during official discussion of the EUPL the 4 freedoms are explicitly acknowledged as the original founding principles of free software which should still be respected. Acknowledging the innovations of the EUPL is a celebration of the universal applicability of the free software movement. Joining in it is a continuation of the free software culture of sharing and learning and building together, without bias towards or against any people.