Posts

In the last few years we have witnessed the unprecedented growth of open source in all industriesfrom the increased adoption of open source software in products and services, to the extensive growth in open source contributions and the releasing of proprietary technologies under an open source license. It has been an incredible experience to be a part of.

As many have stated, Open Source is the New Normal, Open Source is Eating the World, Open Source is Eating Software, etc. all of which are true statements. To that extent, I’d like to add one more maxim: Open Source is Eating the Startup Ecosystem. It is almost impossible to find a technology startup today that does not rely in one shape or form on open source software to boot up its operation and develop its product offering. As a result, we are operating in a space where open source due diligence is now a mandatory exercise in every M&A transaction. These exercises evaluate the open source practices of an organization and scope out all open source software used in product(s)/service(s) and how it interacts with proprietary components—all of which is necessary to assess the value creation of the company in relation to open source software.

Being intimately involved in this space has allowed me observe, learn, and apply many open source best practices. I decided to chronicle these learnings in an ebook as contribution to the OpenChain project: Assessment of Open Source Practices as part of Due Diligence in Merger and Acquisition Transactions. This ebook addresses the basic question of: How does one evaluate open source practices in a given organization that is an acquisition target? We address this question by offering a path to evaluate these practices along with appropriate checklists for reference. Essentially, it explains how the aquirerer and the target company can prepare for this due diligence, offers an explanation of the audit process, and provides general recommended practices for ensuring open source compliance.

If is important to note that not every organization will see a need to implement every practice we recommend. Some organizations will find alternative practices or implementation approaches to achieve the same results. Appropriately, an organization will adapt its open source approach based upon the nature and amount of the open source it uses, the licenses that apply to open source it uses, the kinds of products it distributes or services it offers, and the design of the products or services themselves

If you are involved in assessing the open source and compliance practices of organizations, or involved in an M&A transaction focusing on open source due diligence, or simply want to have a deeper level of understanding of defining, implementing, and improving open source compliance programs within your organizationsthis ebook is a must read. Download the Brief.

Open Source Compliance at NHSOne of the powerful things about open source is the way it allows various organizations and stakeholders come together to achieve common objectives. Open source projects play a critical role by providing a common platform that can integrate with new and existing systems. This is even more apparent when discussing open source compliance and aligning the various stakeholders in an open source supply chain.

A great example of this is a recent NHS case study published on openchainproject.org. NHS England is the public health services provider in England that treats more than 1.4 million patients every 24 hours. The organization needed a way to manage and leverage their open source assets across the organization without vendor lock in. Our partners at Source Code Control proposed the OpenChain Specification and brought us in to work with the Apperta Foundation, Code4Health initiative, OpenEyes, and AB EHR Digital for a training and pilot program.

The result enabled the project participants to meet open source industry best practices. It also helped NHS take the first step in a broader deployment plan across multiple projects and providers in the coming months and years. Thank you to all of our partners and we look forward to future collaboration in healthcare, automotive, and many more industries as they increasingly adopt open source. Read the NHS case study.

Open Source Compliance

This fully updated ebook provides detailed information on issues related to the licensing, development, and reuse of open source software.The Linux Foundation has released the second edition of Open Source Compliance in the Enterprise by Ibrahim Haddad, which offers organizations a practical guide to using open source code and participating in open source communities while complying with both the spirit and the letter of open source licensing.

This fully updated ebook — with new contributions from Shane Coughlan and Kate Stewart — provides detailed information on issues related to the licensing, development, and reuse of open source software. The new edition also includes all new chapters on OpenChain, which focuses on increasing open source compliance in the supply chain, and SPDX, which is a set of standard formats for communicating the components, licenses, and copyrights of software packages.

“Open source compliance is the process by which users, integrators, and developers of open source observe copyright notices and satisfy license obligations for their open source software components,” Haddad states in the book.

This 200+ page book encompasses the entire process of open source compliance, including an introduction on how to establish an open source management program, a description of relevant roles and responsibilities, an overview of common compliance tools and processes, and all new material to help navigate mergers and acquisitions. It offers proven best practices as well as practical checklists to help those responsible for compliance activities create their own processes and policies.

Essential topics covered in this updated ebook include:

  • An introduction to open source compliance
  • Compliance roles and responsibilities
  • Building a compliance program
  • Best practices in compliance management
  • Source code scanning tools

To learn more about the benefits of open source compliance and how to achieve it, download the free ebook today!

SPDX License Identifiers can be used to indicate relevant license information at any level, from package to the source code file level.

Accurately identifying the license for open source software is important for license compliance. However, determining the license can sometimes be difficult due to a lack of information or ambiguous information. Even when there is some licensing information present, a lack of consistent ways of expressing the license can make automating the task of license detection very difficult, thus requiring significant amounts of manual human effort.   There are some commercial tools applying machine learning to this problem to reduce the false positives, and train the license scanners, but a better solution is to fix the problem at the upstream source.

In 2013,  the U-boot project decided to use the SPDX license identifiers in each source file instead of the GPL v2.0 or later header boilerplate that had been used up to that point.   The initial commit message had an eloquent explanation of reasons behind this transition.

Licenses: introduce SPDX Unique Lincense Identifiers


Like many other projects, U-Boot has a tradition of including big

blocks of License headers in all files.  This not only blows up the

source code with mostly redundant information, but also makes it very

difficult to generate License Clearing Reports.  An additional problem

is that even the same lincenses are referred to by a number of

slightly varying text blocks (full, abbreviated, different

indentation, line wrapping and/or white space, with obsolete address

information, ...) which makes automatic processing a nightmare.


To make this easier, such license headers in the source files will be

replaced with a single line reference to Unique Lincense Identifiers

as defined by the Linux Foundation's SPDX project [1].  For example,

in a source file the full "GPL v2.0 or later" header text will be

replaced by a single line:


        SPDX-License-Identifier:        GPL-2.0+


We use the SPDX Unique Lincense Identifiers here; these are available

at [2].

. . .


[1] http://spdx.org/

[2] http://spdx.org/licenses/

The SPDX project liked the simplicity of this approach and formally adopted U-Boot’s syntax for embedding SPDX-License-Identifier’s into the project.  Initially, the syntax was available on the project WIKI and was formalized in SPDX specification version 2.1 “Appendix V: Using SPDX short identifiers in Source Files”.  Since then,  other upstream open source projects and repositories have adopted use of these short identifiers to identify the licenses in use, including github in its licenses-API.  In 2017, the Free Software Foundation Europe created a project called REUSE.software  that provided guidance for open source projects on how to apply the SPDX-License-Identifiers into projects.   The REUSE.software guidelines were followed for adding SPDX-License-Identifiers into the Linux kernel, later that year.

The SPDX-License-Identifier syntax used with short identifiers from the SPDX License List short form identifiers (referred here as SPDX LIDs) can be used to indicate relevant license information at any level,  from package to the source code file level. The “SPDX-License-Identifier” phrase and a license expresssion formed of SPDX LIDs in a comment form a precise, concise and language neutral way to document the licensing, that is simple to machine process.  This leads to source code that is easier to read, which appeals to developers, as well as enabling the licensing information to travel with the source code.

To use SPDX LIDs in your project’s source code,  just add a single line in the following format, tailored to your license(s) and the comment style for that file’s language.  For example:

// SPDX-License-Identifier: MIT

/* SPDX-License-Identifier: MIT OR Apache-2.0 */

# SPDX-License-Identifer: GPL-2.0-or-later

To learn more about how to use SPDXLIDs with your source code,  please see the guidance in the documentation in the SPDX project, REUSE.software  or David Wheeler’s SPDX tutorial.    

In addition to U-boot and Linux transitioning to use the SPDXLIDs,  newer projects like Zephyr and Hyperleger fabric have adopted them right from the start as a best practice.   Indeed, to achieve the Core Infrastructure Initiative’s gold badge, each file in the source code must have a license, and the recommended way is to use an SPDX LID.  

The project MUST include a license statement in each source file. This MAY be done by 
including the following inside a comment near the beginning of each file: 
SPDX-License-Identifier: [SPDX license expression for project].

When SPDX LIDs are used,  gathering license information across your project files can start to become as easy as running grep. If a source file gets reused in a different package,  the license information travels with the source, reducing the risk of licence identification errors, and making license compliance in the recipient project easier.  By using SPDX LIDs in license expressions, the meaning of license combinations is understood more accurately. Saying “this file is MPL/MIT” is ambiguous, and leaves recipients unclear about their compliance requirements. Saying “MPL-2.0 AND MIT” or “MPL-2.0 OR MIT” specifies precisely whether the licensee must comply with both licenses, or either license, when redistributing the file.

As illustrated by the transition underway in the Linux kernel,  SPDX LIDs can be adopted gradually. You can start by adding SPDX LIDs to new files without changing anything already present in your codebase.  A list of projects known to be using SPDX License Identifiers can be found at: https://spdx.org/ids-where,  and if you know of one that’s missing,  please send email to outreach@lists.spdx.org.  

Learn more in this presentation at Open Source Summit: Automating the Creation of Open Source BOMs

Modern open source projects rarely consist solely of all new code, written entirely from scratch. More often, they are built from many sources. And, each of these original sources may operate under a particular license – which may also differ from the license that the new project uses.

license scanning and complianceA new publication, called License Scanning and Compliance Programs for FOSS Projects, aims to clarify and simplify this process. This paper, written by Steve Winslow from The Linux Foundation, describes the benefits of license scanning and compliance for open source projects, together with recommendations for how to incorporate scanning and compliance into a new or existing project.

Winslow runs The Linux Foundation’s license scanning and analysis service, and he advises projects about licenses identified in their source code and dependencies.

He says that getting license compliance right early can help attract contributors and users to an open source project. However, he notes that license scanning and compliance are not end goals; rather, they are processes that can serve other objectives, including:

  • Protecting the project’s developers.
  • Assisting downstream compliance efforts.
  • Demonstrating project maturity.  

According to Winslow, “any project that implements license scanning and compliance should aim to make it sustainable” and should set realistic goals to avoid being overwhelmed by the number of options and issues that may arise.

Winslow also explains how using tools, such as FOSSology for license scanning and Software Package Data Exchange (SPDX) to help package scan results into meaningful reports, can help projects succeed in compliance efforts.

Learn more and download this free publication now.

The influence of open source software on every aspect of business has been on the rise for years, and it should come as no surprise that its influence during merger and acquisition (M&A) transactions has grown as well. In particular, open source audits are part of required due diligence in M&A or initial public offering (IPO) processes. Not only do such audits highlight potential instances of copyright infringement, but they give buyers and investors a landscape view of important open source components in their target’s technology stack.

These issues and more are covered in-depth in a new ebook, Open Source Audits in Merger and Acquisition Transactions, from Ibrahim Haddad and The Linux Foundation, which provides an overview of the open source audit process and highlights important considerations for code compliance, preparation, and documentation.

Today’s software products and technology stacks incorporate many open source components, and the implementation of these components can mean complex licensing and inter-dependency issues.  Part of the goal with a proper source code audit is to avoid unpleasant surprises post-acquisition. Source code scanning tools have the ability to discover and match snippets of open source code that have been incorporated within software tools and platforms. In addition, these tools can identify modifications to open source code that developers may have deployed.

“Every M&A transaction is different, but the need to verify the impact of acquiring open source obligations is a constant,” writes Haddad. “Open source audits are carried out to understand the depth of use and the reliance on open source software. Additionally, they offer great insights about any compliance issues and even about the target’s engineering practices.”

Haddad also notes that open source audits can expose obligations. “Open source licenses usually impose certain obligations that must be fulfilled when code is distributed,” he notes. “One example is the GNU General Public License (GNU GPL), which requires derivatives or combinations to be made available under the same license as well. Other licenses require certain notices in documentation or have restrictions for how the product is promoted.”

According to Haddad, there are three common types of open source audits that are performed in M&A situations:

  1. Traditional audit, in which the auditor gets complete access to all the code and executes the audit either remotely or on site.
  2. Blind audit, in which the auditor does the work remotely and without ever seeing the source code.
  3. “Do It Yourself” audit, where the target company or the acquirer performs most of the actual audit work themselves using the tools with the option for a random verification of results from the auditing company.

Is a merger and acquisition scenario the only time an organization should consider an open source audit? No, regular audits can provide much value, and companies such as Black Duck Software have specialized in doing them in many types of business scenarios. “While it’s undeniable that an open source audit is essential before any successful M&A or IPO, it’s no less important as part of a software team’s regular operations,” notes a blog post from White Source Software. “Put it this way, if you have license compliance or security issues affecting your open source components, isn’t it better to identify and deal with those issues sooner rather than later?”

Many important issues arise during audits, including potential security threats and lapses in version control. Everything you need to know, including recommended practices and mistakes to avoid, can be found in this ebook.

Download the ebook now.

By Chris Donley, Sr Director, Open Source Ecosystems, Huawei; Chair, OPNFV Certification & Compliance Committee

As we kick off 2018, the OPNFV Compliance & Certification committee—the members driven body within OPNFV that defines recommendations to the Board for policies and oversight for compliance and certification—is pleased to announce the launch of the OPNFV Verified Program (OVP). The program is designed to simplify adoption of NFV in commercial products by establishing an industry threshold based on OPNFV releases. The fact we are using an open source platform as referent to measure compliance of commercial products—not necessarily based on its source code—is a new and innovative step for the industry.

The OPNFV Verified Program facilitates both vendor self-testing and third-party lab testing using the Dovetail test suite. In our initial version, we will be testing NFV infrastructure components: NFVI and VIM. In the future, we may expand the program to cover VNFs and other components, as well. In December, just ahead of the launch, we conducted a “beta program” with several vendors: Huawei, Nokia, Wind River, and ZTE. These companies provided valuable feedback while we refined and finalized the program. They also represent the first cohort to received the privilege of using the OPNFV Verified mark and logo. Congratulations to these companies and we welcome additional members of the open NFV ecosystem to join us!

OPNFV Verified Program is designed to help operators establish entry criteria for their trials and RFPs. We have worked closely with end user advisor operators to establish a framework and an initial bar to support their requirements. The program will also reduce operator testing load by identifying a set of common tests and executing them just once under the auspices of the OPNFV Verified Program, rather than many times in many labs. As OPNFV and the industry at large continue to mature, we will steadily raise the bar in future versions as to what becomes verified. We expect two OPNFV Verified versions per year, denoted with the month and the year to make it easy to identify the compliance level of submitted products.

Under the auspices of The Linux Foundation, we are well positioned to expand the program to support other projects in the future. Prior to the official launch, we initiated discussions with related projects on leveraging the program to support the wider open source community. OPNFV’s C&C, the group responsible for chartering the OPNFV Verified Program, is also exploring additional operator use cases that can be incorporated into the compliance test suite.

I am excited about the launch of the OPNFV Verified Program and I hope you will join us in 2018! To operators, I invite you to share your use cases and functional requirements, and please consider incorporating OPNFV Verified into your RFP process or lab trials. To vendors, I hope you’ll download the Dovetail tool and test your commercial offerings. If you’re looking for assistance, several third-party labs are eager to help. Learn more about the OPNFV Verified Program and get started today!

Please direct any questions you may have to verified@opnfv.org.

This article originally appeared at OPNFV.

At organizations of all types, launching and maintaining successful open source programs has become a business priority. A strong open source program office helps to ensure that open source is supported, nurtured, shared, explained, and leveraged. With such an office, organizations can establish and execute on their open source strategies in clear terms.

With all this in mind, The Linux Foundation and The TODO Group (Talk Openly Develop Openly) have published a free collection of detailed open source guides to aid companies developing open source programs. The guides are available to you now, and this is the first in a series of articles that can introduce you to the value of the guides.

How to Create an Open Source Program is the first of the guides, and it explores everything from the role of the open source program office to how successful open source programs at companies like Google function. The guide also includes insights and advice from open source experts, including John Mark Walker, Founder of the Open Source Entrepreneur Network, and Will Norris, Open Source Office Manager at Google.

“The open source program office is an essential part of any modern company with a reasonably ambitious plan to influence various sectors of software ecosystems,” notes Walker, in the guide. “If a company wants to increase its influence, clarify its open source messaging, maximize the clout of its projects, or increase the efficiency of its product development, a multifaceted approach to open source programs is essential.”

The How to Create an Open Source Program guide makes clear that there is not a one-size-fits-all approach to creating a successful program. In fact, Google’s Norris notes that stakeholders from individual business units play a key role in how open source projects advance at Google.

“We allow the various business units around the company to make the decision on whether it makes sense to open source a given project from a business perspective, because there’s a lot of different reasons why you might open source a project or a piece of code,” he notes. “We’re comfortable with allowing projects to take the approach that works for them given their goals. We play more of a role of facilitating and advising.”

The first guide lays out recommendations for how to include stakeholders ranging from Legal to Engineering in the maintenance of a program office. It also delves into the importance of setting clear program policies and observing compliance guidelines.

“Having a well-defined policy in place, that’s great, but it’s got to be a well-defined minimal policy,” said Jeff Mcaffer, director of the Open Source Programs Office at Microsoft, who was interviewed for the first guide. “Otherwise you get lawyers, security folks, business folks, all piling in their concerns and constraints. Soon you end up with a straitjacket full of policy that basically means that nobody can do anything.”

These free guides are extremely valuable for any organization setting up an open source program. Notably, the guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We strongly encourage you to check out the guides, and stay tuned to this space for more articles in this series.

This week in open source and Linux news, open source Cosmos project is taking over aerospace, EdgeX Foundry IoT project announced this week by The Linux Foundation & more! Read on to keep your open source knowledge current.

1) Open Source Project “Cosmos” is opening up the traditionally proprietary aerospace industry.

An Aerospace Coder Drags a Stodgy Industry Toward Open Source– WIRED

2) New EdgeX Foundry IoT project from The Linux Foundation is garnering support from 50 industry heavyweights and counting.

Open Source EdgeX Foundry Seeks to Standardize Internet of Things– ZDNet

3) Linux/Shishiga malware uses four different protocols and Lua scripts for modularity. Detection engineers are concerned.

New Strain of Linux Malware Could Get Serious– LinuxInsider

4) Canonical’s mobile operating system is shutting down.

Ubuntu Touch Phone/Tablet Support Ends June– PCMag

5) The Linux Foundation and Free Software Foundation Europe have announced new resources to help with identification and compliance.

Open Source Groups Provide New Licensing Resources– ADTMag

The previous article in this series covered how to establish a baseline for open source software compliance by finding exactly which open source software is already in use and under which licenses it is available. But how do you make sure that future revisions of the same product (or other products built using the initial baseline) stay compliant once the baseline is established?

This is the concept of incremental compliance: you need to ensure compliance of whatever source code changes took place between the initial compliant baseline and the current version.

Maintaining open source license compliance throughout code changes is a continuous effort that depends on discipline and commitment to build compliance activities into existing engineering and business processes. And it’s a process that involves maintaining both the open source code, as well as the open source culture of an organization.

Below are some recommendations, based on The Linux Foundation’s e-book Open Source Compliance in the Enterprise, for some of the best ways to maintain compliance as your organization’s code and company evolves.

Maintaining Code Compliance

First, companies can maintain open source code compliance through processes and improvements aimed at the development process:

  • Adherence to the company’s compliance policy and process, in addition to any provided guidelines

  • Continuous audits of all source code integrated in the code base, regardless of its origins

  • Continuous improvements to the tools used in ensuring compliance and automating as much of the process as possible to ensure high efficiency in executing the compliance program

Maintaining a Culture of Compliance

In addition to the code, companies need to take steps to maintain compliance activities as the organization itself grows and ships more products and services using open source software. They must institutionalize compliance within their development culture to ensure its sustainability. Below are a few ways that companies can maintain the culture of compliance, as well as code compliance.

Sponsorship

Executive-level commitment is essential to ensure sustainability of compliance activities. There must be a company executive who acts as ongoing compliance champion and who ensures corporate support for open source management functions.

Consistency

Achieving consistency across the company is key in large companies with multiple business units and subsidiaries. A consistent interdepartmental approach helps with recordkeeping, and also facilitates sharing code across groups.

Measurement and analysis

Measure and analyze the impact and effectiveness of compliance activities, processes, and procedures with the goal of studying performance and improving the compliance program. Metrics will help you communicate the productivity advantages that accrue from each program element when promoting the compliance program.

Refining compliance processes

The scope and nature of an organization’s use of open source is dynamic — dependent on products, technologies, mergers, acquisitions, offshore development activities, and many other factors. Therefore, it is necessary to continuously review compliance policies and processes and introduce improvements.

Furthermore, open source license interpretations and legal risks continue to evolve. In such a dynamic environment, a compliance program must evolve as well.

A compliance program is of no value unless it is enforced. An effective compliance program should include mechanisms for ongoing monitoring of adherence to the program and for enforcing policies, procedures, and guidelines throughout the organization. One way to enforce the compliance program is to integrate it within the software development process and ensure that some measurable portion of employee performance evaluation depends on their commitment to and execution of compliance program activities.

Staffing

Ensure that staff is allocated to the compliance function, and that adequate compliance training is provided to every employee in the organization. In larger organizations, the compliance officer and related roles may grow to be FTEs (full time equivalents); in smaller organizations, the responsibility of open source management is more likely to be a shared and/or a part-time activity.

6WMmHe-e9aR6ui-QMbFTdRuEm5DvNzhvPkCdr6e9

Read the first article in this series:

An Introduction to Open Source Compliance in the Enterprise