The industrial revolution continues - starting with the steam engines of the 18th century, continuing with large-scale steel production, oil exploitation, electrical and photographic innovations of the 19th century, and moving on to the transportation, communications, computation and electronics of the 20th century. It is still early in the 21st century, but we can safely say software has become the engine that feeds the industrial, economic, medical, and gradually the political issues of our existence. The only way to satisfy the demand for the volume and complexity of the software that is needed to keep our world moving is to maximally share and reuse code within and across application domains.

Open Source Software (OSS) is the epitome of code reuse, enabling complex applications to be realized rapidly, economically and safely. Probably the largest collaborative endeavor in human kind to date, open source feeds on itself. Independent studies have converged on the fact that open source is everywhere, and depending on the source of the study, 80-100% of all software organizations now use open source software in their products or operations.

There is an implicit understanding that good developers do not write code from scratch any more. Rather, they can adapt a piece of existing code to furnish a desired function. Use of off-the-shelf code such as OSS brings the usual due diligence and precautions associated with deployment of any third-party content within an organization. The pedigree of the code, its ownership attributes, and the rules around the use of open source code (typically captured in a license document) govern its introduction within an organization and its suitability for an end-target use.

Open source software brings with it an unusual set of ownership issues. Unlike other commodities, open source code can be brought into an organization freely. While anything that is purchased in a transaction has implied ownership, ownership and usage of OSS can be confusing to many developers or organizations. Generally, the copyright ownership of OSS always stays with the creator of the open source code. The OSS copyright owner creates and communicates a license that explicitly sets out the rules governing the use of that open source software.

Continuous Versus One-Time OSS Assessment
Detecting and complying with OSS code in a software project has become an important part of a quality and governance process in organizations that create or consume software.

Product quality considerations and standards require that a recorded knowledge of all the third-party components within a product be maintained at all times. These records should also include attributes such as pedigree, defect history and improvements over time, potential vulnerabilities, and code propagation within the organization. These records can be best maintained, not by a one-time examination of the organization's code portfolio, but through an ongoing and structured third-party and open source software adoption process. The practice of creating and updating the records automatically as development proceeds ensures ongoing compliance with the requirements of a quality organization.

As opposed to the continuous recordkeeping requirements of a quality process, a software audit is a one-time activity targeted at providing insight into the intellectual property (IP) ownership or IP rights, in anticipation of a transaction such as an M&A or a product shipment to market.

Open source software audits, generally carried out by an external body, involves an examination of a software portfolio in order to detect OSS and third-party code within that portfolio. The result of the audit is a report which highlights open source and third party components and their attributes. At a high level, statistics such as the names of any public-domain software packages and whether they are used in a modified or unmodified format, composition of the license mix, copyrights, vulnerabilities, languages, and open source lines of code are provided. At a more detailed level, specific open source or proprietary packages that were discovered, their license attributes, links to resources that contain additional information, text of the licenses, copyrights, and know security vulnerabilities associated with the components of the software are provided.

An audit process would highlight code that is specifically copyrighted, but for which no license is offered or mentioned. These cases are one of the challenging aspects in establishing IP ownership, as the copyright owner must be contacted for explicit permission to use their code. Also, any code that is not in the public domain and has no identifying information, such as headers, must be highlighted as requiring further investigation.

The Science: Detecting Third-Party Packages in a Portfolio
Once all OSS and other third-party packages are identified and a software Bill of Materials (BoM) is available, then the list can be examined for properties such as licenses, known deficiencies, security vulnerabilities, various obligations associated with their use, and functions such as encryption that could restrict its use in certain markets.

A number of methods can be used to identify open source and commercial software within a software portfolio. A short list of these methods will include the following.

• Records by developers: Any records maintained by developers and development managers will assist the process.
• Information held within a file, or folder: A quality-development practice is to include a header on every file that holds information about the software package, organization, copyright and license associated with the file or the package. Often binaries also include identifying information, such as copyright owner, project name, and the license pointers within the file. Another quality practice is to include licensing or other information about a software package within the package.
• File/folder names and paths: These could be additional indicators of the presence of a known public domain or commercial software.
• Similarity with public-domain software: Any similarity between a software file, or portions of a software file, and a file in public domain could accurately indicate the presence of OSS in a portfolio. A full-file code similarity to a public domain file would indicate unmodified use of the OSS software. A partial code match would indicate use of OSS in a modified form. This is significant because many open source licenses trigger different obligations based on how the file is used.

There are hundreds of thousands of public-domain projects accessible to developers. When you consider that an OSS project can have multiple versions in the public domain and each package can consist of anything between two and 200,000 files, we gain an appreciation for the task involved in this method. Manual identification of code similarity to millions of files is obviously impractical. Only intelligent automated solutions can go through a software portfolio and examine similarity between each and every file in that portfolio and software files in public domain.

The Art: Reading Between the Lines
The methods described above could theoretically provide insight into composition of a code portfolio. However, those methods alone are not sufficient to reveal an accurate view of the code composition.

• Manual records are the least reliable method as third-party content is often brought into a project without registering a record. Also, in today's typical development environment it is very difficult to guarantee access to the original developer's piece of software.
• File header information is not necessarily an accurate representation of the file pedigree and license. These can be changed by a developer, or automatically as in Linux kernel header files that were used in Android packages.
• Almost all OSS uses OSS. For example, there are more than 65,000 instances of commons.logging (a popular Apache logging layer), and more than 50,000 instances each of Log4j (another Apache logging utility for Java) and JUnit (a popular testing framework for Java) code in various public-domain projects. This leads to OSS project and license nesting complexities and contributes to challenges in correctly identifying the OSS packages within a portfolio. It is critical to detect the genesis OSS project and the version of the original and framing OSS projects. Practical examples of this challenge are:
  • Open source packages that use other OSS but do not maintain or propagate the original OSS license. This action may not be legitimate depending on the original OSS license and the license of the derived OSS package and can lead to erroneous conclusions about the quality as well as usage obligations associated with the organization's software.
  • Open source packages that change the license in subsequent versions such as moving from one version of a license. For example, GPLv2 to GPLv3 on a new release of the OSS project or moving from one license to another compatible license.
  • Projects where the OSS file or folder name is modified. This happens regularly on libraries (those with .jar or .bin extensions), and less frequently on source code files.
  • Seemingly known but non-existent licenses mentioned within a file or folder. A prime example is an OSS package that claims it's released under GPL. There is no GPL, only versioned GPL such as GPL v1, v2 licenses are available.

The art of OSS audit activity and license management relies on a clear understanding of the open source software community, open source packages, open source licenses, and development practices. This understanding comes with both academic knowledge as well as experience in scanning, reviewing, and auditing hundreds of software portfolios. Automated solutions that combine the science of scanning and license management with empirical methods that embody the art of open source package detection and license discovery can significantly speed up the discovery and management process and minimize, although not eliminate, the human involvement factor.

Conclusion
Rapid software development is necessary for sustaining the pace of innovation needed in today's world and the use of OSS is perhaps the best way to maintain this pace. While most organizations are now using open source to their advantage, they must avoid potential complications that OSS license obligations present. The complexity that OSS licenses present makes it almost impossible to manage obligations manually. This is where automated solutions come in. Conducting a one-time audit, or preferably, having a continuous process in place to automatically detect OSS licenses and their obligations is the best way to protect your organization from risk while ensuring continuous innovation.