Licences & complementary agreements

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 FOSS licences, other conditions strongly differ:

  • 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 exempts 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 by reading 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)

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, if the licensor does not publish a FOSS exception list).

  • GNU General Public License (GPL version 2). The “historical” copyleft FOSS licence and the GNU GPLv3 - a very detailed and “technical” licence. More "international" (and less “US centric”) than the previous GPLv2, but 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".
     
  • 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 AGPL. Warranty / liability exclusions are motivated. Applicable law and venue are fixed. The EUPL 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 EC Directive 91/250, the EUPL accepts the reproduction of covered interfaces (static/dynamic linking) without any "viral" impact on linked software.

Other complementary agreements

Contributor agreements (CA)

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 CA 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 CAs 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.

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. 

 

Table of contents