18.05.2021 | Technical topic

Avoid license pitfalls in OSS compliance

Avoid license pitfalls in OSS compliance

Use open source software successfully

Thanks to Android, Qt, Flutter, Tensorflow and Co, OSS has found its way into many commercial projects. As developers, we think that's great, because these open projects can also make commercial product development faster and easier.

But with the great and easily available functionality of open source components also comes great responsibility. Stumbling blocks, such as open source compliance, must be considered in order to successfully get where you want to go.


Open source compliance is about whether the software components used are also used in accordance with their license. In simplified terms, there are two types of licenses:

    Permissive licenses
    CopyLeft licenses

With permissive licenses, the license can be used relatively easily in commercial software. In the case of the CoypLeft license, on the other hand, a clause is included in the copyright usage licenses. This obligates the licensee to place any adaptation of the work (for example extension and modification) under the license of the original work.

This means that the own software with CopyLeft is placed under the open source license, whether you want it or not. If you violate this, you can be sued for expensive money.

According to the Synopsis report on the proper use of open source licenses, 65% of the more than 1500 codebases have license conflicts!
However, if we look at the data of the last few years, we can see a trend towards improvement, albeit a subtle one.

Statistics: audit results regarding correct OSS licensing:

    2018: 68%
    2019: 67%
    2020: 65%

It is particularly interesting to note here that the proportion of license offenders is especially high in the Energy and Clean Tech sectors, as well as in Manufacturing, Industries and Robotics, at over 80%. Equally exciting is the point of sustainability and long-term support: 91% of the codebases examined had libraries that had not had a code change in the last two years. This means they have not been maintained and are therefore more vulnerable to vulnerabilities.

OSS more secure than closed source

###IMAGE8## A solution to these grievances is an (automatically) maintained Software Bill of Material. In addition to the software versions, it also makes the license types visible. This immediately identifies whether problematic CopyLeft software components are present, so that they can then be dealt with accordingly.

Basically, one can claim that OSS is more secure than so-called "closed source".

Freely after Eric Raymond, a well-known US software developer from the hacker and open source scene: "with many eyes looking at code, "all bugs become shallow"." Of course, this excludes unmaintained code from projects that may be discontinued. After all, 85% of all codebases had OSS components that had not been updated for four years or even longer.

GELin as a guarantee for secure products

Ginzinger electronic systems offers a simple solution for all three of the pitfalls described. With GELin, our own Linux operating system, we rely on active monitoring of the software components, on a stable and long-term maintained mainline Linux, and on an easy-to-create software BOM.

Thus, a project can be implemented quickly and without much effort. GELin is thus a guarantor for long-term successful and secure products.

The appropriate Ginzinger webinars about security and OSS can be found here

Link to the report: www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html

Translated with www.DeepL.com/Translator (free version)


Do you have questions

or want to get in touch?