Linux Kernel License Practices Revisited with SPDX®

The licensing text in the Linux kernel source files is inconsistent in verbiage and format. Typically, in each of its ~100k files there is a license text that describes which license applies to each specific file. While all licenses are GPLv2 compatible, properly identifying the licenses that are applicable to a specific file is very hard. To address this problem, a group of developers recently embarked on a mission to use SPDX® to research and map these inconsistencies in the licensing text. As a result of this 10 month long effort, the Linux 4.14 release includes changes to make the licensing text consistent across the kernel source files and modules.

Linux Kernel License

As stated on its COPYING file, the Linux kernel’s default license is GPLv2, with an exception that grants additional rights to the kernel users:

  • NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".
    Also note that the GPL below is copyrighted by the Free Software
    Foundation, but the instance of code that it refers to (the Linux
    kernel) is copyrighted by me and others who actually wrote it.
    
    Also note that the only valid version of the GPL as far as the kernel
    is concerned is _this_ particular version of the license (ie v2, not
    v2.2 or v3.x or whatever), unless explicitly otherwise stated.
    

The kernel’s COPYING file produces two practical effects:

  1. User-space applications can use non-GPL licenses by using the the above mentioned exception.
  2. It allows using different licenses in the kernel’s source files, when explicitly defined as such.

The Current Kernel License Model

A common practice is to add a comment at the beginning of each file with some sort of text like:

  • /*
     * Copyright (c) 2017 by foo <foo@bar>
     *
     * This program is free software; you can redistribute it and/or
     * modify it under the terms of the GNU General Public License
     * as published by the Free Software Foundation; either version 2
     * of the License, or (at your option) any later version.
     *
     * This program is distributed in the hope that it will be useful,
     * but WITHOUT ANY WARRANTY; without even the implied warranty of
     * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
     * GNU General Public License for more details.
     */
    

However, Philippe Ombredanne’s research showed that:

  • there are 64,742 distinct license statements
    • … in 114,597 blocks of text
    • … in 42,602 files
  • license statements represent 480,455 lines of text;
  • licenses are worded in 1,015 different ways;
  • there are about 85 distinct licenses, the bulk being the GPL.

Also, before kernel 4.14, there were about 11,000 files without any license at all. However, due to the COPYING file they’re defaulted to be GPLv2. This inconsistency makes it complex to determine which license applies to a particular kernel version.

Software Package Data Exchange® (SPDX®)

The Linux Foundation has sponsored the SPDX® project to solve the license identification challenges in open source software. The goal of the project is to provide license identifiers inside the source code that could be easily parsed by machines and would allow checking for license compliance of an open source project easier.

In practice, supporting SPDX® inside source code is as simple as adding an SPDX® tag (SPDX-License-Identifier) with the license that applies (usually, GPL-2.0). If you’re the copyright holder, you may also consider removing the now redundant licensing text.

An example commits that add SPDX® tags and cleanup redundant license from USB over IP driver:

commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Nov 3 11:28:30 2017 +0100

    USB: add SPDX identifiers to all remaining files in drivers/usb/
    
    It's good to have SPDX identifiers in all files to make it easier to
    audit the kernel tree for correct licenses.
    
    Update the drivers/usb/ and include/linux/usb* files with the correct
    SPDX license identifier based on the license text in the file itself.
    The SPDX identifier is a legally binding shorthand, which can be used
    instead of the full boiler plate text.
    
    This work is based on a script and data from Thomas Gleixner, Philippe
    Ombredanne, and Kate Stewart.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kate Stewart <kstewart@linuxfoundation.org>
    Cc: Philippe Ombredanne <pombredanne@nexb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Acked-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 11b9a22799cc..0e16a7dcfb38 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+

...

Depending on the type of the source file, the tag will be either one of the tags below:

SPDX® licence identifier tags at the source code
Type of file SPDX License tag
C source: // SPDX-License-Identifier:
C header: /* SPDX-License-Identifier: */
ASM: /* SPDX-License-Identifier: */
scripts: # SPDX-License-Identifier:
.rst: .. SPDX-License-Identifier:
.dts{i}: // SPDX-License-Identifier:

Replacing the licenses inside each source file by a single SPDX license will likely reduce the kernel source files by ~400k lines, with is a nice cleanup, and solve all those issues with ~64k different license statements.

Future Work

Besides the license on each kernel source file, all Linux modules use MODULE_LICENSE() macro to specify their individual license. Right now, the following values for the macro are valid for a module within the official kernel sources:

Types of licenses for MODULE_LICENSE() macro
Macro argument License
“GPL” GNU Public License v2 or later
“GPL v2” GNU Public License v2 only
“GPL and additional rights” GNU Public License v2 rights and more
“Dual BSD/GPL” GNU Public License v2 or BSD license choice
“Dual MIT/GPL” GNU Public License v2 or MIT license choice
“Dual MPL/GPL” GNU Public License v2 or MPL license choice

Any other value “taints” the kernel when such module is loaded, in order to inform the user that a proprietary module was loaded.

With the addition of SPDX® at the kernel, the next step will be to use SPDX tags for Module License. The current plans seem to be to replace the MODULE_LICENSE() macro with MODULE_LICENSE_SPDX() that would take the same SPDX identifier as used in the source code and convert to the values above to keep backward compatibility. The method to achieve this is still under discussion at the Linux Kernel Mailing List.

Additional References:

LWN.net has an interesting article covering other aspects: SPDX identifiers in the kernel. The Free Software Foundation Europe has a set of best practices for License identification at the source code, called REUSE.

The SPDX Trademark is owned by the Linux Foundation.

Check Out the Free Open Source Compliance Handbook

Open source compliance is often overlooked, but is a critical component of a successful open source software strategy. If your company is going to use or contribute to open source software, failure to comply with the software licenses can lead to costly cleanup efforts, or even lawsuits if license violations are found. To mitigate these risks, it’s important to establish an internal organizational program that manages compliance with open source licenses.

For many companies, open source compliance is often the first major step into open source engineering, so it’s vital to establish proper organizations and procedures that build a foundation for continual success. That’s why Ibrahim Haddad joined forces with the Linux Foundation to create Open Source Compliance in the Enterprise, and released it as a free handbook to download.

This book covers the essentials of establishing a successful open source compliance strategy in an enterprise setting, including the structure of an open source management program, common processes and tools for compliance, how to train and encourage developers to follow compliance processes, when and how to involve legal experts, and more.  Many of these strategies are employed here at the Samsung Open Source Group and have helped us establish ourselves as a valuable asset to Samsung’s success. If you oversee a team of software engineers who work with open source software, this book will provide a wealth of helpful information; you should give it a read!

10 Steps to Being Successful in Open Source

No blog is complete without a simplistic numbered list of images, and we’re no exception! Open source methodology can be a complicated subject, but that doesn’t mean we can’t try to boil it down to some easily-digestible snippets. We’re proud to present the 10 simple steps it takes to be successful in open source. All of the images in this article were created by Ibrahim Haddad and are shared under CC-BY-SA-4.0, so feel free to use them in your own work.

1. Setup business infrastructure to support open source

It is extremely challenging for a company to be successful in open source if they haven’t setup the proper infrastructure to allow their employees to interact with an open source community; this includes the establishment of both technical infrastructure as well as organizational infrastructure. You need to make sure your developers have the policies, processes, and tools that are required to contribute code upstream in place, and it’s necessary to make sure everyone involved is properly educated on the use of this infrastructure.  This should be completed before any significant open source effort is undertaken as it prepares you to be successful for the long run.

10 Steps to Being Successful in Open Source - CfPK1rMWAAEovq4

2. Build a team of skilled developers

Open source developers have somewhat different requirements than developers of proprietary software components. For starters, open source development occurs all over the world, and developers are rarely tied to specific geographic locations. This means you will likely need to offer the option to work from home or their current city in order to attract the best individuals. Additionally, their job often requires them to have public interactions with individuals outside the company, and they often serve roles, like maintainerships, outside the requirements of their job and they need to be supported in these efforts. Finally, open source developers typically need to hold periodic in-person meetings with others from the community, which means they often need to travel to events like conferences and technical summits in order to determine the direction of the project. If you want to hire great open source talent, you need to make sure their unique needs are met.

10 Steps to Being Successful in Open Source - CWSrp48UYAAa-zB

3. Apply collaborative development processes and skills

Collaborative development is at the heart of any open source project, and there are a lot of elements that go into being successful with this type of development. Adopting this development model can require changes to things like company culture, processes, tools, and human resources in order to make sure the company can be accommodating. This effort can pay off in spades if you are successful and your company can reap rewards that far outweigh the initial effort by reducing R&D costs, increasing the speed of innovation, and accelerating product development.

10 Steps to Being Successful in Open Source - CWhWYPxUEAAU94P

4. Enable collaborative tools

Collaboration in most open source communities is centered around a relatively standardized set of tools. Tools like wikis, IRC, and mailing lists allow members of the community to communicate with each other. Open source communities often rely on things like Bugzilla, git, and file servers to collaborate on code development, and blogs are often used to inform people about community efforts to keep everyone on the same page. Internal policies and infrastructure must be put into place to ensure your developers can adequately interact with open source communities using these tools.

10 Steps to Being Successful in Open Source - CY9jTWuVAAATZ0z

5. Learn how to send code upstream

Sending code upstream can be a challenging process as it often involves multiple rounds of review and revisions and requires that your company adopt an upstream first mentality. Code that is useful to others, follows the coding style of the community, and that includes documentation is much more likely to get accepted.  Each community has their own processes and guidelines for getting code accepted upstream; it’s vital to be aware of them from the very beginning and to follow them as closely as possible. The community will need time to review the code and often there are multiple stakeholders that will provide feedback. All feedback must be accommodated before code can be contributed upstream.

10 Steps to Being Successful in Open Source - ChDyX-cUgAIKAi_

6. Improve code quality to meet the standards of the open source community

Open source communities tend to have very high standards for the quality of code that is accepted. Any company that wants to submit code upstream needs to put in the effort required to meet this standard, and there are practices that can be implemented internally to facilitate this effort. For starters, mentor programs where experienced open source developers assist newcomers in getting code accepted to the project can help build new talent. Additionally, programs that teach developers to build code according to the requirements of the open source project and that help developers adopt the lean, agile methodologies of open source can improve both internal code as well as code that is contributed upstream. These programs can be facilitated with clear guidelines and useful tools, and can be tracked through regular performance reviews.

10 Steps to Being Successful in Open Source - Ch4nxMFUgAAYkn0

7. Make sure you comply with open source licenses

Open Source initiatives and projects provide companies with a vehicle to accelerate innovation through collaboration with the global community of developers. Important responsibilities come hand-in-hand with the benefits of teaming with the open source community, and companies must ensure compliance with applicable open source license obligations. Open source compliance means that commercial users of open source must observe all the copyright notices and satisfy all the license obligations for the open source software they use. Therefore, it is vital to establish an open source compliance program to ensure that your organization meets the obligations of all open source code included in products.

10 Steps to Being Successful in Open Source - Chk1TWjUYAEYhvf

8. Release early, release often

Release early, release often is a practice that has been integral to open source software for most of its history. This is one of the primary practices that allows open source communities to innovate at a rapid pace with a high quality of code because it creates a much faster feedback loop between developers, testers, and users. Releasing early allows feedback at an earlier stage of development so new ideas can be incorporated while the code is still flexible, and it also allows any potential issues to be flagged more quickly. Releasing often results in smaller changes that are easier to understand, debug, and improve which makes it much easier to maintain a rapid development pace.

10 Steps to Being Successful in Open Source - ChUccduU8AAsoG3

9. Track performance metrics

Once you’ve successfully submitted code to upstream projects, you will probably want to keep track of metrics related to your performance. This helps you gauge how effective your interactions with open source projects are and allows you to identify areas you can improve. Quantitative metrics like patch submission and acceptance rate as well as internal collaboration efforts can help compare development efforts between organizations and companies. Qualitative metrics like conference talks, publications, training, and social media outreach can be used to gauge to level of influence your company has on an open source community.

10 Steps to Being Successful in Open Source - CWXgLqXVEAAJIlh

10. Drive open source leadership

Last, but not least, after you’ve successfully accomplished the first 9 steps you can begin to become a leader in the open source community. Good leadership allows you to influence project direction in order to better support your products and is something that must be cultivated over an extended period of time. Open source development requires an ongoing relationship with an open source community, and this relationship must be cultivated through hiring key individuals, contributing to upstream projects, supporting teams to make open source contributions, and encouraging developers to become involved in community outreach. If you follow these practices you should be quite successful in contributing to and influencing open source communities.

10 Steps to Being Successful in Open Source - CYpuPiiUwAA38mc

Questions to Ask Before Launching an Open Source Project

I’ve been at Samsung in the Open Source Group as Senior Open Source Strategist for about three months now, and one of the most exciting parts of my job is to help internal groups prepare to spin up new open source projects. This is something that I particularly enjoy, having spent five years at The Linux Foundation doing pretty much the same thing (albeit seated in a different place at the table).

So You Think You Can Open Source?

One of the things I’ve noticed over the past few years is that it’s really easy and exciting for people to say, “Open source is hot! Let’s create a new project, do some open source-y stuff, and change the world! And let’s tell the boss we’re doing this right away!”

In some cases (including a few I’m working on right now) this genuinely is the case. Truly transformative technologies tend to get their start with a brilliant dreamer, but hit their stride when the ability to expand and innovate is opened up to others. Building an open source community has become the tech industry’s de-facto solution to the founder’s dilemma.

The other side of this is that not all acorns can become the tallest oaks in the forest. Some open source projects limp along while others flop badly, and in the process they can drain time, money, and morale. Clearly this is not what anybody wants, although it’s not always immediately apparent which ideas will prosper and which will fail.

The reality is that technology itself can be somewhat distracting. It’s very easy to say, “Hey, this is the best thing since sliced bread, who wouldn’t want to work on it?” This is a loaded question, and a hard one to answer consistently because we all tend to be blind to our weaknesses.

The Pre-Open Sourcing Sanity Check

To address this we’ve been developing a structured process for evaluating open source project proposals. The goal is to identify proposals that aren’t likely to be successful before they’re set in motion, so we can modify or reject the ones that aren’t quite right. In certain cases, this may even mean doing something other than open source. Hopefully though, in the end it will result in a pipeline of high quality, focused, and useful open source projects from Samsung.

To that end we recently published a presentation that outlines, at a high level, the questions we ask when a new project is proposed to the Open Source Group at Samsung. The Pre-Open Sourcing Sanity Check focuses on four key questions:

  1. Can we do it?
  2. Should we do it?
  3. Who will we do it with?
  4. How will we do it?

Of course, exceptions do apply. Not every project will have the same answers for all questions, and it would be incorrect to presume the “best practices” outlined in this document (based upon years of first-hand Linux Foundation experience) apply universally. However, we think applying these sanity checks to the front-end of the open sourcing process will help us be better and more consistent with Samsung-initiated open source projects in the future.

Once a project has satisfactory answers for these questions we move them onto the next phase, which is to work out all of the details and decision points needed for a launch – but that’s a discussion for another time.

Have a look, and let me know what you think. I’m particularly interested in what has worked for you that’s missing from this list. You can find me at @RealBrianWarner.

An Introduction to Tizen Compliance

There is a whole world of smart devices out there, and Tizen has been built to run on many of them, including phones, televisions, cameras, appliances, cars, and more. The software that runs on top of these intelligent devices is what powers the new and interesting functionality that make up the Internet of Things. The latest generations of mobile devices have introduced new methods of installing apps in ways that allow them to be used on a wide range of devices, and this article will take a look at how Tizen makes sure that apps run on as many device types as possible through the Tizen Compliance program.

How an App is Installed

At the root of this is how apps are installed on an operating system. Traditional UNIX/Linux systems have several methods to install applications.

  • One method is to hunt for the source code, build it, and run something like “make install.”
  • Another method is to get a prepackaged installer, that handles all of the technical details, from a vendor who knows how to put things in the right places for their app.
  • Yet another method is to install from a repository: a known location on the Internet that the package software on your system knows how to retrieve and install from. The system or distribution provider, or other groups and vendors that package software for your type of system can provide these repositories.

The App Store Model

On mobile devices, the story is normally considerably more constrained. The first method does not work well because you typically do not have a build environment on your device. Additionally, unless you have a “jailbroken” device, you don’t usually have the admin rights to do installations anyways; this prevents both options one and two. Regardless, 3rd party installer packages have some disadvantages, among them the challeng of keeping  software updated. This has been demonstrated with things like the Java Runtime Environment, where security updates have often been very slow to deploy because system owners might not notice there is an update needing to be installed.

Instead, mobile device installation happens from a special curated repository, colloquially called an App Store; a concept that will be quite familiar to users of Apple and Android phones.  These operate using close cooperation between a client already installed on the device and the app store servers. The result is the user is presented with only the packages that are available to install on their specific device.  For example, packages that require a higher pixel count, on a large screen, with accelerated graphics hardware can be filtered out for devices that don’t have these graphical capabilities.

The app store model works best if there is a high degree of compatibility between different devices of a similar type. For differences between devices, the application should be coded to adapt to those differences and “just work”. If there are differences which do need to be exposed, there needs to be a clear method for indicating which device capabilities an application requires, as in the example in the preceding paragraph. For example, app developers should not need to make different versions of their app for phones built by HTC, Samsung, Sony, and so on. Nor should they be required to make a different version for each new Tizen API version. An ecosystem where these two scenarios are necessary is said to be fragmented, and the goal should be to reduce or eliminate fragmentation to improve platform adoption.

How Tizen Reduces Fragmentation

The effort to reduce fragmentation in Tizen is called the Tizen Compliance program.  The term compliance is a little overloaded, for example it is often associated with financial accounting standards. In terms of using open source software, it refers to assuring the specific license the code is released under is being followed. If we define compliance as “acting in accordance with a rule, policy, regulation, standard or law,”  both uses make sense. In Tizen, the Tizen Compliance Specification aims to ensure that implementations of Tizen are compatible with one another, and most importantly, are able to run applications that follow the standard.

When a particular version of Tizen is released, the general code base is referred to as the Platform. The adaptation of the platform to a specific device category is called a Profile. The Application Programing Interface (API) and application execution environment for that profile are called a Compliance Profile. The Tizen Compliance Specification (TCS) is what defines this compliance profile. For the Tizen 2.3 platform, there is a TCS for the Mobile Profile, and a TCS for the TV Profile.  Each TCS precisely describes the profile-specific supported API set (including mandatory and optional elements) that devices must provide, as well as some additional necessary details such as codecs, mandatory and optional hardware elements and their relationship to APIs, and portability aids such as the feature and privilege declarations used by packages. This sets up a predictable environment to program applications for. The Tizen team wants to keep the number of profiles as small as possible, and to maintain a high degree of compatibility between versions.

What Does it Take to be a Tizen Device?

In order to complete the set of compliance deliverables, a series of tests are packaged together to confirm that a device actually follows the TCS. This is called the Tizen Compliance Tests (TCT).  Use of the Tizen trademark is tied to passing the TCS, and it’s designed as a self-test set of tools. Vendors are not required to pay authorized testing labs as they can run the tests themselves.

TCS and TCT are released together for each new Tizen platform version and matching profiles. Their combination clarifies what exactly it means to be Tizen. Applications do not have their own compatibility test, but app stores can force compliance with certain rules as a condition of submission.

I hope this article has made it clear what it takes for something to be a Tizen device. Check out the Tizen Compliance page to learn more about the program and to see the current specifications. In the next article on this subject, I’ll dive into some of the specific details of how applications can use Tizen Compliance to make portable Tizen packages.

7 Steps to Strengthen Your Open Source Compliance

Introduction

Proper Open Source compliance gives you the ability to honor the obligations of open source licenses while protecting your own Intellectual Property (IP), as well as that of 3rd party software providers, from unintended disclosure. Companies that use open source software in their products should establish such a program to ensure compliance with all open source licenses. Basic elements of a compliance program include: policies, processes, guidelines, training, and automated source code audits. Compliance activities must be carefully planned and monitored to assure that objectives are met in a timely manner.

There are three fundamental steps that comprise the core of a Free & Open Source Software (FOSS) compliance process:

  • Identifying any open source software contained in an externally distributed product
  • Reviewing and approving the intended use of FOSS
  • Satisfying FOSS license obligations

7 Steps to Strengthen Your Open Source Compliance - 1

Figure 1: The three fundamental steps that comprise the core of an open source compliance process

In this blog post, I’ll discuss a 7-step system you can use to improve and strengthen your open source compliance program:

  1. Assign an open source compliance officer
  2. Set up an Open Source Review Board (OSRB)
  3. Set up an automated system to identify open source software in your code base
  4. Get your software suppliers to comply with open source licenses
  5. Scale open source legal support to your development teams
  6. Include open source compliance checkpoints as part of business and development processes
  7. Provide checklists for the various open source compliance tasks

Step 1: Assign a Dedicated Open Source Compliance Manager

The compliance officer manages the overall compliance program. This person drives compliance due diligence, end-to-end process, and acts as the compliance program manager to ensure all compliance-related tasks are resolved and there are no compliance issues blocking product shipment.

The open source compliance officer must have the following expertise:

  • Solid understanding of open source licenses and obligations to discuss with legal counsels
  • Knowledge of open source development and compliance industry best practices
  • Knowledge and experience in establishing corporate wide programs, policies, and processes
  • Technical knowledge in order to be capable of conversing with engineers
  • Contacts in the open source organizations and communities that could be called upon for clarification and support when needed

Step 2: Set up an Open Source Review Board

The open source review board consists of representatives from legal and product teams, in addition to the compliance officer. The primary duty of the OSRB is to review and approve the planned use of open source software in products.

Table 1 provides a detailed view of the responsibilities of each participant in the OSRB.

OSRB Members Primary Responsibilities
Legal representative
  • Review and approve usage, modification, distribution of FOSS
  • Provide legal guidance
  • Contribute to the creation of the open source compliance training
  • Contribute to the creation and improvement of the compliance program
  • Review and approve content of web portals in relation to compliance
  • Review and approve the list of obligations to fulfill for each software component included in a product
  • Sign off on product release from a compliance perspective
Engineering and product team representative
  • Follow compliance policies and processes
  • Integrate compliance practices in the software development process
  • Contribute to improving the compliance program
  • Follow technical compliance guidelines
  • Respond quickly to all compliance related questions
  • Conduct design, architecture and code reviews
  • Prepare FOSS packages for distribution
  • Sign off product release from a compliance perspective
Compliance Officer
  • Drive compliance activities
  • Coordinate source code scans and audits
  • Participate in engineering reviews, code inspections, distribution readiness assessment
  • Coordinate distribution of open source software
  • Contribute to the creation of compliance training
  • Help improve the compliance program
  • Contribute to the creation of new tools to facilitate the automation and discovery of open source in the development environment

Table 1: Primary responsibilities of the core compliance team

Outside of the OSRB members, there are several individuals that contribute to the open source compliance effort. Figure 2 presents the individuals and teams responsible for achieving FOSS compliance.

7 Steps to Strengthen Your Open Source Compliance - 2

Figure 2: Individuals and teams responsible for achieving open source compliance

Step 3: Identify Open Source Software in Your Code

The core of any open source compliance effort is to identify open source code and its respective licenses so you meet all license obligations. This core activity is guided by an open source policy and a process. Compliance policies and processes govern the various aspects of using, contributing, auditing, and distributing open source software. The policy is a set of rules for the use and management of open source software in the organization. The process describes how the organization will implement these rules on a daily basis.

Here is a short example of an open source compliance policy:

We must ensure that all of ’s incoming software (in house, 3rd party commercial, open source, etc.) is compliant with the license it is provided under by following the open source compliance process defined in .

Figure 3 is an example of an end-to-end compliance process that includes the various steps a software component goes through before the OSRB approves its acceptance in the build system and integration with the software product.

7 Steps to Strengthen Your Open Source Compliance- 3

Figure 3: Sample open source compliance process

Step 4: Get Software Providers Involved

It is crucial to get your software providers involved in the open source compliance process. Software providers must disclose any open source code included in the products they deliver to you, and they must offer everything you’ll need to meet license obligations once these deliverables are included in your own product.

It is common to require software providers to disclose the following information related to open source software:

  • Package name
  • Version number
  • Original download URL
  • License and License URL
  • Last Modified Date
  • Dependency List
  • Development team’s point of contact
  • Availability of source code

Different organizations require various disclosures, but the list above is a good starting point. In addition to this list, it is very desirable for software providers to report license information for FOSS using the Software Package Data Exchange (SPDX) format, especially if their clients have already adopted SPDX.

Step 5: Offer Easily Accessible Legal Support

It is often the case that open source legal support is a bottleneck in a company, as you might have hundreds, or even thousands of developers writing open source code, but very few legal staff responsible for providing the needed legal support. Scaling open source legal support requires some out-of-the-box thinking and it can be achieved via four practical methods:

License Playbooks

An easy-to-read and digest summary of FOSS licenses intended for software developers. This provide easy-to-understand information about FOSS licenses, such as license grants, restrictions, obligations, patent implications, and more. The availability of such playbooks for the most-used FOSS licenses minimizes the number of basic questions sent to legal counsels and provides developers with immediate legal information.

License compatibility matrix

License compatibility is determining if a certain license has compatible terms with another license. When something is said to have “GPL compatibility,” it states that a certain license has compatible terms with the GPL. The license compatibility problem is often encountered when combining source code originating from different software components licensed under incompatible licenses, which makes it impossible to combine the source code to create a new component.

When the development team combines incoming code under different licenses, they can refer to the license compatibility matrix to verify if there is a licensing conflict created by combining the source code into a single software component. If a license is used and it is not covered in the matrix, it can be added by the legal counsel that advises on open source licensing.

License classification

An easy way to understand the difference between licenses and the course of action needed when using source code provided under these licenses.

Software interaction methods

A guide to understanding how software components available under different licenses interact and if the method of interaction is allowed according to company compliance policies.

Step 6: Inject Compliance Activities into Everyday Development Processes

To ensure the success of your open source compliance effort, incorporating compliance practices into business and development processes is a must. To achieve this, you can:

  • Modify existing business processes to incorporate open source compliance 
activities and considerations
  • Tailor software supplier selection procedures to assure that open source compliance requirements are considered when performing due diligence on suppliers
  • Update process management to ensure that compliance activities are included early enough in the product development cycle to enable the organization to meet its release time-lines
  • Use late-cycle verification steps to assure that all compliance requirements have been met before external distribution occurs
  • Provide open source compliance training to individuals charged with managing business processes
  • Provide license information in SDPX format that includes reporting license names using the SPDX common naming system

Step 7: Develop and Use Checklists

Checklists are extremely useful tools to ensure consistency and completeness in carrying out compliance tasks. It is highly recommended to establish a checklist for most compliance milestones as well as targeted checklists based on staff responsibilities. Examples of checklist include:

  • To approve the integration of incoming code into the product’s source code repository
  • To ensure the fulfillment of obligations from developers, engineer managers, compliance staff, and open source legal staff

The following is an example of a checklist that can be used before posting source code packages on a web site as part of fulfilling open source license obligations:

  • All source code components have a corresponding compliance ticket
  • All compliance tickets have been approved by engineering and legal
  • All compliance tickets are clear from any sub-tasks attached to them
  • Notices for all of the software components have been sent to Documentation team and included in product documentation (including written offer)
  • Legal has approved the written offer notice and overall compliance documentation
  • Source code packages have been prepared and tested to compile on a standard development machine
  • Source code provided is complete and corresponds to the binaries in the product

Open Source Compliance and the Software Supply Chain

The first time I was introduced to open source compliance was over a decade ago while I was a system engineer at Ericsson Research. Since then, compliance practices have improved dramatically and I’ve learned a lot. Open source compliance today is a far different problem than what it was 15 years ago, and today it is more about scaling, automation, and building trust within the software supply chain. Stay tuned to this site to learn more about open source compliance in future posts.