Frequently asked questions on the European Union Public License
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.
For detailed advice on
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:
The EUPL is approved by the European Commission in 22 linguistic versions (all current EU languages, except the Irish). 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 (EUPL v.1.1).
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.
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:
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.
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:
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).
Risks are extremely low and may be classified in four subcategories:
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.
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 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.
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 EUPL is unique for several reasons:
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.
According to Article 13 of the EUPL (which was modified in the EUPL v.1.1), 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 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).
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 as being the following:
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).
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.
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).
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).
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:
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.
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 ».
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 v. 2), 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).