Why a licence?
When someone writes software, the resulting intellectual property (software and documentation) is protected by copyright law, just like a literary or artistic work.
Owning the copyright in a piece of work, whether a book or software, means that the owner, usually the original authors or their employer, decides who can copy it, adapt it and distribute it. By default, only the owner can do that. Anyone who copies, changes or distributes someone else’s work without permission can be subject to legal action.
Therefore, the permission to use, copy, change, or distribute a software can only be granted through a licence.
In Europe, the licence is generally considered as a contract between a Licensor (the author of the software) and a Licensee (you, the user of the software, who can then use it according to the licence terms). Note that if you do not agree to the licence terms, you normally do not have the right to use, copy, change or distribute the software. If you do this without agreeing to the licence terms, you are violating copyright law.
The Free/Open Source freedoms and principles
All projects hosted on Joinup must be distributed according to Free or Open Source conditions. We consider the two terms as synonyms, even if “Open source” is the most used by economic operators and administrations. We often use the acronym “FOSS” (Free/Open Source Software).
FOSS licences comply with four freedoms expressed by the Free Software Foundation (FSF):
- Freedom to use or run it for any purpose and any number of users;
- Freedom to obtain the Source Code (in order to study how the software works);
- Freedom to share, to redistribute copies of the software;
- Freedom to modify, adapt, improve the software according to specific needs and to share these modifications.While the four freedoms above are present in all FOSS licences, other conditions strongly differ.
Licences may be “copyleft” (you must reuse the same licence if you re-distribute) or not
With more details, another non-profit organisation, the Open Source initiative (OSI) has implemented the Open Source Definition (OSD) based on 10 principles (see: www.opensource.org/docs/definition.php)
Other provisions
While the four freedoms above are present in all Free/Open source licences, other conditions strongly differ:
- A copyleft clause (using the same licence in case of refistribution) may be included or not
- Source code publication (reciprocity) may be a requirement in case of distribution, or not
- Remote access may be considered as a "Distribution", or not
- The warranty / liability exclusions may be general or more explicit
- Applicable law and competent court (venue) may be specified or not
- Provisions may fight some business practices (like software patent or proprietary standards) of not (being neutral)
The most used FOSS licences
The Open Source Initiative (OSI) maintains a (already too long) list of more than 60 “approved licences”. The effective number of existing “OSD compliant licences” may be 10 or 20 times higher (due to a phenomenon of licence proliferation during the last years). However, the certification as “OSI approved licence” is the most convenient (i.e. for FOSS requirements) as it covers most practical cases and (partly) exempts non-lawyers from tedious analysis of licence texts.
Inside the OSI list, the most used licences represent a kind of FOSS licensing standards or “best practices”. The following reduced list is based on the 2006 OSI Report of licence proliferation, complemented by two more recent licences, the EUPL and the GPLv3. Our own classification in three groups is indicative. You will find additional support in the licence wizard and in the Joinup Licensing Assistant that will provide you access to the text of these licences
Permissive licences (authorising software appropriation)
Licences that are recommended for component libraries aimed to enter in larger works (source code of component stays covered, but executables and larger works can be more freely re-distributed)
- GNU Library or "Lesser" General Public License (LGPL version 2 and version 3)
- Mozilla Public License 1.1 (MPL)
- Common Development and Distribution License
- Eclipse Public License (including the previous CPL Common Public License)
Reciprocal (or copyleft) licences where the work is globally protected against licence appropriation, the same licence must be used in case of re-distribution. In general, these licences are most convenient for end-user applications (and less for component libraries, except the EUPL that has a large compatibiliy).
- EUPL – the sole OSI approved licence valid in 23 languages. Reference to European applicable law principles (few specific details about business practices) but covering also “software as a service”, like the GNU/AGPL. Warranty / liability exclusions are motivated. Applicable law and venue are fixed. The EUPL mainly differentiates from GPLs by compatibility and interoperability. Regarding compatibility, the EUPL-1.2 authorises the distribution of combined derivatives under 12 other reciprocal licences. Regarding interoperability and based on Directive 2009/24/EC, the EUPL accepts the reproduction of covered interfaces (static/dynamic linking) without any "viral" impact on linked software.
In addition, the EUPL includes a DCO (see hereafter) and covers "software as a service". It is used by default for distributing software produce by the European Commission (Decision C(2021)8759) and the 2022 proposed Interoperable Europe Act states that it shall be proposed by all Member States portals distributing public sector software.
- GNU General Public License (GPL version 3). After the “historical” copyleft FOSS licence GPL-v2, the v3 is a very detailed and “technical” licence, more "international" (and less “US centric”). Original in English only (translations have no legal value). Representative of the most radical free software philosophy (reacting against recent business practices in the field of software incorporation in hardware, patents, digital rights management etc.). The GPLv3 has a variant (the AGPLv3) covering "software as a service". The reuse of the GPL or AGPL will be mandatory as soon a distributed work includes substantial parts of source code received under these licences, or (according to a FSF theory) is depending on linking with programs received under these licences.
Other complementary agreements
Developer Certificate of Origin (DCO)
The Developer Certificate of Origin (DCO) is an affirmation that the source code being submitted is originated from the developer, or that the developer has permission to submit the code.
As it is a “light weight” simple declaration, the DCO is known to be a well-accepted way for contributors to certify that they wrote or otherwise have the right to submit source code as their contribution to a project, while at the contrary a CLA (see hereafter) which is a formal signed contract assigning more and exclusive rights to a project owner – may constitute a dissuasive barrier.
The EUPL is one of the rare Open source licence that includes a DCO for both the original licensor and for all subsequent contributors as follows (article 6):
"Each Contributor warrants that the copyright in the modifications he/she brings to the Work are owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence."
Contributor Licensing or Assignment Agreements (CLA / CAA)
When launching a FOSS project, it may by useful to sign with participants a specific contract, in order to aggregate and assign the copyrights of open source code in favour of a single sponsor. The CLA may authorise the sponsor deciding alone about the participation of new “contributors”, the opportunity of public distribution, the licensing conditions (one or more acceptable licences could be defined in the agreement, however the sponsor could have the right to change the licence, to adopt a new licence version, to authorise dual licensing, to publish a FOSS exception list for larger works etc.).
The disadvantage of CLAs (or CAA - Contributor Assignment Agreement) is that potential contributors may refuse to enter a community where one member has more rights than the rest (Authors equality in an open, meritocratic oligarchy is a key to FOSS success). Another risk is project appropriation in case the sponsor sells its rights to a third party (or is purchased, merged with another economic operator).
Projects like the Linux kernel or Mozilla where successfully developed without any CA. However, without unique sponsor, these projects may be subject to intensive forking and updating their licence may become impossible (lack of unanimity between many authors).
On the other hand, a CA looks legitimate when a specific sponsor provides the bulk of the work and/or budget a project may need to survive.
A branch of the solution is making the community itself (i.e. in the case of a community hosted by a non-profit Foundation) the beneficiary of the aggregated copyright, or ensuring that the sponsor is non profit by nature: a CA is therefore most appropriate when a public authority (European institution, government, municipality) defines the requirements and organises the sponsoring of a FOSS project (possibly including some way to pay the work of contributors).
Another branch of the solution resides in the provisions of the CA, which may provide warranties about community management and licensing (a limited list of licences, “OSI-approved only” etc.)
A group called Project Harmony is working to present best practices in the matter of CA. Pros and cons of CAs are discussed there.
A draft CLA template (to adapt - here) was developed under the ISA2 programme
Non disclosure agreements (NDA)
Contracting a NDA may appear like the contradiction of any open source approach, where the principle is source code publicity.
However, in early development phase and as long some maturity is not reached, it may be necessary to maintain source code disclosure inside a limited circle of participants. This could be the case for public sector projects where security aspects are important, or when adopting FOSS development methods inside a restricted circle (or club) participating to software mutualisation.
NDAs could be implemented as a part of contributor's agreement, during a transition period.