Open-Source Software Policy

This Open-Source Software (OSS) policy applies to all publicly funded research activities that have as result the development of software.

Definitions

In the context of FMI OSS policy, Software is defined as a more complex entity comprising of more than simple scripts and files with clearly defined functionality and purpose.

In general, an open source software is defined as the software published under an open software license that guarantees end users the freedom to run, inspect, share, modify and enhance the software. A comprehensive definition of Open Source that includes 10 criteria can be found here. The most important of the 10 criteria are the free redistribution of the software, access to the source code, and the permission to allow modifications to the software and derived works that may be distributed under the same licensing conditions (as in same or compatible license).

Licensing is the action of a copyright owner allowing others to use a work under specified conditions.

Dependencies are articles of pre-existing software and hardware requirements that the software under discussion depends upon. Dependencies include for example operating systems, compilers, development environments, web servers and similar software needed to build and/or run the software.

Copyright

  • Copyright ownership of software and related work (diagrams, schemas, documentation, manuals, user interface and source code) must be recorded, and is vested with FMI.

  • Projects/groups/units must maintain an IPR register, listing all contributors to their software and, in case of external contributors, who owns the copyright on contributions. FMI recommends that this is managed via rigorous version control.

  • In case of joint projects with external contributors, the ownership of code and related materials which are to be developed must be established before work begins.

Licenses

  • In case of OSS, the licensing conditions are intended to facilitate continued reuse and wide availability of the software, in both commercial and non-commercial conditions. The FMI-approved licenses for software that does not use external components that ensure the above-mentioned criteria are available:

  1. MIT (strongly recommended)

  2. Apache License 2.0

  3. BSD 3-Clause “New” or “Revised” license

  • Software and related work (diagrams, schemas, documentation, manuals, user interface and source code) must be released under one of the above licenses, unless the contract with an external partner specifies differently.

  • The open source license of a software might depend on the eventual restrictions imposed by the use of external software, libraries, other components holding a certain IPR and used in its development. In this case the FMI legal team will issue advice.

Embargo time

  • FMI permits the possibility of embargo, i.e. working, development and publishing of the software before it is made open. If contractually allowed, this embargo period should be no longer than 2 years from the moment when each corresponding version of the software is developed and functional.

Dependencies

  • The projects should list, whenever possible, the dependencies the software under development has and state the licenses applicable to these dependencies. (this will allow the party interested in reusing the software to determine what software they should buy or license)

  • When possible and reasonable, OSS licensed dependencies must be used over the non-OSS licensed dependencies.

  • In case of software developments with external contributors, the FMI responsible person will ensure that all contributors follow the present policy. Special focus is laid on the fact that no libraries with conflicting licenses are introduced and the contribution does not include patent or other IPR violations. Where this is not obvious, the contributor licence agreemet (CLA) is required.

Documentation

  • All OSS-licensed software must be accompanied by explanatory documentation so that the software is understood by those not intimately involved in its creation.

  • All personal information in the documentation must be removed before making it publicly accessible.

Versions

  • Software should be developed from the start in version-controlled environments.

  • Each released software version will be assigned a version identifier as in unique name/number (either increment from 0-> infinity or a->z, following the form major.minor.bugfixes (e.g. 1.2.0) or date-based versioning).

  • All the software versions will be accompanied by proper documentation of the changes the software undertook (what, when, why).

  • All the intermediate versions will be retained and archived (see below)

  • Each version will be accompanied, whenever possible, by the same (or compatible, if needed, but not more restrictive) license as the previous version. If security, contractual, proprietary, or other strong reasons do not allow open source code license to be attached, a non-open source license can be used. In this case the FMI legal team will issue advice.

Archiving

  • To ensure long term preservation and maximum availability and reuse, the software and related work (diagrams, schemas, documentation, manuals, user interface and source code) must be archived in a repository.

  • FMI strongly recommends the FMI’s version control repository in Github, platform that offers convenient archive services for open-source projects’ outputs.

  • Other platforms may be used if they allow version control and are open to public. In case a publisher requires a different software repository, the requirement will supersede the present policy.