The name of the license can lead one to believe that it is reserved to be used by licensors from the European Union (European enterprises, public sector and citizens) for operating on the EU territory. 

This is not the case: the licence is “originated” and promoted/supported by the European Commission (as the “licence steward”) and by EU Member States, but anyone in the world, from public or private sector, can use it and take advantage from its 23 original linguistic versions.

The EUPL is recognised as an “Open Source license” by the Open Source Initiative. OSI categorises the EUPL as “international”. The EUPL is also recognized as a “Free software license” by the Free Software Foundation and as a convenient licence by most Free and Open Source software (FOSS) communities and bodies.

The licence is reasonably (or moderately/weakly) "copyleft" meaning that copies and derivatives works must stay covered by the same licence in case they are distributed to third parties. Applied to the source code of these derivatives, the term "copyleft" itself combines reciprocity (modifications of improvements are published and shared with everybody) and "share alike licensing” (the use of the same - or very similar - license ensures the persistence of granted rights). 

The definition of derivative works depends on the applicable law. If a covered work is modified, it becomes a derivative. Depending on the case, this gives rise to interpretation: if the normal purpose of the work is to help producing other works (it is a library or a work tool) it would be abusive to consider everything that is produced with the tool as "derivative". Moreover, European law considers that linking two independent works for ensuring their interoperability is authorised regardless of their licence and therefore without changing it. Since the EUPL is provided under the European law, this ensures no "viral" effect in the case of linking. 

The EUPL allows the covered work to be combined/merged with a work already covered by a compatible license listed in the EUPL appendix and including the GPL (all published versions so far: 2 and 3), the AGPL and the LGPL. In such case, the whole combined work can be distributed under the compatible license. This compatible license will prevail in the case it conflicts with the EUPL (but when no conflict exists the EUPL stays applicable).

For many open licences, distributing software is obtaining it (i.e. via downloading) in order to install it on your own device. Licences do not cover remote use, when a user interacts remotely with server-provided functionalities. The definitions in article 1 of the EUPL assimilates "communication to the public" to "distribution" and therefore targets and covers SaaS (software as a service) and the ASP (application service provider) activity.
Article 1 defines as "- Distribution or Communication: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, on-line or off-line, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person.".

Therefore on this specific point, the EUPL is similar to the AGPL.

The EUPL was created because it responded to a need: the Commission had the willingness to distribute its own software, applying Open Source licensing principles while submitting possible redistribution to non-appropriation requirements: the software produced with public money had to stay open and non-proprietary, but without invading third parties assets through a kind of “viral effect”.

None of the existing Open Source licences was satisfactory regarding a series of criteria:

• Combining reasonable copyleft (like in the LGPL) with the coverage of SaaS (like in the AGPL);
• Provided as original and legally valid in all the official languages of the European Union;
• Compatible with other copyleft licenses;
• Compliant with the specificity of the Union and Member State's law regarding copyright principles, warranty and liability, applicable law and jurisdiction.

The use of the EUPL is good practice, but not an obligation, except when redistributing code already covered by the EUPL. Some works are not mature or appropriate for needing sharing and distribution, although in specific Member States, the law could make it mandatory when the copyright owner is a public administration. In the case of distribution, the original licensor could prefer another licence: 

• a copyleft one, like the GPL, because inherited, i.e. if the original work includes a third party component obtained under the GPL or AGPL;
• a totally permissive one, like the MIT, in case the work is aimed be copied and included in many other works, even licensed under proprietary terms.

But the EUPL is the default licence applied (with possible exceptions) to all EC produced software (Decision C(2021) 8759) and is a licence that all national open software repositories connected to the Interoperable Europe Portal must propose (Interoperable Europe Act, article 8.4)

The EUPL is unique for several reasons:

1. For the first time, a public body of the size of the European Commission has officially developed and approved a Free/Open Source Licence for software distribution, and authorises the use of the Licence by any other stakeholder.
2. The EUPL has identical value in 23 linguistic versions (all EU languages, except Gaelic). No similar example exists in the world of Free/Open licences.
3. The EUPL has considered the specificity and diversity of Member States Law and the Community Law (copyright terminology, information, warranty, liability, applicable law and jurisdiction).
4. The EUPL covers not only the classical software distribution, but also the "communication to the public" through remote access, or the provision of SaaS (software as a service) through the Internet. On this specific point, the EUPL is like the AGPL.
5. The EUPL is not viral: according to the provision of European Law (Directive EC 2009/24 recitals 10 & 15), static and dynamic linking can be implemented with other programs without barriers or conditions. On this specific point, le EUPL works like the LGPL. This ensures better legal security compared to licences that are not always operating under European Law.
6. The EUPL is a "software license" by design, but it covers "the Work" and what could be considered as its components or derivatives:  documentation, ancillary data or even hardware in case it includes the Work.
7. The EUPL ensures downstream compatibility with the most relevant other reciprocal licences listed in its appendix (including the first intensively used historically, the General Public licence or GPL). Its unique compatibility provisions create a new category of Free/Open source licence: "Copyleft compatible" (other are: "Strong copyleft", "Weak copyleft" and "Without copyleft" or permissive) 

The EUPL ensures the following rights to the licensee:

• Obtain the source code of the software from a free access repository
• Use the software in any circumstance and for all usage
• Reproduce (copy, duplicate) the software
• Modify the original software, and/or make derivative works out of it
• Communicate the software to the public (i.e. using it through a public network or distributing services based on the software via Internet)
• Distribute the software or copies thereof to other users (inside or outside the licensee's organisation)
• Lend and rent the software or copies thereof
• Sub-licence rights in the software or copies thereof.

While the licensor commits to provide all the rights granted by article 2 and the public access to the source code, the licensee obligations mainly exist in the case of modification and re-distribution: 

• If the source code has been modified, to keep intact all existing copyright mentions and identify modifications by prominent marks (who did it, when, for what purpose);
• If the work is redistributed, ensure that it is done under the EUPL licence, or - after merging it with other software in a larger new combined work - distribute this larger derivative under a compatible licence from the list attached to the EUPL (only if this is compulsory after merging or integrating the EUPL-covered software with another software component that is licensed under the compatible licence).

Yes. No EUPL provision restricts the right of asking money for selling the licensed source code to recipients, or requesting funding to share development costs between an initial circle of subscribers. Free software is rarely “for free”. Multiple economic activities and services could be delivered on the market: installation, training, customisation, warranty and support in case any issue is met. Article 2 states that the licence is “royalty free”, but this is resulting of the open source model: multiple copies, modifications and redistributions are authorised, making this business model incompatible with the control of royalties based on the number of end-users, transactions etc. But the open source model is compatible with requesting, for example, an initial lump sum or rent.

The EUPL covers “The copyrighted Work”, which may include more than software code, for example documentation, specifications, taxonomies or ancillary data. The EUPL could even cover hardware, in so far it could be considered as a derivative of the included copyrighted software.

Even when a project is globally licensed under the EUPL, The licence does not grant permission to use the trade names, trademarks, service marks, or names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the copyright notice. This means that in the case of “forking” made without the consent of the original licensor, the distribution of the modified derivative must be done under another name.

The Licensee obtains a royalty-free, non-exclusive usage right to any patents held by the Licensor, to the extent necessary to make use of the rights granted on the Work under this Licence. 

Compatibility occurs when the codes distributed under two or more licences may be merged together in order to create a larger distributable software. This implies the right to distribute the larger software globally under a single licence (that could be one of the licences covering the merged source codes, or a new licence). This must not be seen as a ‘re‐licensing’ (changing the original primary licence) of the received components, but it can be applied to the new combined work as a whole and to any new code that has been added. The EUPL accepts two ways of compatibility:

• Inbound for merging source code licensed differently in your own EUPL code base;
• Outbound for merging all or part of your EUPL code base in a project licensed differently.

Software components covered by these licences can be merged with software code released under the EUPL and the resulting new software be distributed under the EUPL.  All permissive licences are inbound compatible (Apache, MIT, BSD). The moderately copyleft licences authorizing redistribution under a similar licence are inbound compatible also. This is also the case when a copyleft licence includes the EUPL in its own outbound compatible licences list (i.e. CeCILL or LiLIQ).

Compatibility can be checked with the tool “Licensing Assistant” (compatibility checker functionality) and by consulting the EUPL Matrix of compatible licences.

Software components covered by these licences that are listed in the Appendix of the EUPL, can be merged with software code already distributed under the EUPL and continue to be distributed under their primary licences.

The list includes: 

• GPL-2.0 and GPL 3.0;
• AGPL-3.0;
• LGPL-2.1 and 3.0;
• OSL-3.0;
• CECILL-2.0 and CECILL 2.1;
• EPL-2.0 and 2.1;
• CPL-1.0;
• MPL-2.0;
• LiLiQ-R and Rplus;
• CC-BY-SA-3.0 (and 4.0) for data.

Compatibility can be checked with the tool “Licensing Assistant” (compatibility checker functionality)

The original code will stay covered by the EUPL. It is the combined work only that could be, when needed, covered by the compatible licence. In this framework, a combined work results from merging functional codes covered by two (or more) different licenses. The simple action of "linking" does not merge functional codes and in such case the various linked parts will keep their primary licences. This is resulting from the European law, since Directive 2009/24/EC states that interfaces (APIs, data structures etc.) needed for making two programs interoperable can be freely reproduced/used in the various source codes, as an exception to strict copyright rules.

To be legitimate, the use of the compatibility clause must result from necessity: using it for the sole purpose of relicensing a copy of the original work would be a copyright infringement.

Some of the listed compatible licences, like the MPL or the EPL are known to be "less copyleft" or "less reciprocal" than the EUPL. Is there a risk to reduce the EUPL reciprocity (obligation to provide the source code) or the EUPL coverage (since "communication to the public" covers the remote performance of software through a network, also known as SaaS)?

The EUPL states that in case the compatibility clause is used legitimately, “Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under this (EUPL) Licence, the obligations of the Compatible Licence shall prevail.” Yes, but other obligations, in particular resulting from the definition of Distribution (Article 1 of the EUPL related to the coverage of Communication to the public or SaaS, like the AGPL) and the obligation to provide access to the source code will persist in addition to those of the Compatible Licence, because none of the compatible licenses are in conflict with the EUPL on these specific points: for example, the GPL does not mandate to provide access to the source code in case the software is performed remotely, but it does not prohibit it.

So the reciprocal/copyleft effect of the EUPL, even if it is not viral in the case of linking and permits reuse in projects licensed under compatible licences, is stronger than it may appear at first reading when the compatibility clause is legitimately used.

The question is crucial because in case the third party software was obtained under a copyleft licence (quite often GPL or AGPL), this could force the use of the same license in case the work is distributed: private use is never impacted but derivatives works must stay covered by the same licence in case they are distributed to third parties. So far, the EUPL itself does not clarify the notion of derivative, because it depends on the applicable law. 

In practice, the simple fact of “Using” a covered component as a dependency or as a tool, does not transform your work in a derivative, like it would be if the covered source code is really merged, incorporated in your work or modified by you to interoperate with your work.

If the used component is not merged, not modified, but simply linked, European law considers that linking two independent works for ensuring their interoperability is authorised[CM1]  regardless of their licence and therefore without impacting it: no "viral" effect. This is based on recital 10 and 15 of Directive 2009/24/EC. We may also consider that if the normal purpose of the external component is to help you for producing other works or that it must just be present as a dependency (i.e. it is a library or a work tool that you use without any modification and according to its normal usage instruction) it would be abusive to consider everything that is produced with the help of the tool as "derivative". In such cases each part (tool and resulting production) can be licensed separately, with possibly different licences.

But the question is intensively debated and rarely clear cut.

As a licence, the EUPL can be considered as a contract between a Licensor (the author of the software) and a Licensee (the user of the software, who can then use it according to the licence terms). Such licence is compulsory to authorise the widest possible use of the copyrighted work: communication, copy, change or distribution, in full respect of the applicable law. There is no need to sign this contract: From the licensor point of view, the commitment results from copyright mention inserted in the published source code and documentation: i.e. “Copyright MyName 2025, Licensed under the EUPL”. From the licensee point of view, commitment results from any form of agreement, or from the simple fact of using the Work.

This just means that, in case the text of the licence is not clear enough, it has to be interpreted according to the European Law, which is itself available in 23 original linguistic versions and, in all EU Member States, is a derivative of the same Directive.

The EUPL article 13 provides guaranties on this point: The European Commission may publish later EUPL versions “so far this is required and reasonable, without reducing the scope of the rights granted by the Licence”. Due to this formal commitment, licensors may (and not must) confidently protect their works under the “EUPL-v1.2-or-later”. Resulting from the licence introduction (second paragraph) using the general statement “Licensed under the EUPL” automatically refers to the latest version.

Through its annex,-the EUPL is compatible with the GPL-v.3 and other licenses without adding this “OR-LATER” extension (that the FSF in particular is stubbornly trying to impose as a must). In so far you trust the licence steward, there is no harm in licensors doing this. Adding “-or-later” after naming the licence could be considered as a good practice. But when revising the first EUPL version, OSI stated that an automatic and mandatory extension to later versions was contrary to their open source principles. This is because they were unable to assess the compliance of hypothetical later versions with these principles. There is no reason to make a blank check mandatory. It is about sovereignty. Nobody knows the future. Let's concede that there is little chance that FSF or the EC will ever be bought by Mr. X, but who knows?

A “total” exclusion of liability (like in most other licences, from MIT to GPL) is invalid according European and Member States’ law. So the EUPL disclaimer works “Except in the cases of wilful misconduct or damages directly caused to natural persons”.

The EUPL states “wilful” to exclude liabilities resulting from accidental or involuntary inherited corruptions, and it will be to the victim to prove the wilful misconduct. 

In Europe, product liability is a matter of public order. This is an extra-contractual liability regime which benefits any victim (consumer or professional) of a product safety defect, whether or not bound by a contract with the producer. So here also, the EUPL provides a useful warning that the license cannot help to circumvent the law. No other license could do that anyway in case the European law would be applicable.

The EUPL justifies the absence of formal guarantees since the Work is a work in progress, which is continuously improved by numerous contributors. However, the licence permits licensors to grant, on their own responsibility, additional guarantees. In addition there is a warranty that is almost never mentioned in other licenses: in article 6, the EUPL includes a CDO (contributor declaration of origin), stating that both the original licensor and all subsequent contributors “grant that copyright in their contribution is owned by them or licensed to them and that they have the power and authority to grant the Licence”.

The EUPL refers to the jurisdiction of the European Court of Justice in the case the European Commission is the licensor of the software. By referring to this exception, the EUPL does not intent to create any discrimination (between the European Commission and other stakeholders). It just reminds Article 238 of the Treaty establishing the European Community.

According to Article 14 of the EUPL, any litigation resulting from the interpretation of the licence will be subject to the exclusive jurisdiction of the competent court where the licensor resides or conducts its primary business. Without impacting the validity of other EUPL provisions, it cannot be totally excluded that due to compulsory rules, the “court of the residence of the consumer” would consider itself as competent.

According to Article 15 of the EUPL, the competent court, whatever it may eventually be, will take its decision by applying the law of the European Union country where the Licensor resides or has his registered office. It will be the Belgian law if the licensor is the European Commission or - for reasons of legal security - if the Licensor has no residence or registered office inside a European Union country. However, on most points, all Member States' law are based on the same framework: Directive 2009/24/EC published in 23 languages, which will be, included its recitals, the main source of law.

By this provision, the EUPL ensures that the competent court will have – in any case – to appreciate the EUPL rights and obligations in consideration of the law of a European Union country.