Use of Open-Source Software in Proprietary Software Products – Part 1

 
 

Most software manufacturers and SaaS providers have been extensively using open-source software components in the production of their proprietary software products for years.

However, this often leads to a need for consultation, especially when customers suddenly demand extensive guarantees, liability provisions, and indemnification clauses for the use of open-source software in license agreements.

“Can I contractually ensure that all the open-source software components I use are suitable for the proper functioning of my software product?” “What are the implications if the customer requests an unlimited indemnification on first demand or the right to have proprietary software modifications that I would need to acquire?”

Using open-source software entails various risks that should be considered and addressed during the development of the solution. Only by doing so can one confidently compete in the market and meet the contractual requirements of customers.

A short refresher from practical experience:

(1) License verification: It is essential to ensure that the license terms of the used open-source software are carefully examined and understood. There are different types of licenses with various legal requirements and obligations. Failure to comply with license requirements or incorrectly applying them during the integration of third-party components can lead to claims for non-compliance. The license requirements can also extend to proprietary software, potentially requiring disclosure of its source code (known as the “copyleft effect”).

(2) Documentation: Maintaining comprehensive documentation of all used open-source components in the product is crucial. This documentation should include the names of the components, their versions, associated licenses, and sources. Often, licenses require this documentation to be made publicly available or even delivered to the customer with the software. Failing to do so may result in license violations.

(3) Copyright notices: Many licenses require that license notices of the open-source software must not be removed or altered. They should remain clearly visible in the overall proprietary product.

(4) License compatibility: Some licenses of the used open-source software may be incompatible with each other. For example, conflicts may arise between the Apache License and the GPL v. 2.0. If a software manufacturer uses incompatible components together, incorporating them into the overall product constitutes a copyright infringement.

(5) Distribution and modifications: Certain open-source licenses impose specific conditions on the distribution and modifications of the respective libraries. These conditions must be observed and implemented.

(6) Risk mitigation through contracts: To address legal risks that may arise from the developer community, contractual agreements with developers or the open-source community should be made, clearly regulating the use, liability, and warranties, known as “contribution agreements.”

(7) Software audits: Regular software audits are recommended to ensure that only legally compliant open-source software is used in products and that no unauthorized components are included. Software tools that crawl the source code and provide support and compliance functions are useful for this purpose.

(8) Open-Source policies: We recommend creating internal policies for dealing with open-source software to ensure that all employees adhere to the relevant provisions.

(9) Regular updates: Keeping deployed open-source components up-to-date is essential to benefit from bug fixes and security updates.

(10) Legal advice: When necessary, seeking legal advice from specialized attorneys familiar with open-source licensing and legal aspects is advisable.

(11) ISO/IEC 5230: Open Source Compliance is now even covered by a specific ISO certification (ISO/IEC 5230). For companies that extensively work with open-source software and have a significant portion of their proprietary products based on open-source software, considering this ISO certification may be recommended.

 
Previous
Previous

Use of Open-Source Software in Proprietary Software Products – Part 2

Next
Next

Legal Issues in Digital Transformation Projects