Task and motivation
Smart Government, Smart City, the Digital City – these buzzwords describe IT systems developed to provide citizens with modern information services.
This article aims to raise awareness of an issue that largely goes unnoticed, or at least is not always handled professionally. Both clients (AG) and contractors (AN) have relevant challenges in this environment.
Risk & background
A client purchases a software system. However, there is often no clarity about future cost risks.
Today’s software is expected to be modern – and it is. New companies enter the market and present convincing products. Developers are inventive and efficient: they do not write every line of code themselves but use the libraries available on the internet in huge quantities. That means: software developers integrate (often independently) open source components to solve their tasks.
“Open source” suggests to many: open, freely usable code for everyone. Stop: open-source software has authors – and those authors have rights. The question is: What rights have the authors defined in detail?
Can companies (software vendors & users) only use the software, or also modify it? To what extent? And which rights apply to which release?
Examples of open-source license terms
Many different license models exist. Two typical examples:
- Request to contribute modified code back to the original developer.
- Free use only for non-commercial applications.
Scenario from practice
A software vendor uses open source as a library to develop its own products. A typical base-platform release change is pending, e.g., Windows release xyz. This release closes security gaps; the previous one will (at some point) be discontinued.
The used open-source library no longer works in some areas, so the vendor must switch to a new release as well. For this new release, the author suddenly charges a fee.
What does the software vendor (AN) do? It must pass costs on to its customer – the client (AG) – increase maintenance fees, or absorb the extra costs and run into economic problems. Every scenario ultimately leads to higher costs for the client.
Fact check
The system vendor (AN)
Insiders know: today, almost every company – including traditional providers – uses open source. Sometimes even without an exact, up-to-date overview of all components and their usage terms. There is an urgent need to catch up here.
The client (AG)
Does the client request from the supplier a list of the open-source components used and the associated rights? Does the AG actually want to read foreign-language license texts? Can the AG assess what this means long-term in terms of cost and maintainability?
Or does the AG request a risk assessment of potential additional costs from the AN? In practice: No – this is usually not included in tenders.
Systematics of FOSS licenses
Free and Open Source Software (FOSS) may be used according to the authors’ intent if the individual license terms are complied with. A programmer can decide: “I programmed something, and whoever uses it must follow my conditions.”
Anyone using the program without observing these conditions has no right to use it, must cease use, and may trigger further legal consequences.
From a practical perspective, three broad groups can be distinguished:
- Dangerous (legally risky / strong binding).
- Not dangerous, but associated with administrative effort.
- Harmless (few restrictions).
Decisive are the copyleft effect and the complexity of the rules. Copyleft, in short, means: if you use my software and permanently link it with other software, that other software must also be subject to my license terms.
Examples:
- Strong copyleft: e.g., GPL2, GPL3, AGPL.
- Weak copyleft: e.g., LGPL, Apache.
- No copyleft effect: e.g., MIT, BSD.
From practice it can be said: FOSS with long, clear license texts (e.g., GPL) is often less risky than FOSS with very short, vague terms of use (e.g., BSD), because obligations are described more clearly. (Note: this is a pragmatic view; legal assessment can vary case by case.)
Responsibilities of AN and AG
Which license terms must be observed in detail can only be clarified in coordination with the supplier. The supplier must run internal compliance with the developers.
At least two tasks follow from this:
- The system vendor (AN) documents which software components are contained in the solution – including all open-source components.
- The client (AG) derives, based on the legal conditions, the processes that must be complied with.
In addition, the contract should regulate:
- Who is responsible for complying with obligations from the FOSS licenses? Many lawyers primarily see the user (AG) as responsible.
- Who is responsible for ensuring the customer knows what to do and complies with these rules? Many arguments support the view that the IT company (AN) must take on this role.
Facing reality
If we want to use modern, affordable software, we have to ask: Who actually makes a living from what in this chain?
Are these all “nerds” who can live without money? Or are they intelligent, communicative people who develop business models with business consultants? At the latest in the next version, the client pays – often without the license models having been discussed transparently beforehand.
Conclusion
Everything has its price. For solutions used long-term, the maintenance budget should include security buffers in line with the share of open source.
At the very least, suppliers should be required to systematically work through their own risks. This can and must be part of the requirements specification (tender) today.
For strategic applications, additional contracts should be concluded that establish clear obligations down to the source code. Templates such as EVB-IT do not, in the view of many practitioners, sufficiently address this problem.
The basis is clean documentation of all open-source libraries at the supplier and a license/legal evaluation or cost-risk assessment from the client’s perspective.
Further development of the topic
For more complex IT solutions, a structured approach to open-source licenses can help relieve planned costs by involving usage partners. Example: a city could offer an IT solution to other cities and thus achieve refinancing.
Which rights must exist or be acquired to set up this refinancing sustainably? How must the supplier be involved so that, from the client’s point of view, lifecycle costs remain planable?
There are models to remain largely in control. What matters is choosing a long-term viable model that gives providers room to react, while ensuring the client conducts a sound analysis of the problem and integrates it cleanly into cost planning.
