Skip to Main Content
It looks like you're using Internet Explorer 11 or older. This website works best with modern browsers such as the latest versions of Chrome, Firefox, Safari, and Edge. If you continue with this browser, you may see unexpected results.

Research Data Management: Open source software and code

General information on open source software

Open source is a way to develop and share software. The open source model of software development makes both ideas and products available for everyone to see and utilize within the boundaries set by certain licensing models. Private persons and companies (end users) can take part in the development process, which helps in finding and fixing programming errors. This collaboration often results in good data security, high software quality and interoperability. Different licensing models determine how licensed software can be distributed and combined.

Two main rules when choosing your license

  1. If you continue developing an existing open source project, use the license used by original program. It may be mandatory, and in any case it is almost always reasonable.
  2. If you start from scratch, select some already used license like MIT, GPL or BSD. In particular do not make restriction for using the program to some specific mean, because those restrictions usually make it impossible to integrate you code as a part to some bigger program.

Source code licensing

Open source code must be properly licensed. The independent commercialization of the software may be the basis for the choice of license. When choosing the license, other case-specific needs must also be taken into account. You should discuss your choice of licence with your supervisor, the Head of Laboratory, or Innovation Services

We recommend the following three licensing models depending on the situation:
  1. MIT license is the most open of the recommended options. MIT licensed source code can be used freely. The MIT license is especially suitable for software that is not connected to any specific commercial interests.
  2. GNU General Public License (GPL) gives anyone the right to use, copy, change, and distribute the software and their source code. GPL licensing also guarantees that these rights are retained with regard to the new and modified software based on GPL licensed source code. This makes GPL a copy left license. Please note that there is also GNU Lesser General Public License (LGPL), which, unlike GPL, doesn't require other projects with parts of the code to be similarly licensed.
  3. Dual licensing is utilized in cases where the goal is to sell commercial licenses in addition to distributing research licenses. It is important that all of the software authors have agreed, that the software may be released initially under multiple licenses. In these cases, a license for this specific use is compiled together with university's legal services. In addition, Tampere University lawyers are intended to predominantly lend their licensing support in cases concerning commercially significant projects and to research groups seeking outside funding.
    Read more about dual licensing: Publishing and commercialisation – Can I have both? - Aalto University

All aforementioned licenses include a limitation of liability, ensuring that the copyright holder and software developer are not liable for the use of the licensed material.

Please remember!

  • The license must be included with every software code file and in the metadata. The license can be included as a separate LICENSE.txt file, or it can be copied into another suitable text file, such as a README.txt file. Please make sure that the license has the correct year and owner.
  • It is also important to determine the owner of the code before distribution. The owner of the source code is determined by the conditions it was created in. Ownership is decided based on relevant legislature, the funding used, the creator’s position, and the background of the users contributing to the code. Ownership may therefore lie with the creator or creators, Tampere higher education community, the sponsor, or any combination of these.

Other open source licensing options are described at the Open Source Initiative website. GitHub’s Choose a License page reviews the differences between the different licenses. More information on choosing an alternative license is available at the Free Software Foundation website. However, it is important to note that Creative Commons licenses are not suitable for source code.

Read more about the differences in open source licenses.

Other licensing options

  • BSD Unix license which is originally published by the University of California in Berkeley.
  • Apache-2.0.

Sticky and permissive licenses

Open licenses can be roughly divided to two classes: sticky and non-sticky. In both cases everyone is free to use and copy the original program, the difference lies in continuing development.

  1. Being sticky means that those continuing development must use the same license. If the program A has the GPL-license (so that it can copied freely etc.), then derivative programs A¹ and A² must also be GPL-licensed (i.e. also those must be copyable freely etc).
  2. Being permissive means that someone can make closed version of the program for commercial use. If B is licensed as, for example, BSD, one can make a commersial version B¹. Of course nothing forbids others to make another version B², and that can have again BSD-license or maybe GPL-license; in the latter case all versions developed from B² must also have GPL-license.

Permissive license might interest corporations slightly more. Sticky license might attract slightly more independent developers.

In both cases there are no direct limitations for commercial use. A free program can be used in private business, and for example support services for the program can be sold. A corporation may also pay for developer to implement a specific feature.


Saving and sharing source code

code on a laptop

It is recommended that source code be shared and distributed where it is most appropriate, as determined by funding and other factors. 

The recommended venue for sharing open source code is GitHub. To make your GitHub repositories easier to reference in academic literature, you can issue a persistent identifier for your repository with Zenodo. If more appropriate, code can also be shared through the system used by the software the code contributions belong to.


Source code metadata

It is recommended that at least the metadata concerning the source code is saved on TUNICRIS. Please also take care that the source code is citable.

Make sure that the metadata includes, at the very least:

  • the name of the software or source code
  • its maker or makers
  • its publication date
  • its version number
  • preferably its web location
  • the license used. The location on the web can be marked with, for example, a URL address or a DOI identifier.

This metadata can be licensed, as well. recommends that metadata be published under the CC0 license.

Legal background

By the copyright act of Finland a computer program is an artwork having copyright just like a composition, poet etc. By the same law the copyright will remain -- unlike in private business -- to the writer to "computer program made by someone independently working on teaching or research at academy".

Hence an explicit contract is always needed if the copyrights are transferred to the university.

Contact us

Is there something you did not found in this guide? Or is some important information missing? You can always contact us for further information, and we will help you with the research data management.


P. 0294 520 900

Kirjaston kotisivut | Library homepage

Palaute | Feedback