In December of 2000, IBM made a huge splash announcing the landmark investment of 1 Billion dollars in Linux and open source software. This move sent ripples through the technology industry and gave confidence to other companies to start seriously exploring and evaluating Linux as an alternate operating system and figuring out what open source software components are worthy of a corporate investment. At that time, I was working at Ericsson Research in Montreal, Canada, as a System Designer focusing on the design and prototyping of carrier grade systems using Linux and open source software. I started this job 11 months before IBM’s announcement. Back then, open source compliance was not a thing. We did not really understand what it meant; we did not have the mechanics developed to implement it, and most of the related discussions were debates about open source licenses. To the point, I even remember co-authoring with my colleagues at Ericsson a report in 2001 entitled “What is Linux? What is the GNU GPL”. This was our attempt at educating our leadership on the topic and also trying to figure out what are the obligations we need to fulfill when using the GPL. Good times.
Fast track 20 years.
Open source runs every bit of our modern life. It’s ubiquitous. It powers the internet and everything connected to it. With that massive adoption over 20+ years, the concept of open source compliance has evolved and we are in a much different space today than we were then. Most open source licenses are well understood. We understand what are the obligations per license that we need to fulfill and respect. We have educational programs and training to make sure people handling open source software are aware of their responsibilities. Enterprises have open source program offices (OSPOs) acting as clearinghouses for all open source activities (using, contributing, creating, complying). In the process, we’ve learned to build open source compliance programs, establishing processes and policies to govern the use of and contribution to open source projects, adopting tools for automation processes, and so on… And, we’ve created a new breed of tools’ category – Software Composition Analysis Tools – to help us identify open source code, pinpoint their origins, license and flag any security vulnerabilities found in it.
Really great progress.
However, we still have a number of challenges in relation to open source compliance that we need as an industry to chase and resolve.
SCALABILITY – How can we build scalability in our compliance efforts?
Enabling thousands of developers across any given organization using the SCA tooling simultaneously in support of their development efforts, scanning thousands of software components daily, identifying the origin and license of these components, and identifying any possible security vulnerabilities found in the code base.
STANDARDIZATION – What can we standardize across companies throughout the ecosystem?
Standardizing various aspects of the compliance process. There are a couple efforts in this direction from the Linux Foundation:
- OpenChain defines the key requirements for an organization’s open source compliance program. It establishes a conformance program where companies can self-certify to these requirements, with the goal of improving transparency and communication of compliance information across supply chains.
- SPDX (Software Package Data Exchange) is a specification for communicating Software Bill of Materials information in a standardized, human- and machine-readable format. It enables better communication of information, including license and copyright details, between organizations and interoperability between compliance tools.
Both of these initiatives are key in supporting open source compliance in a growing and complex software ecosystem.
SPEED – How can we maintain highway speeds of development and not hinder it with slower compliance activities?
Keeping up with the pace of fast development in open source is a major challenge. Compliance is often regarded as a burden, an add-on activity that must be done and no one likes to work on it. We need to change that and make compliance a non visible activity that happens automatically, in the background, at lightning speed.
ACCURACY – Can we depend on the results?
Accuracy is a critical challenge for many SCA tools. Ideally, when you scan code, you’d want the tool to identify the true origin of the code and the license under which that original code was released under. However, due to a high degree of code reuse, many of scanned code bases appear dozens and hundreds of times as possible matches and hence requiring a compliance engineer directing the tool on what’s a correct match and what’s a false positive. Accuracy with many SCA tools is a concern and a great goal to achieve in the near future.
INTUITIVE – Can everyone use it?
As mentioned earlier, we want all developers to be compliance engineers and hence the tooling used to support compliance efforts should be easy to use and very intuitive. Deploying such tools directly with the developers would help avoid compliance problems before they get integrated with the larger code bases. You would want an easy to use tool that minimizes the learning curve and avoid the need for professional training.
There are certainly other challenges that exist in the domain but the above would be my top 5 picks. Right now, compliance is a personal interest versus a core part of my job as it was years ago. I continue to write about the topic and follow the news and the development of tools in the space and believe the next frontier is taking the cost out of achieving compliance and providing a standardized easy-to-replicate process to ensure compliance and enable innovation with open source software.
What are the challenges you’re experiencing in relation to open source compliance? Please write about it, share it and more than likely you’re not the only one working to resolve them. Let’s come together as an industry and make open source compliance easier, faster and cheaper — while benefiting a charity of your choice!
About the author
Ibrahim Haddad (Ph.D.) is the Executive Director of the LF AI & Data Foundation. Throughout his career, Haddad has held technology and portfolio management roles at Ericsson Research, the Open Source Development Labs, Motorola, Palm, Hewlett-Packard, the Linux Foundation and Samsung Research. He is known for his writing and speaking on topics ranging from legal compliance to using open source as an R&D tool to drive collaboration and innovation.
Linux Foundation Resources
I would like to invite you to explore some of the resources that the Linux Foundation is making available for free on the topic of open source compliance.
- Linux Foundation Open Compliance Program: The Open Compliance Program website is a starting point for developers and lawyers, particularly those who are new to open source compliance considerations, to learn more about the tools and best practices that can make compliance easier.
- Open Source Licensing Basics for Software Developers: This free training course is focused on developers (although it is also helpful to lawyers who are new to open source) as a basic grounding in open source licensing and compliance matters. It covers the underlying concepts of copyrights and patents; discusses how open source licenses function in this legal ecosystem; and gives concrete examples and recommendations for how best to include license and copyright notices in your own code.
- Whitepapers
- Docker Containers and License Compliance
- Ebooks:
Share this article
