Policy on technological sovereignty and guidelines for its implementation

Principles and guidelines

The policy on the technological sovereignty of the City Council is based on the principles and guidelines set out in the 2017-2020 Digital Barcelona Plan: Transition towards technological sovereignty, digital service standards and the Code of Technological Practices.

Generally speaking, these principles consist of:

  • The use of free standards for all digital services.

  • The prioritisation of free software and the reuse of IT resources.

  • A new relationship model with providers and free software communities.

  • A flexible intellectual property policy.

The main elements of this policy can be consulted below.

These principles and guidelines will be rolled out progressively via projects for digital transformation and migration to free software undertaken by the City Council and whose costs will be assumed by the IMI, which shall set the pace and make it possible to dedicate resources, create an infrastructure and acquire competencies to this end. This shall enable an iterative management of change implied by applying this policy within the organism via specific projects. Some projects and their extensions (for example, Decidim Barcelona, Sentilo, BIMA) already comply with these guidelines, whereas others will gradually become aligned with them as part of a more progressive implementation process.

Free standards and interoperability

The digital services of Barcelona City Council must be implemented using shared and open architectures for services, information and technology. Services will be built by implementing shared solutions in terms of system integration and their interfaces. The solutions will use free standards.

Interoperability

All of Barcelona City Council’s digital services will support interoperability, based mainly on the use of free standards and formats.

  1. The interoperability requirements of each system, both externally having an impact on citizens, and in terms of the exchange of information in internal processes, shall be implemented based on free standards and formats, with the sole exception of systems that have already been deployed, for which there is no plan in place yet for their replacement.

  2. Particular emphasis shall be placed on interoperability for the future: this ensures that the data retained by the City Council can be used (exploited, modified and expanded upon) regardless of the applications (and providers) that are used in the future.

  3. When interoperability is required from systems that have already been rolled out and that use nonfree standards or formats, the option of amending these systems shall be considered by adapting them to free standards.

  4. The interoperability needs of each system that must be developed or acquired shall be detailed in the tender specifications. Two different sets of circumstances may apply:

    • In the event that a specific interoperability need is covered by an internationally accepted free standard, the tender specifications shall provide the name and version of this standard.

    • When a specific interoperability need cannot be covered by an existing standard, the technical documents attached to the tender specifications shall contain full details of the information, protocols, interfaces, formats and processes to be used. These details shall make its implementation possible without having to resort to specific products or providers.

  5. As an example of a specific case implementing these interoperability guidelines, please consult the City document management policy (at http://ajuntament.barcelona.cat/arxiu-municipal/sites/default/files/InstruccioPoliticaGD_cat.pdf)
The use of free standards

The City Council’s digital services shall use free standards on a mandatory basis and, in particular, the contents of the catalogue of standards set out by the Technical Interoperability Norm (specified under Royal Decree 4/2010) or internationally accepted free standards that update, replace or complement these standards. When no approved free standard exists in the required format, a proposed format shall be submitted conforming with applicable regulations and the IMI’s requirements for the free standards.

  1. A free standard must satisfy the following conditions:

    • It is public and can be used free of charge or at a cost that poses no difficulty in terms of access.

    • Its use and application are not dependent on the payment of an intellectual or industrial property right.

  2. Free formats and standards shall be designed using the standard channel for exchanging information with citizens and no alternative or complementary method that uses closed options. Under no circumstances shall citizens be required to file an express request or perform additional activities to exercise their right to use free formats and standards.

  3. Under no circumstances may the City Council force citizens to purchase or use systems belonging to specific suppliers to access public services. The foregoing would amount to ensuring that these providers have a monopoly, sanctioned by the public authority.
Identification of standards and formats

The IMI will maintain public lists of technical formats and standards in use, categorised as mandatory, priority or recommended.

  1. To facilitate the specification and procurement of systems and solutions, the IMI will maintain a list of technical standards that must be used.

  2. The IMI would update the list in terms of both the evolution of national regulations and the evolution of international standards developed by the corresponding standardisation institutions.

  3. Some standards may be mandatory for specific uses and recommended for others.
Selection of standards

The selection of standards shall be subject to an open and transparent selection process based on users' needs, flexibility, the promotion of free competition and free collaboration and the implications on future interoperability. This process must be formally approved. Areas with their own legal framework shall be subject to the specific standards (for example, Geodata).

  1. Applying a formal selection process is recommended, based on national regulations (Royal Decree 4/2010), the European Interoperability Framework (EIF) and the internationally recognised methods, such as the Common Assessment Method for Standards and Specifications (CAMSS, https://webgate.ec.europa.eu/fpfis/mwikis/idabc-camss/index.php/Main_Page).

  2. Specific sectors shall maintain their own lists. For example, Geodata, for which a very strict framework is in place (http://www.bcn.cat/geoportal/es/estandards.html).

Free software and the reuse of resources

The City Council’s policy in terms of free software seeks to harness, insofar as possible, the benefits of the free software development model, both in terms of the general technological sovereignty objective and on the grounds of economies and technological quality. Therefore, the main elements of this aspect of the City Council’s technological sovereignty policy are as follows:

  • To facilitate and promote the effective and efficient use of free software at the City Council.

  • To reusing existing software and facilitate the reuse of the City Council’s software by third parties, both amongst administrations and other individuals and institutions (under free licences).

  • To migrate the City Council’s systems to free solutions.

  • To contribute and participate in free software communities, with a particular emphasis on local communities.

  • To ensure respect for the rights of the City Council and third parties, in particular those of developers and members of the free software community.

When the City Council has access to the source code of its applications, in addition to the rights of reproduction, modification and distribution inherent to free licences, its independence from specific providers and the future maintenance and sustainability of municipal systems is guaranteed. Furthermore, a free software-based system is particularly useful when building services to be used by different municipal institutions and that can be shared with other administrations as well as with the wider user community. Public access to the source code is also a guarantee of transparency in terms of particularly important or sensitive systems, such as, for example, electronic voting or tax calculation systems.

Along these lines, the main elements of this policy, as defined in the Code of Technological Practices, can be seen below. We will discuss each element in more detail, offering explanations and guidance for their implementation.

GENERAL GUIDELINES

The IMI’s basic free software principles for complying with the city’s technology sovereignty principles are as follows:

  1. The public procurement of tools and systems shall prioritise free software.

  2. All municipal technology projects that develop software internally or subject to contract, insofar as possible, shall ensure that said software is made available as free software.

  3. With this objective in mind, internal development programs shall be based, by default, on open technologies that allow the final product to be freed.

  4. Free software shall be used progressively by all municipal systems and applications as provided for by the City Council’s free software migration plan.

These principles are structured around the following guidelines set out in the Code of Technological Practices:

Acquisition

The acquisition and public procurement of tools and systems shall give preference to the use of free software for all the technical architecture of the applications and services that are delivered, avoiding reliance on systems that are not free. The deployment and use of closed systems shall only be allowed under exceptional circumstances, which shall be reviewed on a case by case basis, pursuant to the following criteria.

  1. Contracts for the purchase and development of digital services, including those concerning the adaptation of existing systems, must give preference to solutions and services based on free technologies.

  2. The use of proprietary software shall only be accepted in cases in which:

    • there is no open solution that fulfils the necessary requirements;

    • the adaptation of an existing solution in order to fulfil the requirements is not viable, and

    • the construction of a new solution, to be deployed under an open licence, is not viable.

    For the purposes of this paragraph and the preceding paragraph, whether a solution is not viable shall depend on technical reasons or the necessary resources, or because the increase in the period of time in which the solution will be made available prevents the success of the project.

  3. The process for establishing whether the aforementioned exception is applicable is set out below in the section called “Preparation and preliminary designs”.

  4. In cases in which, pursuant to the aforementioned exceptional circumstances, it is not possible to propose a completely open overall solution, preference will be given to an architecture and a selection of components with minimal dependencies on closed source elements.
Freeing software

Both internal and external digital service projects for development of digital services must be developed from the beginning with a view to their freeing, following the best free software development practices, and based on open technologies that allow for the final product to be released. Documentation, design and other elements (sounds, fonts, etc.) shall also be published under open licences.

  1. The commitment to publishing software projects that are being developed, whether internally or outsourced, means that quality standards and common development practices used in free software projects must be taken in account from the beginning in order to safeguard success. A number of the elements to be included in the procurement specifications to safeguard these requirements are set out in the “Projects” sub-paragraph below.

  2. Furthermore, to avoid obstacles when freeing software, the use of closed source subcomponents and reliance on closed development, administration and monitoring platforms and tools must be avoided, following the other recommendations in this document (see “Development” sub-paragraph in particular).

  3. The IMI has established and shall maintain a free software release and migration plan, the roll out of which will facilitate the progressive implementation of best practices in the development and use of open technologies in the City Council’s digital service projects.

  4. The criteria to be followed to evaluate the release of a project include: that the product responds to a general need (and not a specific need of Barcelona City Council), that it compares favourably in some aspects with other existing free projects that resolve the same problem, that the City Council is able to do it legitimately in terms of third party rights, that the product can be run on free platforms and that it has sufficient technical quality and the documentation required to be used by third parties.
Reuse

Software acquisition will provide incentives for reusing existing solutions. Development projects in which the City Council participates will attempt, on top of being released under free software licences, to offer technical and organisational facilities for their reuse by third parties. Where software owned by the City Council and its associated entities cannot be released under a free software licence (for technical or legal reasons), it will be made available to other administrations without the need for any valuable consideration or agreement, in accordance with applicable regulations

  1. Whenever possible, and following prior research, projects shall reuse or extend existing free tools in order to reduce maintenance costs and reinforce open ecosystems, before contemplating the creation of similar alternatives. In some cases, this will make it possible to reduce development costs and, in any case, promotes the strengthening of open ecosystems, the reduction of maintenance costs and the construction of better quality and more durable solutions.

  2. Priority shall be given to reusing free technologies and components that are already being used by the City Council. As a result, costs can be reduced and consistency guaranteed in terms of user experience.

  3. To facilitate the reuse of the code produced, it shall be published by the City Council using means including:

    • A project directory containing the City Council’s main projects, with links to the code’s repository, even when this is located on another platform, and to all the elements relating to projects’ development and governance. This directory can be consulted online at https://ajuntamentdebarcelona.github.io.

    • A centralised code repository (as described under “Development” sub-paragraph).

  4. Bear in mind that the regulations in force (Law 40/2015, Art. 157-158) require systems owned by public administrations to be made available to other administrations that may request them, under the conditions set out therein.
Sharing or pooling projects

When appropriate, the possibility of collaborating with other public administrations and entities in the development of technological projects of interest shall be considered, with a view to sharing costs and promoting interoperability.

  1. Pooling projects close cooperation between municipal governments and other administrations or entities in order to jointly develop tools for everyone’s benefit.[1] Participants share needs and specifications, costs, economic resources and development teams, in addition to the code that is developed.

  2. To encourage the pooling of projects, the Localret network of towns and cities may be used, in addition to other national or international networks.

  3. To share the required information with other administrations and entities to promote pooling, the City Council shall periodically publish software acquisition plans (road maps) that set out the forecasts for software acquisition or development for the following months or years.

PROJECTS

The use of free software and the corresponding open technology and development methods has specific implications in terms of the preparation and management of digital service projects.

Preliminary projects (for example, initial designs of a system to be built) are a key piece in the IMI’s public procurement and acquisition process. Their reports must always include options based on open technologies.

These principles are structured around the following guidelines:

Preparation and preliminary projects

During contract preparation phase, it must be demonstrated that exhaustive research has been undertaken in terms of possible existing reusable solutions, both nationally and in international public repositories.

  1. The preparation phase shall study the market and establish the technological specifications and, as applicable, the technologies recommended for future municipal development or implementation projects. This preparatory work often is carried out through a preliminary project.

  2. Alternatives must be sought in at least the following free software repositories: GitHub, SourceForge, JoinUp and the Technology Transfer Centre, pursuant to the provisions of Royal Decree 4/2010 and Law 40/2015.

  3. In the event that solutions based on proprietary software are proposed, it must be demonstrated that they fulfil the exceptional conditions set out under “Acquisition” subparagraph above, and that therefore the use of the proprietary software is the only viable option. Therefore, the preliminary design must include a specific report that:

    • Demonstrates the quality and rigour of the research undertaken on free software based solutions. The preliminary project contract itself may mention any of the alternatives that must be studied if the IMI is aware of them.

    • Demonstrates how the option of building new solutions has been assessed, including an estimate of their cost.

    • Includes a simulation of the requirements that call for the use of proprietary software and the requirements or functions that would have to be rejected in order to build an alternative solution without using proprietary software.

    • Specify the possible impact on the interoperability of the system with other systems and platforms and the possible vendor lock-in that may occur as a result. Actions to mitigate these impacts must also be proposed.

    • In the event that a proposed solution using proprietary software imposes any type of restriction on the construction or evolution of other information systems or technical platforms using free solutions, this report justifying the use of proprietary software must include all possible repercussions.

  4. Work will be carried out to establish a committee of free technology experts who can advise on the design and assessment of the preliminary projects and also offer assistance, if proprietary technologies are proposed, for determining the admissibility of the alleged exceptional circumstances.

  5. Preliminary projects must assess the maturity, maintenance conditions and expected sustainability of the proposed software components[2]. In future, the IMI may make teams and resources available to projects in order to provide assistance with this undertaking.

  6. An important function of the preparatory phase, when free projects are preselected for expansion or adaptation, is researching the legal and technical requirements to participate in these projects. To this end, contacts can be made with the maintainers and the legal owners of these projects, in addition to noteworthy developers thereof. The result of this phase shall include a description of the obligations resulting from these requirements, to be included in the procurement contract specifications.

  7. In terms of projects that are subject to harmonised regime, it must be demonstrated that the search for reusable solutions to be deployed has been undertaken at EU level.

2. For example, following the Open Preservation Foundation model, available online at http://openpreservation.org/technology/principles/software-maturity
Technical and functional specifications

The proposed projects must not include any specification that prevents the proposal of solutions based on open technologies nor name specific products or providers, unless on the grounds of compatibility with existing technologies, subject to the criteria set out in this Technological sovereignty guide. The architecture, interoperability requirements and the right and capacity to modify and reuse the software of systems and services shall be considered technical characteristics and requirements.

  1. Development based on free software will not be achieved by simply mentioning this term, but by means of clarity in functional, technical and legal requirements that enables and even promotes the use of open technologies.

  2. Technical requirements that require specific solutions shall be avoided, particularly where they may not even be necessary following a more detailed analysis of the underlying requirements.

  3. Whenever possible, tender specifications shall include detailed functional and technical specifications of the system to be developed or acquired. This does not mean that during the development phase, applying agile and iterative methodologies, these specifications cannot be refined, improved or adapted when mutually agreed with the internal customer.

  4. Generally speaking, tender specifications for new solutions shall not name a product (and much less a provider) of specific software and, in all cases, must include the phrase “or equivalent”.

  5. An exception shall only be made (in other words, a specification of criteria that prevent free technologies from being offered or a reference to specific privative products) when it is required on the grounds of compatibility with existing technologies, the replacement of which requires more long-term planning (as set out in “Preparation and preliminary designs”).

  6. Notwithstanding the foregoing, compatibility with proprietary products procured in previous tenders shall not be considered a generally acceptable exception, given that this would promote reliance on a single provider and make it difficult to take impartial procurement decisions based exclusively on the City Council’s needs.

  7. In contrast, there is no restriction on mentioning specific freely licenced products in the tender specifications, as this would not create any reliance on any specific provider.
Cost calculations

All decisions on the acquisition of technologies shall consider the total cost of the system during its long-term service life (TCO, Total Cost of Ownership) including hidden costs (for example, exit costs when replacing technology in the future when formats or interfaces are not standard) in addition to the net benefits for society.

  1. The economic calculations must be specific to the project’s needs; however, the spill over effects (secondary costs and benefits) must also be considered, for example, through the reuse of technology by public administrations and the acquisition of internal skills.

  2. Hidden costs must be taken into consideration (for example, exit costs when implementing proprietary or non-standard solutions) in addition to encouraging the procurement of products that satisfy free standards and include an adequate level of interoperability moving forwards.

  3. Decisions must also take into consideration how to maximise the net economic and social benefits for the local economy and society in general, in the medium to long term.
Procurement of projects and services

Contracts for new projects or the expansion of existing projects shall contain standard clauses based on these principles, including for preliminary projects in which technologies are preselected, in addition to framework agreements and contracts in separate batches. These clauses shall require the use of solutions based on free technologies, with the exception of the special circumstances provided for under “Acquisition”.

  1. The IMI shall produce these standard clauses for the Technology Procurement Guide and include them in the form of an appendix.

  2. The clauses shall not include conditions that contradict the principles indicated herein, for example, a requirement to preserve the confidentiality of code published in a public repository (whether as free and open software or not).
Best development practices

The development of digital infrastructures and services shall comply with best practices applied in free software development methods, using by default the agile methods applied in the IMI.

  1. Source code shall be managed effectively using modern version control systems that enable contributions to be traced and external contributions to be managed simply, and support different branches (main branch, maintenance branch, specific branches for the development of functionalities) and project forking, as applicable.

  2. The City Council shall maintain its own organisational space on an online software project management and publication platform. This space shall contain a repository for each software project in which it has participated (whether directly or via contracts), even if the development is made on another platform or using another repository managed by another entity (in this case, the City Council’s space shall mirror the main repository).

  3. Projects undertaken by the City Council shall feature a public issue tracking system in which anybody can report bugs and follow their progress. The system will also allow contributions to be made and their integration to be tracked, in addition to enabling improvements or adaptations to be suggested.

  4. All code and comments must be in English. A troubleshooting forum will be available in English. Optionally, some projects may choose to establish platforms for participation in project development in which Spanish and Catalan are the preferred languages.

  5. Projects shall also have a continuous integration system that makes it possible to run batches of automated tests and that publishes the results.
Code and document maintenance

During the contract term, IT development service providers shall collaborate with the IMI to ensure that the code is available in adequate version control systems. Furthermore, all systems and services must be correctly documented for administrators, users and developers, including instructions required for installation, deployment and configuration of the service in free and open environments.

  1. Tender specifications shall establish the period and form in which the contractor is obliged to maintain and support the code .

  2. Contracts that include the operation and administration of a service shall establish that the code to be used must have been published previously in the project’s main repository in a branch dedicated to this end (which may be the main branch). The repository of free or freed projects shall be public.

  3. Bug reports and their resolution shall also be carried out in a visible and transparent manner, using the means set out under “Development”.

  4. All projects will have a specific versions policy defined in its repository or via a link (for example, SemVer).

  5. The public repository must include sufficient documentation to deploy or maintain the code (for example, a Readme file with a description of the project, the requirements for using the software, a reference to the installation instructions, the licence that is used, etc.).

  6. Tender specifications shall define the user documentation (including for managing the service) that must be provided by the contractor and its technical characteristics, languages, etc. This documentation will also be published and covered by a licence, which will be defined in the specifications, using CC0 or CC-BY-SA 3.0 by default.

  7. All files contained in the repository referring to documentation, including user documentation if it is featured in the code repository, shall be in English and be formatted in plain text or in a lightweight markup language, such as ReStructuredText.

A NEW RELATIONSHIP MODEL WITH PROVIDERS AND THE COMMUNITY

The city’s model for technological sovereignty seeks to prevent dependency on a single provider, which is also a key factor in increasing the capacity for innovation in public services. Wherever possible, the procurement of digital services must increase the diversity of providers.

The most innovative and effective free software projects require a community of stakeholders that is effectively managed, participating in and contributing towards the evolution and sustainability of the software. The IMI will follow community principles of sustainability, openness, transparency and participation.

Factors to be taken into account include the governance of the community and the technical management of these projects, including the approval of the code for its inclusion in the project and the definition of requirements and the corresponding roadmap. The diversity of contributions shall be encouraged, although for critical projects, the IMI shall retain effective control over technical developments financed using public funds.

These principles are structured around the following guidelines:

Collaboration with free software communities and other institutions.

Proposed projects shall study options for collaboration with technological and free software communities, in particular local communities. Collaboration with other interested entities and institutions shall be encouraged to promote social innovation and local technological products and skills.

  1. Tender specifications (projects and preliminary projects) may establish the existence and possibility of collaboration with a community of developers and users for the technologies to be selected as an assessment criterion.

  2. As part of the project’s implementation, cooperation with developer and user communities shall be promoted, in particular if they are local communities, via processes aimed at promoting the development and use of software, including seminars, conferences, technical meetings (hackfests, etc.) in addition to processes for community management and release management (see "External contributions").

  3. In addition to the standard channels of cooperation with open development communities (addressed under “Development”), for certain strategic projects, specific mechanisms aimed at local developer and user communities may also be mandatory. These may include online collaboration tools (forums, wikis, mailing lists) or presence based events (hackfests), and the main language may be either Spanish or Catalan.
Sustainability and governance

Projects that produce complete free and open systems or tools as a result of a development service promoted and financed by the City Council shall include a project sustainability and governance model. This model will include, in addition to other aspects, an idea of the definition of the community, support tools, communication and marketing activities, processes for accepting external contributions, intellectual property management and the sustainability of the tool beyond the City Council’s project.

  1. The definition of a project’s “community” may include: other City Councils and public administrations, specialist sectors such as Geodata or libraries, organisations or institutions related to the project’s technologies.

  2. The governance structure of the projects includes the definition of:

    • A policy on dependencies: who and how admissible dependencies are decided upon.

    • A contributions policy: who and how contributions included in the products are decided upon.

    • The relationships and management bodies shared with other entities such as companies or other public administrations.

    • A communication and marketing policy.

  3. For large-scale projects, adopting (or writing) a code of conduct (in English) is recommended, with a link from the project’s website and in the Readme file in the repository. This document serves to establish the rules of participation in the project’s online communication channels, in addition to the rules of contact for possible in-person events.
External contributions

Projects led or freed by the City Council shall encourage contributions from external stakeholders. Specific rules shall be established, adapted to each case, for the management of rights over these contributions, in order to ensure compliance with third party rights and applicable regulations.

  1. The recommendations in this section seek to achieve the following objectives for projects freed by the City Council:

    • To integrate as much as possible valuable, high-quality contributions insofar as possible (in terms of both code and bug fixes, etc. and documentation) coming from parties other than the City Council’s activities and those of its contractors.

    • To ensure that all contributions have sufficient technical quality.

    • To ensure the legal integrity of the contributions (ensuring that third party intellectual property is not included by mistake or incorrectly).

    • To prioritise contributions that favour achieving Barcelona City Council’s objectives or the objectives of other institutions sponsoring the project and, in any case, accept only those that do not hinder this process.

  2. For all projects that are freed, documents required to facilitate the development and deployment of the software by third parties must be included in project’s repository (in line with free project practices: for example, Readme, Install, Contributing, Roadmap files etc.).

  3. Contributions management shall include a protocol for contributions and management of the corresponding rights, in particular to ensure that third party intellectual property is not included by mistake or incorrectly.

  4. To ensure that the requirements for contributing code are strictly technical, bureaucratic barriers to contributions must be minimised. With this objective in mind, instructions shall be provided on project programming styles and standards and how to make contributions from a legal perspective (as explained under “Intellectual property” and “Legal management” below).

  5. To ensure that contributions are traceable and that fragments of code that may pose a legal risk can be eliminated, as the case may be, all contributions that are ultimately included in the product must be signed by a party authorised by project maintainers in accordance with the protocol for a Developers Certificate of Origin (DCO), as is the case for the Linux kernel and many other free projects.
Upstreaming and forwards compatibility

Projects that improve or transform an existing free software product, whether undertaken by City Council or provider staff shall, insofar as possible, contribute these improvements and upstream any corrections to the original project. Furthermore, projects shall guarantee, to the extent possible, forwards compatibility in such a manner that the software adapted for the Barcelona City Council minimises the number of potential update and maintenance problems.

  1. Upstreaming means making code contributions (developed by and on behalf of the City Council) to existing free projects, so that this code can be included in the trunk software and thus form part of the free project.

  2. The extra (short-term) costs corresponding to making these contributions to the original project (upstreaming) are justified by the fact that, that once changes have been made, the new functionalities or improvements are maintained by the entire community working on the project. Furthermore, this also ensures the quality of changes that are introduced and compatibility with future changes made by third parties.

  3. The commitment to upstreaming extensions or modifications made to free software projects is made concrete through the following conditions for implementing each relevant project:

    • Contractors shall comply with the quality criteria of the original project, including regarding coding standards.

    • Contractors will be responsible for making the modifications implemented available to the community following the channels and protocols described thereby.

    • Clauses on intellectual property and licensing will be established based on the expectations of the original project.

    • The developers contracted or subcontracted by the City Council must sign a contributor license agreement (CLA) or DCO with the the project managers, if so required.

  4. For free software projects that have a written code of conduct, it is recommended to specify clauses in the technical specifications that make it possible to penalise contractors who fail to comply.

FLEXIBLE INTELLECTUAL PROPERTY POLICY

With respect to intellectual property rights, the City Council contemplates both the traditional figure of assignment of rights in new developments to the City Council as well as the option of allowing providers to retain ownership of rights in the results, provided that they release the software under a free software licence. This promotes local industry and the reuse of resources.

As a general rule, the accumulation of intellectual property at the IMI shall be avoided and, where applicable, software and acquired solutions should be freed or their reuse permitted. Therefore, when appropriate, intellectual property rights in developments shall not be transferred in full to the IMI by providers or other contributors, so that these developments can be recycled for other projects, provided that the IMI can reuse, combine or modify the software generated and, if applicable, release it under a free software license.

To facilitate and speed up the deployment and reuse of applications, each technological project managed by the IMI shall establish a clear legal framework for managing intellectual and industrial property rights, the use of components under different licences and contributions to the project, clearly identifying the owner of the rights in the software and the scope and characteristics of any license or assignment of rights.

External contributions outside the scope of the supply or service contract will require a formal process to support rights management, whether under an agreement that assigns rights to the City Council, or in the form of the project licence or a contributor licence agreement (CLA) or a Developers Certificate of Origin (DCO), to ensure that third party intellectual property is not included by mistake.

Projects must use a centralised tool of the IMI to manage both the licences on generated software and those pertaining to components used in the development.

These principles are structured around the following guidelines:

Intellectual property rights in the software

The City Council’s projects will establish a legal framework for clearly defining and managing the intellectual property rights in software developments. Depending on the circumstances, the agreements will establish the selected ownership model, including the options of transferring rights to the City Council or the IMI, leaving the rights to the provider or transferring them to entities that manage the relevant code of the project, provided that they are made available under free software licence for released projects.

  1. Each project will define which individuals and organisations will retain ownership of the intellectual property rights in the software.

  2. As a general rule, the accumulation of intellectual property at the IMI shall be avoided. When intellectual property rights in the software developments are not transferred to the IMI, providers may retain them and have the capacity to recycle developments for other projects; however, in any case, the City Council must have the right to use, combine and modify the software generated and allow it to be freed or otherwise reused.

  3. In some cases, the IMI will want to retain effective control of technical developments financed using public funds. External contributions outside the scope of a supply contract will require a contributor licence agreement (CLA[3]) to be signed. Notwithstanding the foregoing, there are other options for correctly managing contributions (establishing a DCO[4] or contributions being made under the project licence or a more permissive licence).

  4. Regardless of the intellectual property policy, which may differ from one project to the next, the authorship of all contributors shall be reflected in an Authors file in the public repository.

3. See, for example, http://harmonyagreements.org/
4. DCO: Developers Certificate of Origin. For example: https://developercertificate.org/
Legal management of software development projects

Projects must establish processes and documentation for managing the legal aspects associated with intellectual property and software licences (in particular, for contributions and licences of components used as part of the development and other software dependencies, ensuring that all licences involved are compatible); to this end, best practices and standard tools or tools commonly used in the sector shall be employed to ensure the traceability and integrity of the code.

  1. Correct legal management will facilitate compliance with regulations and the rights of third parties during the project and thereafter.

  2. The specifications must ensure that the legal integrity of contributions made to the code repository is safeguarded, in other words, that at no time should code be included which is not the author’s or for which permission has not been granted for its use under the conditions required by the licence. A policy for signed commits should be used, for the assignment of rights or DCO.

  3. Contractors shall also be obliged to establish a full list of third-party components included in the project, notifying the IMI each time that a new software dependency is introduced in the project and analysing whether the new package on which the software depends has a free licence that is compatible with the rest of the project.

  4. The code repository must feature a Licence file with the full text of the licence to be used for the project. If the licence so requires, each code file shall specify the licence under which it is distributed and the individuals or entities that retain intellectual property rights (copyright notice).

  5. The use of standards and best practices such as SPDX and OpenChain will be encouraged to ensure greater transparency between suppliers and the City Council and compliance with the best legal practices in the sector.

  6. The IMI will appoint an individual responsible for managing the legal aspects of its projects with a view to ensuring compliance with legal obligations associated with the free licences and other legal topics (intellectual property, trademarks, governance of communities).
Licence for freeing software

Software produced within the framework of the City Council’s digital service projects, including the software resulting from service agreements, shall be made public under a free software licence that complies with applicable regulations. The City Council shall establish the criteria and requirements for establishing the type of licence to use in each project.

  1. The licence chosen must comply with the requirements of Royal Decree 4/2010.

  2. The licence shall depend on the type of software development and how it has been created, using criteria including the degree of license permissiveness or reciprocity (copyleft), internal and external compatibility with other projects, licenses for software as a service platforms, etc.

  3. Insofar as possible, the City Council shall avoid the proliferation of licences, in such a way that a range of recommended and compatible licences will be created for the City Council’s technology infrastructure.

  4. When expanding or adapting existing free projects, the same licence shall be used.

  5. In other cases, the free licence to cover the project’s entire code may be established in advance as an condition of the contract (binding on the contractor).

  6. Tenders for new software development contracts may require a specific free software licence, or bidders may be given room to propose the licence that they wish to use, in recognition of the legitimate commercial and licensing policies that different suppliers may have (provided that they are free software licences). In any case, the criteria for selecting or evaluating licences as part of tenders shall bear in mind that the selected licence:

    • Must be on the Free Software Foundation or Open Source Initiative list of licences as “Free Software”. The creation of ad-hoc licences or the use of public domain licences is not recommended whatsoever. Nor is it recommended to use very rare or unknown licences.

    • The City Council must be protected in terms of the warranties and responsibilities relating to versions of the software that may be redistributed.

    • Licences that promote the integration and interaction of the project with its technological ecosystem (for example, for a Python component, choosing a licence common to the Python community) are recommended.

    • If all other conditions are the same, using a licence with copyleft is recommended (including “ASP/network copyleft” for distributed applications), as this is considered appropriate by Spanish law and serves to prevent a product developed with public funds from eventually becoming private.

  7. The IMI will have a team dedicated to assessing the legal aspects and licences of projects and establishing the obligations of each licence used.
Trademarks

If a trademark is registered to designate a software project freed by the City Council, the Council shall establish a public use policy that allows members of the community of users and developers to use it within the framework of the community’s activities.

  1. For projects to be freed, using a name that is identical or similar to existing free projects must be avoided as well as any already registered trademarks for products and services in the information technology sector.

  2. Trademarks serve to differentiate projects and prevent imitations or similar projects (including forks), that could exploit the reputation and efforts of the original project sponsored by or belonging to the City Council.

  3. The trademark use policy shal allow the community and third parties adopting or implementing the software to use the project trademark whilst restricting its commercial use by third parties in breach of the rules defined by the community and the City Council.