Opening your Software at Aalto University

Background

You most likely have heard about the benefits of sharing the code you have used in your analysis: results are reproducible and can be verified by other scientists, transparency of the process allows for improvements as well as identifying “bugs” in past code, others are able to re-use your code (and cite it!). For further motivation and examples here are a couple of references: “Top Ten Reasons To Not Share Your Code (and why you should anyway)”, “Ten simple rules for writing and sharing computational analyses in Jupyter Notebooks” 

Can the code be opened?

First off, you need to evaluate if there is any reason to not open source.  In practice, the principal investigator should know the answer to these questions (but can always consult with support staff for advice).  Reasons include

• Privacy and personal data (do not open if data contains personal data) 
• Contractual obligations (do not open if against agreements)
• Commercialization intent (commercializing is not necessarily opposed to opening, and opening can sometimes support commercializing.  Consult with Innovation Services to find what is right for you if you want to do both.)
• Unknown/mixed ownership.  If there are multiple persons as owners, all must agree to the license.  If you have reused other work with an incompatible license, you are out of luck.
• Department policies: assume allowed unless you actively know otherwise
• You don't want to (yet).  For example, you may wait until work is concluded.  In this case, it is still best to agree to a license and opening date in advance.

Decide on opening: who is the owner?

The owners have to agree to open, but who are the owners? 

You probably know that your employer usually owns your work. This is also true in universities in Finland, but perhaps you didn't know that for academic staff, this is mainly true for externally funded research.

If work is owned by Aalto, decisions about commercialization are primarily made by the head of unit (e.g. department head).  For practical purposes, decisions of open-sourcing are delegated to the principal investigator of a research group (but ask your unit head!).

Sometimes, outputs are owned by the one who did the work.  For example, this applies to non-employee students, and most interestingly researchers doing research not funded by an external source.  If you have non-Aalto collaborators, they will somehow own the Intellectual Property (IP).

Beware of the danger of split IP: start early and decide on licensing and ownership, because it is much harder to change this later.  "Intellectual property ownership" is not ownership, it's a right to prevent others from using a work in a certain way.  Don't end up in a case where no one can do anything.

For patentable inventions (novel, technological non-obvious inventions), Finnish law requires that a disclosure be made to the university.  This doesn't cover most of what would be considered "open science" (publications, software, data): if you have any questions, get in contact with an innovation advisor and they can help you, with no pressure to do something you don't want to do.

However, instead of spending time trying to figure out exactly who owns the work, it's simpler for all authors and supervisors to agree on the principles of opening: This is most in the academic spirit. If there is some disagreement on the license or principles of opening, we recommend that you contact Research Services to work out the IPR ownership and establish who has the formal authority to make the decision.

Open it!

Declare the license in the project itself. The minimum is a note clearly stating the authors (owners) and license. To be most formal, there would be a header in every single file stating this same information. In practice, that is too much work relative to the benefit – you can do that if you want to formalise well, but if someone needs further clarification, they can contact you to do this work.  A typical copyright declaration could be:

    Copyright YYYY [Affiliation, Author]
    [License text, chose from Licenses & Standards | Open Source Initiative for software and When we share, everyone wins - Creative Commons license or waiver]

For license recommendations, MIT license is good for general software that should be as open and reusable as possible.  The GPL license is good for software that you may want to commercialise, but consult Innovation Services first if you are serious.  CC-BY is good for data.

Make it part of the community

Opening is just the first step in making sure that others will find and re-use your code.  To get the most value out of this, you should use the best standards of community projects, if it suits your interests.  For example, software could be put on GitHub so that others can contribute to it.  Datasets should be put in a standard repository so that they can be found and properties searched with metadata. You should let others know what you have done and provide a way to make your software citable following the FAIR principles. If you want to learn more about these issues, you can read the FAIR4RS report “FAIR Principles for Research Software”.

Are you unsure how to proceed? Do you need practical help with your research software? Our Aalto Research Software Engineers are happy to help to guide you through the steps for making your code open and can also take care of the practicalities.