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.
As a Licensor, it is enough to write in your source code, documentation or anywhere in your work "Licensed under the EUPL" (as it is stated at the beginning of the EUPL licence).
This means the current version of the EUPL and is therefore equivalent to licensing under the EUPL-1.2-or-later.
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)
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.
The OSI (Open Source Initiative) organisation has certified/approved the EUPL as an Open Source licence.
The FSF (Free Software Foundation) organisation has certified/approved the EUPL as a Free Software licence.
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.
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 of “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:
- A modular design (a solid kernel facilitating the addition of several modules).
- The use of a version control system (which is normally provided on any “software forge”).
- A clear documentation explaining the objectives, scope, use cases and interactions according to standards.
- An open mind team spirit, welcoming external participation, while keeping control and setting a direction.
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 or at least a legitimate licensee 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:
- 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).
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. In case contributors to your project are employees from third parties with whom there is no contract assigning copyright to you, it is good practice and recommended to request from them and their employer a formal agreement or CLA (Contributor Licensing Agreement), since copyright is by default assigned to the employer, Directive 2009/24 states.
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 functionalities 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.
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 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.
The EUPL is unique for several reasons:
- 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.
- 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.
- 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).
- 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.
- 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. This ensures better legal security compared to licences that are not always operating under European Law.
The EUPL ensures downstream compatibility with the most relevant other reciprocal 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")
Yes: the definitions in article 1 of the EUPL (unmodified in all EUPL versions so far) 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 new guidelines published in September 2021 (dated July 2021) are totally in line with this definition.
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. The result of this 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 reconducted in 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).
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, if such situation occurs, the EUPL foresees for "compatible licences", by allowing the resulting combined software to be distributed under the compatible licence instead of under the EUPL itself.
Regarding software, 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 will be enlarged (e.g. to later versions of the above licences).
List enlargement is not automatic (the list doesn't provide "blank check" to "or later" versions), but will be done in so far the later version of compatible licences are still "open" (granting the rights provided by Article 2 of the EUPL) and "reciprocal" (protecting software from exclusive appropriation).
No. 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 like the LGPL it is not viral in the case of linking, is stronger than it may appear at first reading when the compatibility clause is legitimately used.
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.
As from version 1.2, the EUPL permits to introduce (i.e. in the copyright notice) provisions that may modify the applicable law and the competent court (i.e. assigning jurisdiction to another Member State) or to specify other provisions in a complementary agreement (i.e. adoption of an arbitration process), in so far the aim of these provisions is not to reduce recipient's rights
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), meaning that, even if the payment of a lump sum or any other contribution could be a legitimate requirement, i.e. to cover or share development costs, the Open Source model will permit later re-distribution to anyone and is therefore incompatible with royalties depending on the number of distributions, users, devices, transactions, etc.
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 commit themselves to keep knowledge into their circle (by signing a Non Disclosure Agreement / NDA), 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:
- 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 - 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 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 ».
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.
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 and a Licence compatibility checker in the JLA tool.
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, Apache 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 or the AGPL), there are no problems either: you are authorised to re-distribute the merged software under the compatible licence.
In other cases no re-distribution may 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).
Only the European Commission can modify the EUPL, so far this is required and reasonable and without reducing the scope of the rights granted by the Licence (article 13 states). So, if you bring modifications to the licence itself, it cannot be called EUPL anymore, but "MY OWN LICENCE" or any specific distinct name and it will not be OSI/FSF approved anymore. Therefore it is not recommended. But you may add complementary agreements to the EUPL in so far they are consistent with the Licence (article 9 states).
An example is the the assignment to the jurisdiction of another Member State, which does not reduce the recipient's rights: for example, a licensor with residence in UK may assign jusrisdiction to Germany (rather than Belgium), by specifying it immediately after the copyright notice as follows:
“Copyrighted (name, date). Licensed under the EUPL-1.2-or-later with the specific provision (EUPL articles 14 & 15) that the applicable law is the German law and the Jurisdiction Berlin” (for example). “Any redistribution must include the specific provision above”.
A second example is the conclusion of a formal Contributor Licensing Agreement (CLA) with third partie's contributors and their employers. This is useful because Directive 2009/24 assigns by default copyright to the employer. By assigning copyright to the project owner, a CLA may facilitate changes in licensing conditions without having to request consent from all authors/contributors.
Other examples are the provision of a service or warranty contract that will be binding for the direct licensor only (not for previous licensors or contributors), or the conclusion of a Non Disclosure Agreement (NDA) where participants commit themselves to limit distribution into their circle (i.e. for sharing development costs).
The Joinup Licensing Assistant (JLA) is a tool provided by the Joinup platform.
Its functionalities include:
- the selection of licences based on their content and access to their texts;
- comparing licences;
- assessing licence compatibility.
The JLA is focused on the 50 most-used open licences that everyone could use for licensing software or data, and not on the EUPL only.
When owning the copyright, the European Commission uses the EUPL for licensing software. This was initiated as from 2005 and has been confirmed by EC Decisions, the last being Decision C(2021) 8759 of 8 December 2021 stating that the open source licence granted by the Commission shall be the EUPL.
By exception, when a product or solution includes third party copyright obtained under a copyleft licence (like the GPL or AGPL), such licence can be provided.
More specific terms could be used when really needed and when appropriate, like when creating the “ISA Product Licence” for distributing EIRA, which uses/includes “ArchiMate” owned by The Open Group.
Concerning the reuse of the European Commission’s data and documents, the general principles have been fixed by Decision 2011/833/EU, stating also that these provisions could be complemented or replaced, where appropriate, by an open licence. This has been done in 2012 when creating the ISA Open Metadata Licence for distributing the ADMS semantic project, at a time when the Commission could not release works directly under Creative Common licences. The situation changed in February 2019 with decision C(2019) 1655 adopting Creative Commons CC-BY 4.0 as an open licence under the European Commission’s reuse policy. Thus, the trend is to avoid creating new “ad hoc” legal licensing instruments and to use licences that are recognised by internationally representative organisations: the EUPL for software and ancillary data (as from C(2021) 8759), and the Creative Common licence for independent data or documents (as from C(2019) 1655).