So it turns out that the EU has a course (short, ~20 min) introducing the EUPL to administrators who might want to use it. I think it’s interesting to look at to see how the primary sponsors of the license are thinking about it, and it’s accessible to the public (which is in the right spirit).
3 Likes
The EUPL made a good impression on me so it’s been stewing in the back of my mind. These are my current thoughts.
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.
1 Like