License compliance for off-the-shelf free/open source software components

By Daniel M. Germán

Associate Editor: Stefano Zacchiroli

One of the major accomplishments of Free and Open Source Software (FOSS) has been the materialization of the ideas behind component-off-the-shelf (COTS) software engineering. COTS encouraged reuse: any time developers would need certain functionality, they would integrate ready-to-use components that implement the desired functionality. There exist innumerable FOSS components. Today, a necessary skill for any software developer is to be able to find, select and integrate FOSS components to reuse.

FOSS components are usually available for download at zero cost. Many of them are highly reliable and are widely used in the industry. One of the best examples is OpenSSL. As reported by the Guardian daily: "There is a very high chance that at least one service that you use [uses OpenSSL]" [1].

While FOSS components are likely to be free (as in gratis) to download, they do have a cost when the final product in which they are integrated is distributed ("shipped" to the customer, so to speak). This cost is compliance with the license under which the component is being made available. There exist many different FOSS licenses, but each of these licenses have several important characteristics in common: the source code must be made available, the code should be allowed to be modified, and perhaps the most important of all, the source code (including modifications) should be redistributable in either source code and/or binary form. Each FOSS license can also set a series of conditions that must be satisfied before the right to such redistribution is granted.

Therefore, when a developer is planning to reuse a given FOSS component, the second and third questions should be, "what is its license?" and "is this license compatible with the license of the product where it is being integrated?" (the first, of course, is: "does it do what is needed"?). For example, the license of OpenSSL has only one major condition: it requires an acknowledgment: "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising materials and redistributions. This condition might be impossible to satisfy by some; for example, software licensed under the GPL-2.0 or GPL-3.0 cannot satisfy it, and hence, cannot use the library.

Identifying the license of a component is not always easy, primarily because there is no agreed format to document it. SPDX (Software Package Data Exchange), a consortium of organizations, for- and non-for-profit has been working towards the creation of a standardized format for documenting licensing information, including the standardization of the names of the licenses, and tools to maintain this information.

Answering the question "is this license compatible with the license of the product where it is being integrated?" is not always an easy question to answer. Whether a system can reuse software under a given license is affected by the architecture of the system, the way the component is connected to the rest of the system, and how the component is redistributed.

In a survey, Soler and Henkel found that developers do not usually have the training to understand software licenses nor their impact [2]. I am not advocating that they should be legal experts, but rather, that they should be able to identify potential issues and, when necessary, ask for help. Ideally, any organization that creates and distributes software should have a license compliance team that is responsible for approving the reuse of external components (including FOSS), and to assess that—when a product is released—all the necessary requirements of the licenses of the reused components are satisfied.

FOSS is an enormous resource, and the Internet makes it easy to search and find suitable FOSS components. The real challenge is to properly reuse FOSS by satisfying the requirements of its licenses.

Further reading

• Bain [3], describes, from a legal point of view, the difficulties and challenges of integrating components licensed under the GPL with other licenses.
• For more information about SPDX, please visit https://spdx.org/
• In [4] we describe the challenges of license identification in FOSS.
• In [5] we describe the problem of license mismatch when reusing FOSS components and different methods to address it.

References

• [1] Samuel Gibbs, "Heartbleedbug: what do you actually need to do to stay secure?", The Guardian, April 10, 2014. 
• [2] Malcolm Bain. "Software interactions and the GPL", International Free and Open Source Software Law Review, 2(2), 2011.
• [3] Manuel Sojer and Joachim Henkel. "License risks from ad hoc reuse of code from the internet." Communications of the ACM, 54(12):74–81, December 2011.
• [4] Daniel M. German, Yuki Manabe, Katsuro Inoue. (2010). "A sentence-matching method for automatic license identification of source code files". ASE 2010, 25th IEEE/ACM International Conference on Automated Software Engineering, Antwerp, Belgium, September 20-24, 2010. ACM 2010
• [5] Daniel M. German, Ahmed E. Hassan. (2009). "License integration patterns: Addressing license mismatches in component-based development". Proceedings 31st. International Conference on Software Engineering, ICSE 2009. 31st International Conference on Software Engineering (ICSE 2009), Vancouver, Italy, 2009-05-16 (188--198)