This new ebook from The Linux Foundation provides a practical approach to establishing an open source strategy based on more than two decades of experience.

When it comes to running and managing open source in the enterprise, experience-driven advice counts for a lot. It is very likely that your organization already runs open source, but many organizations make the mistake of reacting to the open source ecosystem instead of adopting a proactive strategy that is optimized for success. That’s where the free Enterprise Open Source ebook comes in.

This new 45-page ebook from The Linux Foundation provides a practical approach to establishing an open source strategy by outlining the actions your enterprise can take to accelerate its open source efforts. The information is based on more than two decades of professional, enterprise open source usage and development and will be most beneficial to software engineering executives, development managers, compliance experts, and senior engineers involved in enterprise open source activities.

“The availability of enterprise grade open source software is changing the way organizations develop and deliver products,” the book notes. “The combination of a transparent development community and access to public source code enables organizations to think differently about how they procure, implement, test, deploy, and maintain software. This has the potential to offer a wealth of benefits, including reduced development costs, faster product development, higher code quality standards, and more.”

Proven Practices

The book outlines concrete steps that an organization can take to run an effective open source program and foster success with open source. These include the following recommendations:

  • Join The Linux Foundation compliance Initiatives
  • Establish relationships with open source communities
  • Create or outsource open source training
  • Collaborate with universities on open source R&D projects
  • Join the TODO Group (Talk Openly, Develop Openly)
  • Encourage internal collaboration

The ebook also makes specific recommendations for important open source workflow practices in enterprises. You’ll find discussions on:

  • Visibility
  • Forking
  • Pull/Merge Requests
  • Peer Review
  • Release Early, Release Often
  • Testing
  • Continuous Integration
  • Documentation
  • Issue Tracking

This book states that strategizing and communicating are important steps in managing enterprise open source effectively: “To establish open source software as a major driving force for software development, your company needs to develop business-level objectives and fully identify any constraints faced for the use of open source software. The goal is to establish consensus and communicate business rationale behind new policies. This book will help you develop a strategy that transforms your efforts from a defensive approach that reacts to open source software to offensive market leadership that is fueled by strong open source engineering.”

Lessons Learned

The “Lessons Learned from Two Decades of Enterprise Open Source Experience” section notes that one of the most important steps an enterprise can take is to encourage a cultural shift surrounding open source.

“You’ll need to lead a cultural shift from traditional software development practices to a more open and collaborative mindset. Internal company dynamics need to be favorable to open source efforts. As an open source leader inside your organization, you will face challenges in terms of funding resources, justifying ROI, getting upstream focus, and so forth. These challenges often require a major shift in mindset and a lot of education up the chain.”

Download your free copy of Enterprise Open Source: A Practical Introduction now.

The key to open source compliance is knowing what’s in your code, right down to the exact versions of the components, says Ibrahim Haddad.

Companies across all industries use, participate in, and contribute to open source projects, and open source compliance is an integral part of the use and development of any open source software. It’s particularly important to get compliance right when your company is considering a merger or acquisition. The key, according to Ibrahim Haddad, is knowing what’s in your code, right down to the exact versions of the open source components.

Ibrahim Haddad

Haddad often writes about compliance with the aim of simplifying what can be a complex and daunting process. Recently, Haddad, who is Vice President of R&D and Head of the Open Source Group at Samsung Research America, wrote Open Source Audits in Merger and Acquisition Transactions, a free ebook from The Linux Foundation. In the book, Haddad provides a practical guide to open source audits in merger and acquisition (M&A) transactions and offers tips for improving general open source compliance preparedness. We reached out to Haddad to understand more about the importance of compliance and audits in the open source world.

The Linux Foundation: A common perception is that using open source software means you do not have to worry about negotiating licenses, fees, and other complications associated with proprietary software. So, why should enterprises care about compliance?

Ibrahim Haddad: It is true that open source software has to a large extent simplified the process of software procurement. The traditional procurement model for proprietary software has always been heavy on the front end, as it involves trial and evaluation, negotiation related to possible customizations, licensing terms, fees, and several other factors. With open source, it is still true that you should evaluate the software, compare it to other possible alternatives, and evaluate if the license of that software is in line with how you plan to use it.

However, this is generally the extent of the initial effort. Once you ship a product, you then must demonstrate that you have respected the terms of the licenses attached to the open source components. That may mean providing a written office, publishing all copyright, attribution and license notices, and/or making available source code including any modifications you have introduced.  Obligations will vary based upon the terms of the open source license and how the code is used.

Companies must make open source compliance an engineering priority, as it is the best way to display their fulfillment of the license obligations. If a company is unable to demonstrate compliance and is unwilling to become compliant when challenged, the owners of the copyright on the open source software may decide to revoke the license.  The company could easily end up in a very difficult space where they may need to recall products and re-engineer around the code.

The Linux Foundation:  In my opinion, there are two primary aspects of Open Source — consumption and contribution. What role does compliance play in these cases? 

Haddad: I agree that the two primary aspects of open source are using and contributing. An enterprise can choose open source components and deploy them in their software stack. An enterprise can also decide that certain open source components are strategic to their products and contribute to these components, inject new dynamics in the projects, and steer them in a technical direction that is favorable to their products.

In the first case, compliance is a critical aspect of the “usage” model. A product or software stack that incorporates open source and is being made commercially available must demonstrate open source compliance. This is essential, and no enterprise should risk their profitability with incomplete compliance.

In my mind, contributing involves a different type of compliance than what is implied through the “usage” model. My recommendation and actual practice for code contribution is to follow an internal process that includes:

  1.     Scan source code intended for contribution to identify its origin and license.
  2.     Ensure you have the rights to contribute it under the project’s license.
  3.     Get your company’s approval for that contribution – and in the case of CLA, also getting approval to sign the CLA on behalf of your company before making the contribution.

I will explain my logic for these three steps:

On 1: It is necessary to identify all the code planned for contribution, and any licenses upon it. This step will also help you identify any possible incompatibilities between the licenses of the contribution and the target project. If the code you plan to contribute and the target project have incompatible licenses, or if you discover the code was copied from somewhere else, then you will need resolve the issue before your code submission.

On 2: This step ensures that you are not accidentally open sourcing third-party proprietary code.  This can be a problem in big internal projects with legacy code.

On 3: In most companies, ongoing contributions require approval following whatever internal process that has been set in place. That process should also address who can sign and submit a CLA as an individual contributor (employee of company X), or on behalf all contributors from company X.

Following these steps, you will be able to significantly minimize legal or compliance risks resulting from using or contributing to open source projects.

The Linux Foundation: If you do serve external customers, but you are not shipping any code, then you are simply offering a service. Do you have to be compliant in that case also?

Haddad: I would like to highlight two use cases here. The first is using open source software in your company for internal purposes: IT, testing, evaluation, etc. In such cases, there are no compliance requirements because it is never distributed.

The second case involves offering online (or web) services to clients using software that incorporates open source software. In that specific case, some licenses such as the GNU Affero General Public License (AGPL) do require companies to comply with the license obligations, even if the software itself never changes hands.

Therefore, regardless of how you use the open source software, I am a strong believer in the value of going through a compliance process to identify open source code, applicable licenses and usage models. I believe that good compliance practices are also good engineering practices.

The Linux Foundation: What was the motivation behind writing Open Source Audits in M&A Transactions? Who is the main audience of the book?

Haddad: I mainly had three motivations for writing this book:

  • The first motivation was the lack of documentation around the open source audit process that must take place prior to a merger or an acquisition. If you search online for documentation on this topic, you will not find much outside of the advertisements from various compliance services providers.
  • The second motivation is saving time. I get many inquiries about this process and having such a document is great to share when I am asked about it. In addition, I thought that if I am able to produce a document that highlights the process and explains it, maybe this will encourage others to write about it and share their experiences and recommended practices.
  • The third motivation was related to innovation in the compliance space that was not getting the attention it deserves. For example, the “Blind Audit” model from FOSSID AB where your compliance service provider can complete the audit without having access or even looking at the source code. This level of privacy and security is highly desirable.

The target audience of the book is anyone interested or involved in ensuring open source compliance. Although the ebook focuses on the specific process during an M&A transaction, it offers various recommendations on how to be compliant. These recommendations apply to any company that uses open source. Therefore, if you are an engineer, legal counsel, someone who works in software procurement, or anyone who is involved in open source in their organization, then you will get something out of reading the book.

The Linux Foundation: Compliance can be a challenge when you use a lot of open source projects with many license mixes. What practices would you suggest to companies to help them with their compliance efforts?

Haddad: I think we have come a long way in the open source compliance domain. Back in the early 2000s, open source compliance was really misunderstood, in large part because it was a developing domain. Today, open source compliance is well understood and most companies have a good enough understanding of the licenses and what needs to be done to stay in compliance. My view is that the top challenges are related to scale and building compliance into the software supply chain.

Of the two challenges I just mentioned, scale is the hardest, and it covers multiple dimensions. One is scaling at the project level, when you are dealing with hundreds of open source components and potentially thousands of open source snippets. The other dimension is scaling to address the complexities of a product with an arbitrary number of licenses involved. The way to deal with that is twofold: process and automation. In November 2016, The Linux Foundation published an ebook entirely dedicated to this topic: Open Source Compliance in the Enterprise.  It offers a guide for how best to use open source code in products and services and participate in open source communities in a responsible way.

The second challenge is building trust in the software supply chain, and there are several initiatives that are geared for that purposes. The most prominent projects are OpenChain and SPDX, both hosted at The Linux Foundation. The SPDX initiative has created a standard method to communicate software components, licenses and copyright information associated with the software. In addition, the OpenChain project is offering a systematic approach for companies to build their compliance efforts and be in conformance of various levels of compliance. They are also offering a training curriculum that companies can adopt and customize for their internal use.

For organizations that rely heavily on open source for their products/software stacks, it is essential for them to participate in these efforts. When you look at the errors that lead to non-compliance, we’ve notice that large companies have significantly improved their internal compliance practices. However, many compliance issues are still being propagated via the software supply chain, from upstream suppliers whose compliance practices are not as rigorous. The final product integrator is responsible for compliance obligations even if they did not create the code they distribute, so this is a relevant issue throughout the entire supply chain. Both SPDX and OpenChain help minimize the compliance gap and ensure proper compliance when software changes hands.

The Linux Foundation: What would be your top recommendations for companies who are major consumers of open source software but are not well versed in ensuring compliance?

Haddad: I have one recommendation: know what is in your code, right down to the exact versions of the open source components. This statement sounds simple but it involves setting up a compliance policy and process, investing in tooling and automation, training employees, and assigning someone (or a small team) to oversee the overall effort.

Also remember that open source compliance is an ongoing process, not a destination. Maintaining good compliance practices enables companies to be prepared for a possible acquisition, sale, or product or service release. For this reason, companies are highly encouraged to invest in building and improving upon their open source compliance programs.

There are also many resources available, so please check them out:

  • Open Source Compliance in the Enterprise is a practical guide for enterprises on how to best use open source in products and services in a legal and responsible way.
  • Practical GPL Compliance is a guide for startups, small businesses, and engineers, particularly focused on complying with the versions of the GNU General Public License (GPL).
  • OpenChain Curriculum is designed to help organizations meet the training and process requirements of the OpenChain Specification. It can also be used for general open source training.
  • The Linux Foundation offers a free open source compliance course for developers.

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.


There are generally two teams involved in achieving open source license compliance within an organization: a core team and an extended team of individuals from various departments.

No individual, no matter how adept, can successfully implement open source compliance across an entire organization. Keeping track of where and how open source code is used, approved, and shipped must be a cross-functional team effort.

From core engineering and product teams, to legal counsel and upper management, compliance involves individuals in many roles from various departments throughout the company.

In this article, highlighting a chapter of The Linux Foundation ebook Open Source Compliance in the Enterprise by Ibrahim Haddad, we’ll give an overview of the roles and responsibilities that any open source compliance program should include. Together, these are the individuals who will make sure your company stays current and compliant with the open source licenses in the code you use and ship.

3 Key roles on an open source compliance team

There are generally two teams involved in achieving compliance: a core team and an extended team, with the latter typically being a superset of the former. The core team, often called the Open Source Review Board (OSRB), consists of three key representatives from engineering and product teams, one or more legal counsels, and the compliance officer/ open source program office manager.

Legal representative: A legal counsel or paralegal, depending on the task. Reviews and approves usage, modification, and distribution of free and open source software (FOSS); provides guidance on licensing; contributes to compliance training; reviews and approves open source notices; and more.

Engineering and product team representative: Follows compliance policies and processes; requests approval to use (and/or contribute) to open source projects; responds quickly to all questions; conducts design, architecture, and code reviews; prepares software packages for distribution; and more.

Open source compliance officer, manager, or director: Not necessarily a dedicated resource, this person drives all compliance activities; coordinates source code scans and audits and distribution of source code package; contributes to compliance training and creation of new tools to facilitate automation and FOSS discovery in a dev environment; and more.

Others involved in open source compliance

The extended team includes a larger group of individuals from across multiple departments who contribute on an on-going basis to the open source compliance efforts. However, unlike the core team (in substantial organizations), members of the extended team are working on compliance only on a part- time basis, based on tasks they receive from the core review board. Roles and responsibilities include:

  • Documentation – Includes open source license information and notices in the product documentation including license text, written offer, copyrights and attribution notices
  • Supply Chain – Mandates third-party software providers to disclose open source in licensed or purchased software components and assists with ingress of third-party software bundled with and/or including open source software
  • Corporate Development – Requests open source compliance be completed before a merger or acquisition, or when receiving source code from outsourced development centers or third-party software vendors.
  • IT – Provides support and maintenance for the tools and automation infrastructure used by the compliance program and creates and/or acquires new tools based on OSRB requests
  • Localization – Translates basic information in target languages about open source information related to the product or software stack
  • Open Source Executive Committee (OSEC) – Typically includes executives representing Engineering and Legal. The OSEC reviews and approves proposals to release IP and proprietary source code under an open source license.

Read other articles in this series:

The 7 Elements of an Open Source Management Program: Strategy and Process

The 7 Elements of an Open Source Management Program: Teams and Tools

How and Why to do Open Source Compliance Training at Your Company

Basic Rules to Streamline Open Source Compliance For Software Development

How to Raise Awareness of Your Company’s Open Source License Compliance

Establishing a Clean Software Baseline for Open Source License Compliance

Ibrahim Haddad (Ph.D.) is Vice President of R&D and the Head of the Open Source Group at Samsung Research America. He is responsible for overseeing Samsung’s open source strategy and execution, internal and external R&D collaborations, supporting M&A and Corporate VC activities, and representing Samsung towards open source foundations. He is currently serving as Vice President of the Open Connectivity Foundation and the Director on the Board representing Samsung Electronics.

open source reading list

Check out the list of 21 must-read books for open source program managers, recommended by members of the TODO Group.

Is your organization looking to build out an open source program or are you already managing one? If so, you’re probably already considering the kinds of tools and guidance that can make your program a holistic success. That is why, in this article series, we have been covering tools for managing open source programs and providing advice from leading experts.

Now, to take your program to the next level, we offer a free guide containing an essential open source reading list. This list can help any organization launch and maintain a thriving open source program.

Specifically, the guide provides 21 must-read books for open source program managers, recommended by members of the TODO Group. These books can help your organization build a strong foundation and avoid missteps in developing your open source program.

Advice from experts is key to running a successful open source program. “It took us years of constant discussion and negotiation to break from the traditional IT setup into a more flexible environment that supports our open source development,” said Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research. “We made it work for us and with enough persistence you also can make it work for your open source team.”

The book in this list provide expert advice on how to get your open source tool collection started, how to approach issues such as licensing and governance, and much more. “A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences,” notes Haddad.

Here are just some of the titles on the essential open source reading list:

Codev2 by Lawrence Lessig: A classic treatise on Internet regulation and the role of code as a form of law

New Frontiers in Open Innovation by Henry William Chesbrough: A thorough examination of research conducted to date on open innovation

Managing 3rd-Party Software Licenses by Giles Middleton: Covers not only license types, but methods of handling and tracking components and their licenses

Open Source for Business: A Practical Guide to Open Source Software Licensing by Heather Meeker: A downloadable ebook on licensing and legal terms

Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel: From your mission statement to project fruition, don’t miss these guidelines

The Art of Community: Building the New Age of Participation by Jono Bacon: Sound advice from one of the most respected of all community managers

The free reading list can help you navigate all kinds of common open source-related challenges. It covers everything from evaluating ROI to optimizing practices, and it explores how to seamlessly and safely leverage existing tools to complement your open source creations. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are targeted at organizations running open source programs or considering them.

The guides are available now and they can help you run an open source program office where open source is supported, shared, and leveraged. They can also, in many instances, keep your program out of trouble, where trouble can range from licensing skirmishes to lawsuits.

These free resources were produced based on expertise from open source leaders, including advice from many members of The TODO Group, which includes Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Red Hat, Salesforce, and Samsung.

Also, don’t miss the previous articles in the series:

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

Participating in Open Source Communities

Using Open Source Code

Launching an Open Source Project: A Free Guide

Practical Ways to Improve Your Open Source Development Impact

Linux is hot right now. Everybody is looking for Linux talent. Recruiters are knocking down the doors of anybody with Linux experience, and there are tens of thousands of jobs waiting to be filled. But what if you want to take advantage of this trend and you’re new to Linux? How do you get started?

  1. Install Linux  It should almost go without saying, but the first key to learning Linux is to install Linux. Both the LFS101x and the LFS201 courses include detailed sections on installing and configuring Linux for the first time.
  2. Take LFS101x If you are completely new to Linux, the best place to start is our free LFS101x Introduction to Linux course. This online course is hosted by, and explores the various tools and techniques commonly used by Linux system administrators and end users to achieve their day-to-day work in a Linux environment. It is designed for experienced computer users who have limited or no previous exposure to Linux, whether they are working in an individual or enterprise environment. This course will give you a good working knowledge of Linux from both a graphical and command line perspective, allowing you to easily navigate through any of the major Linux distributions.
  3. Look into LFS201 Once you’ve completed LFS101x, you’re ready to start diving into the more complicated tasks in Linux that will be required of you as a professional sysadmin. To gain those skills, you’ll want to take LFS201 Essentials of Linux System Administration. The course gives you in-depth explanations and instructions for each topic, along with plenty of exercises and labs to help you get real, hands-on experience with the subject matter.

    If you would rather have a live instructor teach you or you have an employer who is interested in helping you become a Linux sysadmin, you might also be interested in LFS301 Linux System Administration. This course includes all the same topics as the LFS201 course, but is taught by an expert instructor who can guide you through the labs and answer any questions you have on the topics covered in the course.

  4. Practice! Practice makes perfect, and that’s as true for Linux as it is for any musical instrument or sport. Once you’ve installed Linux, use it regularly. Perform key tasks over and over again until you can do them easily without reference material. Learn the ins and outs of the command line as well as the GUI. This practice will ensure that you’ve got the skills and knowledge to be successful as a professional Linux sysadmin.
  5. Get Certified After you’ve taken LFS201 or LFS301 and you’ve gotten some practice, you are now ready to get certified as a system administrator. You’ll need this certification because this is how you will prove to employers that you have the necessary skills to be a professional Linux sysadmin.

    There are several Linux certifications on the market today, and all of them have their place. However, most of these certifications are either centered on a specific distro (like Red Hat) or are purely knowledge-based and don’t demonstrate actual skill with Linux. The Linux Foundation Certified System Administrator certification is an excellent alternative for someone looking for a flexible, meaningful entry-level certification.

  6. Get Involved At this point you may also want to consider joining up with a local Linux Users Group (or LUG), if there’s one in your area. These groups are usually composed of people of all ages and experience levels, so regardless of where you are at with your Linux experience, you can find people with similar skill levels to bond with, or more advanced Linux users who can help answer questions and point you towards helpful resources. To find out if there’s a LUG near you, try looking on, check with a nearby university, or just do a simple Internet search.

    There are also many online communities available to you as you learn Linux. These sites and communities provide help and support to both individuals new to Linux or experienced administrators:

7. Learn To Love The Documentation

Last but not least, if you ever get stuck on something within Linux, don’t forget about Linux’s included documentation. Using the commands man (for manual), info and help, you can find information on virtually every aspect of Linux, right from within the operating system. The usefulness of these built-in resources cannot be overstated, and you’ll find yourself using them throughout your career, so you might as well get familiar with them early on.

Interested in learning more about a career in system administration? Check out our free ebook “Future Proof Your SysAdmin Career

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.


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.


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.


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.


Read the first article in this series:

An Introduction to Open Source Compliance in the Enterprise

In today’s rapidly evolving markets, companies that consistently innovate, most quickly and at the least cost, will win. And, as you’ve seen in our ongoing series, using Open Source Software (OSS) enables rapid, low-cost innovation. But it can also introduce operational challenges and legal risks.

We’re at a point now that OSS has become such a mainstream phenomenon that not using open source almost certainly places your organization at a disadvantage. So you must learn how to navigate the challenges and risks in order to remain competitive.

“Open source is ubiquitous, it’s unavoidable… having a policy against open source is impractical and places you at a competitive disadvantage.” — Gartner.

In this post, we’ll explore how open source became the de facto way to build software. Then we’ll cover the challenges this new method of software development has introduced for organizations. You can download the entire series now in our Fundamentals of Professional Open Source Management sample chapter.

The open source development revolution

From innovative beginnings in academic research and the GNU tools project started roughly four decades ago, OSS has grown into a major phenomenon that has reshaped multiple industries. Today, there are more than 1.5 million unique open source projects offering terabytes of working code to software developers. The availability of these resources and the trends toward modular software and software reuse have radically changed the way most companies develop software.

Not so long ago, we developed most of our software products in-house. We might have used a few third-party components for connectivity to other systems or some specialized processing, but these were acquired through a carefully controlled procurement process.

Today, we develop more complicated software faster by using open source components freely available on the Internet. Most of our activity has shifted from specifying and implementing our own custom software to integrating already available working pieces. We only code the parts that are truly unique to our application.

But now, instead of a few carefully controlled code acquisitions, we are repeatedly downloading code from the Internet to evaluate, prototype, and integrate. Although this approach speeds up development, it has created some significant new challenges.

6 OSS operational challenges

While using OSS brings many advantages, it can introduce risks and ​additional operational complexity to software development lifecycles.

● Organizations must deal with many new software sources, including commercial and noncommercial suppliers – some use OSS acquired from hundreds of different sources.

● The cornucopia of available open source components drives a higher volume of third-party software acquisition decisions. Where are these decisions being made? Many developers are not qualified to consider all of the necessary aspects including software license analysis, but a heavy-weight process like the old procurement approach is too expensive and time consuming to apply to the new volume of acquisitions.

● Integration of a large number of third party components can create complexity. One area of complexity is software version consistency across multiple interdependent stacks of code.

● Open source projects run the gamut from amateur exercises to professionally developed and tested releases. Your organization must ensure that appropriate levels of quality are chosen for each application.

● How will your organization obtain technical support and updates for all of these different open source components? Healthy open source communities provide excellent support and maintenance, but the self-service model of open source requires consistent participation on the part of your developers.

● Commercial relationships can reinforce your requirements with suppliers by adding a financial incentive, but influencing open source project direction is dependent upon multiple aspects of participation.

In our final article, we’ll discuss the legal issues and risks that come when companies incorporate OSS into their own software projects. And we’ll introduce the spectrum of open source license types with which organizations should become familiar.

Open source software management

Read more:

What Is Open Source Software?

Using Open Source Software to Speed Development and Gain Business Advantage

6 Reasons Why Open Source Software Lowers Development Costs

Why Using Open Source Software Helps Companies Stay Flexible and Innovate

One of a company’s first challenges when starting an open source compliance program is to find exactly which open source software is already in use and under which licenses it is available.

This initial auditing process is often described as establishing a clean compliance baseline for your product or software portfolio. This is an intensive activity over a period of time that can extend for months, depending on how soon you started the compliance activities in parallel to the development activities.

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 achieve initial license compliance.

4 Activities to Establish Baseline Compliance

Organizations achieve initial compliance through the following activities:

• Early submission and review of open source usage requests.

• Continuous automated source code inspection based on a predefined interval of time for all source code.

• Continual source code scans, including code received from third-party software providers, to intercept source code that was checked into the code base without a corresponding compliance ticket. Such source code scans can be scheduled to run on a monthly basis, for instance.

• Enforced design and architectural review, in addition to code inspections, to analyze the interactions between open source, proprietary code, and third party software components. Such reviews are mandatory only when a given interaction may invoke license compliance obligations.

Compliance on Future Revisions

If a company fails to establish baseline compliance, it is almost guaranteed that future revisions of the same product (or other products built using the initial baseline) will suffer from compliance issues. To guard against such scenarios, companies should consider establishing other elements of a complete open source management program, including the following:

• Offer simple but enforced policies and lightweight processes.

• Include compliance checkpoints as part of the software development process as it moves from concept into shipping

a product or software stack. Ideally, with every development milestone, you can incorporate a corresponding compliance milestone, ensuring that all software components used in the build have parallel and approved compliance tickets.

• Ensure availability of a dedicated compliance team.

• Utilize tools and automation to support efficient processing of compliance tickets.

There are several challenges in maintaining open source compliance, similar to those faced when establishing baseline compliance. In fact, many of the steps are identical, but on a smaller, incremental scale. We’ll cover recommendations for maintaining compliance in the next article in this series.

Open source compliance

Read the other articles in this series:

The 7 Elements of an Open Source Management Program: Strategy and Process

The 7 Elements of an Open Source Management Program: Teams and Tools

How and Why to do Open Source Compliance Training at Your Company

Basic Rules to Streamline Open Source Compliance For Software Development

How to Raise Awareness of Your Company’s Open Source License Compliance

Communication is one of the seven essential elements to ensure the success of open source license compliance activities. And it’s not enough to communicate compliance policies and processes with executive leadership, managers, engineers, and other employees. Companies must also develop external messaging for the developer communities of the open source projects they use in their products.

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 communicate open source license compliance both internally and externally.

Internal Communication

Companies need internal compliance communication to ensure that employees are aware of what is involved when they include open source in a commercial software portfolio. You also want to ensure that employees are educated about the company’s compliance policies, processes, and guidelines. Internal communications can take any of several forms:

  • Email communication providing executive support and of open source compliance activities

  • Formal training mandated for all employees working with open source software

  • Brown-bag open source and compliance seminars to bring additional compliance awareness and promote active discussion

  • An internal open source portal to host the company’s compliance policies and procedures, open source related publications and presentations, mailing lists, and a discussion forum related to open source and compliance

  • A company-wide open source newsletter, usually sent every other month or on quarterly basis, to raise awareness of open source compliance

External Communication

Companies also need external compliance communications to ensure that the open source community is aware of their efforts to meet the license obligations of the open source software they are using in their products.

External communications can take several forms:

• Website dedicated to distributing open source software for the purpose of compliance

• Outreach and support of open source organizations which help the company build relationships with open source organizations, understand the roles of these organizations, and contribute to their efforts where it makes sense

• Participation in open source events and conferences. This can be at various levels ranging from sponsoring an event, to contributing presentations and publications, or simply sending developers to attend and meet open source developers and foster new relationships with open source community members.

Open Source Compliance

Read the other articles in this series:

The 7 Elements of an Open Source Management Program: Strategy and Process

The 7 Elements of an Open Source Management Program: Teams and Tools

How and Why to do Open Source Compliance Training at Your Company

Basic Rules to Streamline Open Source Compliance For Software Development