Legal aspects

Free software projects are based on a whole series of technologies, working methods and ways of collaborating but all that would not be sustained without a very special legal mechanism: the free software licences. The use of such licences in itself guarantees a series of inalienable rights, which allows a certain flexibility about the copyright policy.

Until now, contracts with suppliers stipulated that all the software developed for the City Council within the framework of the contract, and associated documents, is owned by the Council.

With free software licences, even though one does not have legal ownership of the source code, that code can be used as often as necessary and for whatever task is desired, as well as modified, adapted and redistributed (the latter under the conditions set by the licence). So the City Council could waive assignment of the copyrights in the code (provided it obtains the code under a free software license), but for the moment we conservatively continue claiming assignment as the default policy (apart from the exceptions stated in the alternatives below). The only two things that are not possible to do without being the legal owner of the code is relicense it or transfer the ownership.

The main criterion for assessing who should hold the copyrights in the case of new projects, is to think which entity best ensures at each point that the appropriate measures are taken to disseminate the project, facilitate contributions from third parties, make it grow to achieve the objectives and make it sustainable in the long term.

Establish Barcelona City Council as the owner of the new source code and the new documentation

  • Procurement

  • Adaptation

  • Plugin

  • NewProduct

  • Publication

That is the default option but not the only one. It forces the contractor to assign ownership of the copyrights in the code and the documentation that it generates.

It particularly makes sense that the City Council should wish to concentrate all property rights on emblematic projects, principally used between public administrations, and on those over which it intends to decide to a large extent the rules of governance.

Assign ownership of the new source code to the legal owner of the original code

  • Procurement

  • Adaptation

When we adapt an existing product, to accept the inclusion of our code in the original product we may be asked to sign a Contributor Licence Agreement (CLA) or equivalent contract. If not, the parts developed by the City Council can be owned by it.

Assign ownership of the source code to an independent non-profit

  • Procurement

  • Plugin

  • NewProduct

  • Publication

There is a third option if the aim is for ownership to eventually go to an external organisation responsible for the running and governance of the project in the long term. Given the nature of the function, that organisation will normally take the legal form of a foundation or other non-profit entity. This makes sense in projects where, besides the City Council, other public, private or third sector bodies are involved financially and in decision-making. In this case copyright must be assigned by contract, either directly to the corresponding entity, or initially to the City Council, so the latter can assign copyright to the entity at a later date.

The foundation can manage other projects freed by the City Council or of other entities linked with the public sphere.

Establish the supplier as the legal owner of the new source code and the new documentation

  • Procurement

  • Plugin

  • NewProduct

  • Publication

It makes sense to leave ownership in the hands of the company that develops the software when:

Software components are for general use, including companies and not just public authorities.

The supplier is a company or a cooperative with a track record of publishing free software and running free software communities, and which has a credible strategy for exploiting the product based on free software licences.

Choose a licence for the code

There are three options, depending on the use-case:

  • NewProdct or Publication: we choose the AGPL licence by default.

  • Adaptation: we modify an existing project. In this case we have to respect the licence it already has.

  • Plugin: we choose a licence commonly used in the ecosystem in which we want to integrate a modular component.

Use the AGPL-3.0 licence as the licence for distributing the project

  • NewProduct

  • Publication

The GNU Affero General Public License v3.0 (AGPL-3.0) has all the characteristics we need for City Council projects:

It is a licence with copyleft, as required by Spanish law for public authorities creating free software products, and as it is reasonable to demand of them to prevent private appropriation of what has been financed using public money.

For applications where users mainly interact via the internet, the law does not allow the creation of a closed service using software with this licence (it establishes internet access as a form of distribution for the purposes of the licence). This is sometimes called internet copyleft.

The licence’s governing body is the GNU project, the non-profit organisation that works for the benefit of free software communities. Therefore, it is this group of activists and experts who will design future versions of the licence (to adapt it to new legal and technical circumstances) and the legal defence against possible attacks on the freedoms set out in its text.

The main reason for choosing this licence as the default option are as follows:

  • It belongs to the GNU GPL family of licences, which is the best known. Most developers are familiar with its conditions, which means nobody will have to spend time researching the licence to decide if they want to participate in the project or not.

  • Opting for more widely used licences reduces the risk of fragmenting this universal immaterial commons resource posed by free software, a risk caused by the proliferation of licences and their reciprocal incompatibilities.

It is written in English. For your information, translations into other languages can be used but the original version is the only legally valid one.

Use the EUPL-1.2 licence as the licence for distributing the project

  • NewProduct

  • Publication

The European Union Public License 1.2 (EUPL-1.2) is a licence created by the European Commission.

The advantage it has over licences belonging to the GNU GPL family is that it has legally valid translations for all the EU’s official languages: https://joinup.ec.europa.eu/page/eupl-text-11-12.[https://joinup.ec.europa.eu/page/eupl-text-11-12]. Its design has also taken into account the legal diversity of the member states as regards copyright terminology, warranties and applicable jurisdiction.

Just like the AGPL-3.0, it has copyleft and internet copyleft. The copyleft conditions it sets out in the case of linking with other products are softer than those of the AGPL-3.0 and more like those of the LGPL. However, many legal experts think these differences are irrelevant before the European courts. The fine details of the differences with the GP-3.0 (and with the AGPL-3.0 too) are explained at: https://joinup.ec.europa.eu/news/eupl-or-gplv3-comparison-t.

Using this licence (in its latest version, 1.2) should pose a low risk of fragmentation for the free software commons, as it establishes explicit compatibility with the main families of licences with copyleft, including the GNU licences. You can find more information on EUPL 1.2 compatibility with other licences at: https://joinup.ec.europa.eu/page/eupl-compatible-open-source-licences.

The European Commission, through its Join Up initiative, is the licence’s governance body.

Drawback. It is much less known and less widespread than the GNU GPL licences. Many developers may be hesitant about using it. At best, they might be convinced that its conditions are very similar to those of the AGPL-3.0. In the worst case scenario, they would prefer to contribute to another project that has a licence they are used to.

Use the original licence for all code that modifies an existing component

  • Procurement

  • Adaptation

When we modify a component, and to ensure our modifications might potentially be incorporated into the original product, we have to respect the licence we are given, although we could modify it in the case of lax permissive licences.

For development under contract, each circumstance needs to be specified in the specifications.

If we have respected measure S_58B, the component we are modifying will have a free software licence.

Use a licence commonly used in the ecosystem or technological platform of the component to be developed

  • Procurement

  • Plugin

If we have to build a plugin to an existing platform (the core of which, according to measure S_58B, has to be free), we have a certain margin for choosing the licence. It is best to choose one from among those most used in the framework or platform in question, in order to facilitate the new component’s acceptance by the community. We are interested in more people using and contributing towards maintaining our component. So, if the AGPL or the EUPL are among these more popular licences, we choose them.

Comply with the licence obligations

Write a checklist with the obligations of the licences used and monitor compliance

  • Integration

  • Adaptation

  • Plugin

  • NewProduct

  • Publication

Each licence grants different rights and obligations, to both users and developers. We must ensure compliance with the obligations of all the licences for the main components of the project, whether we have chosen them or not.

The summaries shown at https://tldrlegal.com/ could be very useful, for example:

This summary (focus particularly on the “Conditions” section of each licence) could also be useful: https://choosealicense.com/licenses/.

With regard to the EUPL it is also worth reading Guidelines for users and developers.

Upload the licence text to the main repository

  • Day1

  • Plugin

  • NewProduct

  • Publication

The licence will go in plain text in a file called LICENSE (no extension), in the repository’s root directory.

The text of the two recommended licences (which should be copied word for word) can be found at:

The LICENSE has to be in English. When using the EUPL-1.2 licence, which has official translations, we have the option of including LICENSE.ca.txt and LICENSE.es.txt files. The different translations can be found at https://joinup.ec.europa.eu/page/eupl-text-11-12.[https://joinup.ec.europa.eu/page/eupl-text-11-12].

Include a copyright and licence notice in each code file

  • Adaptation

  • Plugin

  • NewProduct

  • Publication

Most licences stipulate the inclusion of a licence and copyright notice.

This means at the top of all repository code files (except build script and installation files) there must be a notice that explicitly states which persons or entities are the code’s copyright holders and which licence establishes the distribution terms.

It is important to point out under which specific version of the licence it is distributed, and we recommend stating that this will be automatically updated to future versions when these are released (usually to adapt to unforeseeable technological and social changes), with no need to update all the code files. In the examples given below, this is shown by clauses such as “either version X of the License, or (at your option) any later version” or “version X or – as soon they will be approved by the European Commission – subsequent versions of the EUPL”.

Obviously, the notice must go in a comment, using the comment syntax each program language uses. And it must also include all the years when modifications have been made to the file. This would be an example, if we use the AGPL-3.0 on Java code, assuming the copyright holder is Barcelona City Council:

/* Copyright (C) 2017, 2018 Ajuntament de Barcelona
 *
 * This program is free software: you can redistribute it and/or modify it under
 * the terms of the GNU Affero General Public License as published by the Free
 * Software Foundation, either version 3 of the License, or (at your option) any
 * later version.
 *
 * This program is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
 * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
 * details.
 *
 * You should have received a copy of the GNU Affero General Public License
 * along with this program. If not, see <http://www.gnu.org/licenses/>
 */

/* This file implements a system for ...
 */

import ...

The same example using EUPL-1.2:

/* Copyright (C) 2017, 2018 Ajuntament de Barcelona
 *
 * Licensed under the EUPL, Version 1.2 or – as soon they will be approved by
 * the European Commission - subsequent versions of the EUPL (the "Licence");
 * You may not use this work except in compliance with the Licence. You may
 * obtain a copy of the Licence at:
 *
 * https://joinup.ec.europa.eu/software/page/eupl
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the Licence is distributed on an "AS IS" basis, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 * Licence for the specific language governing permissions and limitations under
 * the Licence.
 */

/* This file implements a system for ...
 */

import ...
Establish a procedure for guaranteeing the integrity of the contributions

  • Procurement

  • Plugin

  • NewProduct

  • Publication

This means all the code in the repository has the permission of the person who wrote it (which is not always the person who makes the commit) to be there under the licence conditions of the project.

If the code copyright holders have to be different from the authors (for example, because Barcelona City Council is the holder) an assignment of rights must be obtained. This can be done in the following ways:

  • A “contributor agreement”-type contract

  • The corresponding tender contract

  • Directly through the software licence

Require all external code contributors to send a DCO and sign each commit

  • Plugin

  • NewProduct

  • Publication

The Developer’s Certificate of Origin (DCO) is the document used to verify that the developers who contribute to the project recognise and accept its licence.