How to use the EUPL

 Frequently asked questions on the European Union Public License

  1. What is the EUPL?
  2. How to use EUPL?
  3. Is the software licensed under the EUPL “Open Source”?
  4. Where can I get the EUPL text in my language?
  5. What are the benefits of publishing software under the EUPL?
  6. Are there specific development requirements for the EUPL?
  7. How can I collaborate to a EUPL project?
  8. Can we translate a EUPL licensed application?
  9. What are the risks of publishing software under the EUPL?
    1. Copyright litigations
    2. Patent claims
    3. Warranty and Liability claims
    4. Security risks
  10. Why did the the European Commission create the EUPL?
  11. What makes the EUPL unique?
  12. Were other licences screened?
  13. What about new versions of the EUPL?
  14. What about compatibility issues?
  15. What are jurisdiction and applicable law?
  16. Does EUPL deprive me from intellectual property?
  17. Is EUPL software “for free”?
  18. Are they limitations to the use of the software?
  19. Can I provide government services on Internet, based on EUPL licensed software?
  20. Can I make my own software on EUPL software?
  21. Can I merge other software with EUPL software?

What is the EUPL?

The EUPL is a licence, meaning 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 software: communication, copy, change or distribution, in full respect of the applicable law. The EUPL licence is “Open Source” ensuring freedoms to use, analyse, adapt and redistribute the software.

How to use EUPL?

For detailed advice on

  • using software licensed under the EUPL
  • distributing your own software under the EUPL
  • please read the European Union Public Licence (EUPL v1.1 and v1.2) which is available in 23 European languages (external website, guidelines are listed below the licences)


Is the software licensed under the EUPL “Open Source”?

Yes. EUPL licensing makes software Open Source (or more generally “Free / Libre / Open Source Software – FLOSS) because 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.


Where can I get the EUPL text in my language?

The EUPL is approved by the European Commission in 23 linguistic versions (all current EU languages, except Gaelic). All linguistic versions have identical value. Therefore the EUPL may produce legal effects in any approved linguistic version.

To check all the linguistic versions of the EUPL please visit European Union Public Licence.


What are the benefits of publishing software under the EUPL?

As the author of the software, you (or your organisation / administration) will keep full ownership of the software with a guarantee that your copyright is publicly known and that your software will never been appropriated by a third party: all subsequent users will have to respect your copyright and if they distribute some improvements, you will benefit from it for free.

If you develop appropriate communication, organisation and leadership, your work will be more widely known and it will be both rewarding and motivating for you or for your team to be recognised as one of the domain experts in the field (due to the visibility of your work, you may expect to be invited in specialised workshops or to communicate your experience to other administrations sharing similar needs). This will both motivate your team and provide you interesting feedback, in return, or even support from volunteer contributors forming a kind or “community” with you and around you.

If your software is recognised as best practice (because of the achieved results, because of your presentations in workshops, in some case because of national or international recognition or awards), it may gain in visibility,  awarded in relevant events, be quoted in taxonomies of software repositories and eventually become a reference or a standard. This will maximise your return on investment and the long term sustainability of your work, by maintaining an active group of developers and by developing a competitive service ecosystem around it.


Are there specific development requirements for the EUPL?

There are few specific requirements, in the sense that all software development models (open or proprietary) share common issues such as security and quality: you could as well decide to apply EUPL licensing to any existing software application that you own, without regarding the way it has been developed.

However, there are differences concerning the way the software is distributed, bundled or packaged and the roles played by participants. If you want to benefit from the support of an external community, it is always recommended to apply a number of principles: It is recommended to start with more than a simple idea: an efficient application kernel, easy to understand and enrich with new functionalities is a preferred starting point. It is also recommended to dwell on successful other Open Source standards of existing projects: sustainability will be better if you build on such success than if you reinvent everything alone or duplicate what others have done already.

Concerning the development of your specific part, take care about:

  1. A modular design (a solid kernel facilitating the addition of several modules)
  2. The use of a version control system (which is normally provided on any “software forge”)
  3. A clear documentation explaining the objectives, scope, use cases and interactions according to standards
  4. An open mind team spirit, welcoming external participation, while keeping control and setting a direction
  5. Good communication and interface with the "developers community" 


How can I collaborate to a EUPL project?

By collaborating to an Open Source project, you will offer some of your work (time, writing work, lines of codes) to this project. By doing this, the EUPL requires one specific warranty from you: you must be the copyright holder of the provided work. This warranty is provided in Article 6 of the EUPL: Contributors warrants that the copyright in the modifications they bring to the work are owned by (or licensed for that purpose to) them.

Therefore, if you are an employee of a public or private organisation, it is strongly recommended to go to your department head and obtain their green light.

In a second step you should identify yourself and contact the relevant project manager, present your experience and explain your interest in collaborating (normally, you or your organisation should have a specific need that the project could cover). In order to avoid work disorganisation and duplication, it is important that your role in the project will be known, that your potential contribution will be defined and communicated to all stakeholders, knowing who you are and what you are doing or planning to do on which project module.


Can we translate a EUPL licensed application?

Facilitating the translation of EUPL licensed software (for example adapting an eGovernment application from UK or France to Slovakia or Romania) is one of the main potential utilities of the “common” EUPL licence. Adaptation is more than simple translation on another language: it is called “Localisation” because from one State to another, many parameters may vary:

  • the role of the stakeholders (depending on the organisation of the government, of the judiciary etc... ) and the rights attached to these roles;
  • the conditions of performing a specific operation (age, cost, VAT rate, pre-requisites);
  • the required time to perform an operation, etc.

Therefore, before trying to translate any interesting application, it is recommended to check that it was “made for localisation”. The software code should not contain any hard-coded messages or parameters: just the logical instructions and internal comments (usually in English) allowing readers to understand. All displayable text and all parameters depending on location should be stored in external files, with references to both countries and language because several countries may share the same language (as Austria and Germany) while in some other several languages are spoken (like in Belgium).


What are the risks of publishing software under the EUPL?

Risks are extremely low and may be classified in four subcategories:

Copyright litigations

You (or your developers) have copied parts from other software without appropriate and compatible licences or without reproducing copyright marks (this is copyright violation). Although this may happen occasionally (however generally for internal use and not for public re-distribution), the number of litigations related to Open Source software copyright is extremely reduced (a handful in ten years time) because cases are normally solved based on common agreement. Most existing software copyright litigations involve companies with conflicting commercial interests. In the case of a public administration distributing its own software, risk can be mitigated by suspending distribution during the copyright clarification, and as long as an agreement cannot be found.

Patent claims

What has been said for copyright is also true for other intellectual property rights (i.e. patents, in the exceptional case it could be applicable). Patents on computer programs are not allowed in European law “as such”, but in practice, patents have been granted that cover functionality in many common software applications. Patents pose a specific risk to the development of software because they protect the idea or the method and not simply the form, as copyright does. It is therefore possible to infring some patent without copying anything or without even knowing it. However, users are rarely subject to legal action for patent infringement. Developers and software licensors must almost always be notified first, prior to legal action seeking damages, thus giving them an opportunity to replace or remove the functionality that is possibly patented. The risk is therefore related to higher costs for replacing this functionality, rather than the direct costs of being subjected to patent lawsuits. In the practice, risks appear to be higher for proprietary software, where commercial interests are higher, than for Open Source distribution. Known software patents, such as MP3 audio or the LZW data compression have halted software development specific areas, but no Free / Open Source software has yet been subject to legal action for patent infringement.

In conclusion, when public administrations are using or distributing their own specific software under the EUPL, the risk from legal action related to patent infringement, while not zero, is very low.

Warranty and Liability claims

Liability for such damages are generally excluded by the EUPL licence, to the extent permissible by applicable law. Exceptions, as spelled out in Article 8 of the licence, could be your wilful misconduct (for example by distributing a computer virus) or direct damages to natural persons, which are not likely to occur regarding public sector software (risks look theoretical, and it seems that such case has never been met).

Security risks

Security issues are to be considered with more attention. If your software is well written, the publication of the source code should not facilitate security breaches (intrusion by hackers etc.) as the code should not contain passwords, nor sensitive or personal data as names or biometrics, or information on possible back door etc. At the contrary, the Open Source publication of the code should by the time reinforce software security by allowing a wider community to screen it for possible bugs.

However, if a software is effectively used for critical applications and if the published source code contains serious security flaws, disclosing the code will generate real risks of hacking, at least in a first stage, before bug corrections. Therefore, depending on the sensitive character of the application and the nature of accessed data, a risk assessment is recommended prior to Open Source distribution.


Why did the the European Commission create the EUPL?

EUPL was created by the European Commission under the IDABC programme because it responded to a need: the Commission had the willingness to distribute the software produced under the IDABC programme (with applications such as CIRCA, or IPM). A decision was taken to apply Open Source licensing principles while submitting possible redistribution to non-appropriation principles: the software produced by the European Commission had to stay open and non-proprietary.

None of the existing Open Source licences (more than 100 models exist) was satisfactory regarding a series of criteria:

  • the specificity of Community and Member State's law regarding copyright principles
  • the specificity of Community and Member State's law regarding warranty and liability issues
  • the specificity of Community and Member State's law regarding applicable law and jurisdiction
  • the requirement to obtain a text legally valid in all the official languages of the European Union.


What makes the EUPL unique?

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 the release of its software, 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.
  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 ensures downstream compatibility issues with the most relevant other licences (including the most intensively used, the General Public licence or GPL). Its unique compatibility provisions create a new category of F/OSS licence: "Copyleft compatible" (other are: "Strong copyleft", "Weak copyleft" and "Without copyleft")  


Were other licences screened?

Yes, as the EUPL elaboration that has taken more than two years started with the evaluation of several existing licences by a team of lawyers and software practitioners.he result of such investigation was a first report of December 2004 “Open Source Licensing of software developed by the European Commission“ published on the IDABC web site.


What about new versions of the EUPL?

According to Article 13 of the EUPL (which was modified in the EUPL v1.1 and v1.2), the European Commission may publish new linguistic versions and/or new versions of the EUPL, so far this is “required and reasonable”, and "without reducing the scope of the rights granted by the Licence". This means that:

  • the European Commission may update the licence to address new legal or technological issues that would otherwise keep the licence from functioning as intended.
  • Any new version will not change the fundamental characteristics of the licence, such as the freedoms it grants you, the liability exemption, or its reciprocal (or “copyleft”) character, meaning that the exclusive appropriation of the licensed work will not be authorised.

The key word in Article 13 is reasonable. The European Commission (EC) can indeed update the license, e.g. to cope with new or previously unknown legal problems that would otherwise keep the license from functioning as intended. However, any such changes must be reasonable, meaning that they cannot tamper with basic characteristics of the license, such as the freedoms it grants you, the liability exemption, or its reciprocal character”.

Each new version of the Licence will be published with a unique version number.

It is important to note that new versions are applicable to the software already licensed under the EUPL v.1.0, or to software that is licensed without an explicit version number, or with the explicit provision that later versions become applicable. As from the publication of the EUPL v.1.1 in January 2009, new versions (if any, in the future) will not be applicable automatically if the software was formally licensed "under the EUPL v.1.1". For such software, the licence upgrade will be depending on the agreement of the original author (who keeps control on licensing modifications).


What about compatibility issues?

Compatibility issues are resulting from the merging or integration of your work with other software components, when the licence of these components provides that modified works must be distributed under the same licence. Normally, the EUPL also does this, to protect your software against “appropriation”, however this may produce licence conflicts or “incompatibility”. Therefore EUPL foresees for "compatible licences", by allowing the resulting software to be distributed under the compatible licence instead of under the EUPL itself.

The compatible licences are currently defined by the EUPL v1.2 as being the following:

  • General Public licence (GPL) v2, v3
  • AGPL
  • LGPL
  • Open Software licence (OSL) v. 2.1, v. 3.0
  • Common Public licence v. 1.0
  • Eclipse Public licence v. 1.0
  • MPL
  • CeCILL v2
  • LiLIQ

This list will not be reduced (anyway, as soon a merged or combined work will be validly licensed under a compatible licence, this may not be revoked), but could be enlarged (e.g. to later versions of the above licences).


What are jurisdiction and applicable law?

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.

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.

However, EUPL v1.2 permits complementary agreements that may modify the applicable law and the competent court (i.e. selection of an arbitration process)


Does EUPL deprive me from intellectual property?

Does the EUPL preserve your full ownership of your work? Could EUPL licensing deprive you of potential opportunities (especially if you want to make some money out of licensing or recover your investment)?

By sharing your rights, you will not be deprived from your copyright or intellectual property. You will keep full ownership of your work, especially if you are the original author.

You may as well decide to undertake new developments, to distribute it or not, and if you redistribute it to re-licence your software under another licensing agreement, or even under a proprietary licence.

You may even manage two simultaneous distributions: an Open Source one (for example under the EUPL) and a proprietary one (that may include additional functionalities and be proposed for commercial fee). The name for this is “Dual licensing”.

It is a matter of fact that the existence of an Open Source licensed version will limit the possibility of merchantability of alternative licences: indeed, if a free Open Source version exists, why would users accept to pay high licensing costs for a “commercial-off-the-shelf” solution? Therefore, the additional fees requested from users in the framework of an alternative licence are generally justified by a higher warranty and a better level of support services.

A number of software companies operate according to this model (for example SUN for Star Office/Open Office or MySQL , which presents two versions - open and proprietary - of its database).

In the case of dual licensing, your sole potential issue will be to reduce forking (the co-existence and competition among different software versions) by integrating third party FLOSS contributions into the version that is licensed differently. If the Open Source test bed demonstrates the efficiency and profitability of a new specific module, you may find a convenient agreement with the author (you will normally have good contacts with him as member of your developers community) or decide to rewrite the most useful modules by yourself (copyright protects the form, not the ideas).


Is EUPL software “for free”?

As often reminded “free software is not for free”, meaning that it has certainly a cost, at least for developing, implementing, training the users and maintaining it. In the specific case of the EUPL, the rights granted by the licence are always royalty-free (as said in Article 2).

This does not restrict the merchantability of additional services related to the software, for example providing consultancy or support for implementation or maintenance.

Similarly the various stakeholders undertaking a common project may decide to share investments according to a separate “consortium” agreement, and to ask for a contribution in the case new participants would like to join (because they will then benefit from the support from other members or from the contractors of the consortium).


Are they limitations to the use of the software?

They are normally not: you can use the software for any purpose (for example commercial, private or non-profit), in any place or country (inside or outside the European Union), on any type of computer (from the mobile PC to the main frame) and for any number of users. You may also use it to provide your services on a network like the Internet or on your Intranet.

The only restrictions are related to modification and re-distribution of the software:

  • if you modify it, keep intact all existing copyright mentions and identify your own modifications by prominent marks (who did it, when, for what purpose) with mention of your own copyright
  • if you redistribute it, ensure that it is done under the EUPL licence, or under a compatible licence from the list attached to the EUPL (only if this is compulsory after merging or integrating the software with a component that is licensed under the compatible licence).


Can I provide government services on Internet, based on EUPL licensed software?

Yes you can. Indeed, Article 2 of the EUPL provides you the right to “communicate to the public, including the right to make available or display the Work or copies thereof to the public and perform publicly, as the case may be, the Work”.

Therefore, the deployment of the EUPL licensed software via Internet or via any similar public network is considered as a case of «distribution» according to the licence. This remains true even if the end-users perceive (for example through their Internet browser) only a selection of functionalities and not the whole software itself.

As soon such communication of EUPL software is done, the licence covers it (because – according to Article 10, the licence is accepted by exercising any rights granted by Article 2). However, this means also that, if you modify or improve some EUPL licensed software and use it to provide your services on line to the general public, you have to make your modified source code available on a repository, in order to allow the original author as well as other members of the «developers community » to benefit from your contributions, as the case could be.


Can I make my own software on EUPL software?

Yes, provide you respect (leave as they are) the existing copyright mentions related to the part of EUPL licensed code that is used in your own software.

If you decide to redistribute or to communicate to the public the resulting work, you will have to do so under the EUPL provisions (including the publication of your source code on a repository). Using the modified software to provide services via Internet is considered as a « communication to the public ».

By exception, the EUPL compatibility clause allows recipients to merge the covered code with other software covered by a compatible licence and to redistribute this merged software (= another project, with another name) under the compatible licence. Please note that this is not a "re-licensing" (meaning changing the licence) or the EUPL covered project, which has indeed provided some code but which must stay covered by the EUPL.  Compatible licences are listed in the EUPL appendix.


Can I merge other software with EUPL software?

Yes, you can merge EUPL software or any part or component of it with other software, provide this other software is yours (developed by you or for you) or was licensed to you under licensing terms allowing you to do so (which is the case with all Open Source software).

Please note that the question of how far software can be considered as “merged” is a matter of case to case appreciation. Merging criteria (or criteria to consider that a new software is a derivative) are not precisely defined in the EUPL, because it was not reasonable, due to the diversity of possible situations.

In most cases, simply aggregating, combining or linking software does not create a derivative.

Whenever possible, it is recommended that the different components exchange parameters or data without merging their source code into a single file. This would preserve modularity, facilitate future improvements and prevent licence compatibility issues in the case of re-distribution as the different components can then be used and possibly be re-distributed under their respective different licences.

If it is not possible to avoid the merging of the different codes within a single file, you will not encounter problems if you are using the merged software for your own needs (no distribution outside your organisation). However, if your intention is to distribute the merged software to third parties under the EUPL licence or to perform it publicly (for example by providing a service with it on the Internet), the pre-requisite is to check if the licensing conditions of the merged software are compatible.

To help you, Joinup publishes a list or matrix of licences that are compatible with the EUPL.

There is no problem if you have the copyright of the other software: the merged software is a derivative work that can be re-distributed under the EUPL.

There is no problem if the other software licensing conditions are permissive regarding the re-distribution under the EUPL (this would be the case if the merged component was licensed to you under a BSD or a MIT licence, for example).

At the contrary, if these licensing conditions are restrictive or “copyleft” (allowing no re-distribution under any other licence than the original one), you should check if this licence is included into the EUPL compatibility list. If this is the case (for example if the other software was licensed to you under GPL v2 or v3), there are no problems either: you are authorised to re-distribute the merged software under the compatible licence.

In other cases no re-distribution will be possible without a specific authorisation from all relevant authors. 

Some authors distributing components under a "copyleft" licence have implemented "FOSS exception lists" to authorise the distribution of larger (combined) derivative works under another FOSS licence. For example Oracle has included the EUPL in its FOSS exception list (for integrating MySQL components that are distributed under the Gnu GPLv2).