The University’s open-source code principles support transparent software development

The IT Center released the University’s new open-source code principles at the end of 2022. This article answers questions about what open-source code principles and openness mean, to whom the principles apply and where you can find more detailed guidance and information on their application.

(Tämä artikkeli on saatavissa myös suomeksi.)

Text: Tiina Silvonen, Petteri Hemmilä and Jukka Karvonen (Center for Information Technology, University of Helsinki)

The concept of openness is not a novel idea, as the University has long preferred open-source code. The University’s new open-source code principles formulate the openness policy into a clearly understandable form, making it easier to communicate about.

Benefits of open-source code

Openness is a strategic choice for the University, which brings benefits such as:

Sense of community

One of the most significant benefits of openness is the sense of community and collaboration, which can only be realised through openness. In open-source code, everything is transparent, which makes it possible to find out how the program works, how information is processed and how the functionalities have changed over time.

Quality

Better quality is often regarded as one of the most significant benefits of open-source code. Since open-source software is developed in cooperation, the code is checked by several collaborators. Developers also want to ensure the high quality of openly published material, as the published code is part of their public résumé. Therefore, the material’s language, structure and comments are usually prepared with special care.

Agility

Open-source code enables agile software development, where new features are created when needed and in a timely manner. Anyone can modify open-source code at any time, which supports agile development. If the organization uses closed source code produced outside the organization, the desired changes must be ordered separately, which is usually not very agile.

Avoiding supplier dependency

All the features and functions of the open-source code are openly visible. If an open-source product does not have the features you want, you can develop the software in your preferred direction. Sometimes closed-source software means supplier dependency, as only one party can develop the product. Open solutions reduce this risk.

Cost-effectiveness

The use of open-source applications is often cost-effective. However, openness should not be perceived as free of charge – although you avoid paying license fees by using open-source applications, their use still requires expertise and resources.

Supporting applications or components that are important to your operations is profitable, even if it is not mandatory. Many open-source applications are developed with the support of the community – this support may be financial or even a contribution of human resources. Broader participation often enables the promotion of functionalities important to your operations and reduces supplier risk when your organization has good application know-how.

Coordination of the developer community can take significant resources from the main developers. Requests for developments and bug reports require responses, and it is also necessary to review the possible contributions of others and assess them against the application’s objectives and architecture.

Challenges

The use of open-source code also poses challenges:

  • Open-source code usually has no guarantees.
  • The user can try to find out how active the community is behind the open-source product, but even this does not guarantee active development in the long run.
  • Open-source code does not always mean good quality source code. The code may contain errors, and the vulnerabilities are quickly known to the public. Open-source products may not have support services available.
  • There are risks involved in all activities, and open-source code is no exception. Risks must be identified and preparations must be made.

Why should I use open-source code in my small application?

It is almost always worthwhile to open your application’s code, and openness should be seen as a standard practice. Even if the potential benefit of your application for others is small, it is good to remember that the benefits of co-creation can only be achieved through openness. The software may contain technical components that can be generally utilized.

As a public organization, we also want to act transparently. It is important that developers utilize open-source code produced by others and also participate in the development of open source code produced elsewhere.

It is almost always worthwhile to open your application’s code, and openness should be seen as a standard practice. Even if the potential benefit of your application for others is small, it is good to remember that the benefits of co-creation can only be achieved through openness.

Open-source code licensing

If a self-developed product attracts interest and its developer base expands, development usually accelerates. It may be difficult to prevent further commercial use of your own code, but with the right license selection, the code and product can remain open.

A license is a document that describes how a program can be published and used. There are two main types of open license – copyleft and permissive. These licenses differ fundamentally from one another in that the copyleft license contains more restrictions. Copyleft – i.e. a strong obligation of reciprocity – means that the license must be published with the original license when it is redistributed (e.g. modifications or copies), but also when new components are added to the program by linking. The most common copyleft license is the GPL.

The University of Helsinki’s open-source code policy is based on the source code being published openly and its further use is not unnecessarily restricted. For this reason, the recommended license is the MIT License, which is a permissive license with simple and clear license terms.

The MIT license was developed by the Massachusetts Institute of Technology (MIT). The MIT license obligates you to keep the original license text and copyright statement with the application when distributing it, but otherwise gives you full rights to make copies and modify the source code. Programs released under the MIT License may continue to be licensed under other licenses. For example, software released under the MIT License can be attached to software released under the GPL license and used under the GPL license. Software released under the GPL license cannot be redistributed under the MIT License.

Dual licensing can also be used for open-source products. In this case, the open-source product is also released under a commercial license, which allows, against license fees, the product to be modified and distributed without publishing the modified code.

Publication of open-source code and application guidelines of the University of Helsinki

Open-source code must be openly available to others. The easiest way to publish code is in the GitHub version management system, a well-established open-source code publishing platform. We recommended that code is published so that everyone understands that its publisher is the University of Helsinki. Instructions for publishing code can be found in the instructions for applying the open source approach maintained by the IT Center.

The application guidelines also indicate when it is justified to deviate from openness. If the developed software is part of a critical infrastructure or is used to process confidential information, it is important to ensure that the openness of the source code does not pose a threat to information security or data protection. Qualitative reasons may also prevent the code from being published.

Openness of the code should be discussed in every software development project. Topics may include, for example:

  • Can we release our source code?
  • What is the quality of our software?
  • What are the risks associated with openness?
  • What benefits can be achieved?

The project team should reach an understanding of the risks and benefits of openness. We are happy to provide advice and tips on the subject at: versionhallinta@helsinki.fi.


Tiina Silvonen works as Team Lead for the University of Helsinki IT Center’s Software Development team.

Petteri Hemmilä is an IT Manager for the University of Helsinki IT Center’s IT Solutions unit.

Jukka Karvonen works as an IT Specialist in the University of Helsinki IT Center’s Identity and Access Management team.