Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include spearheading the licensing team that elevated Open Invention Network into the largest patent non-aggression community in history, establishing the leading professional network of Open Source legal experts and aligning stakeholders to launch both the first law journal and the first law book dedicated to Open Source.
Shane has extensive knowledge of Open Source governance, internal process development, supply chain management and community building. His experience includes engagement with the enterprise, embedded, mobile and automotive industries.
What is the OpenChain Project, and how has SAP adopted the corresponding standard? In my current role in the SAP Open Source Program Office, I was involved in several activities around SAP’s OpenChain certification and would like to share some insights in this blog post.
With numerous open-source licenses available (more than a hundred licenses approved by the OSI) and new ones emerging constantly, it is important for companies that manage open-source software to fulfill all legal requirements and obligations. The OpenChain Project, launched in 2016 under the umbrella of the Linux Foundation, aims to support companies with their license compliance across the open-source software supply chain and has been adopted by a wide range of companies and a broad community. The mission of OpenChain is “a supply chain where open source is delivered with trusted and consistent compliance information” (more). In 2020 it had matured enough to be accepted as an ISO standard, which runs under the name of ISO/IEC 5230 and is considered the International Standard for open-source license compliance. Global and local working groups address the needs of different industries and regional adopters and help to improve and enhance the project continuously. Anybody is invited to freely use the existing OpenChain content, whether training material, policy templates, or developer guidelines. There are more than 1000 reference documents, such as how-to guides available on GitHub including reference guides for software supply chain security.
In March 2022, SAP finished its certification for ISO/IEC 5230 conformance. As mentioned in the related press release this was “the first time an enterprise application software company has undergone whole entity conformance” meaning that SAP as an entire company was certified. What was SAP’s experience with the OpenChain certification? What were the prerequisites and how much effort did it take?
What better way to celebrate our 1,000 news post on the OpenChain website than to see what other people are saying about us? Check out this post by Dan Whiting over on the official LF blog:
[There] are also challenges in this space, with a good example being the question of how to address licensing. There are A LOT of types of licenses that can apply to a piece of software/code. Each license needs to be understood and tracked with each piece of software it is included in for an organization to ensure nothing is missed. This can quickly multiply into a significant catalog that requires lots of manual work. On top of that, you also need to provide that license information to each of your customers, and they will have their own system and/or processes for providing that information to them and making sure it is up-to-date with each new version of the software.
You can see where this can quickly consume valuable staff resources and open doors to mistakes. Imagine the possibility of a standard way to track and report the licenses so your teams don’t need to worry about all of the digital paperwork and can instead focus on innovation and adding value to you and your customers.
This is exactly the problem a team of lawyers and governance experts sought to fix back in 2016 and created the OpenChain Project to do just that. They asked, what are the key things for open source compliance that everyone needs, and how do we unify the systems and processes. They envisioned an internationally accepted standard to track and report all of the licenses applicable to a software project. The end result is a more trustable supply chain where organizations don’t need to spend tons of time checking compliance again and again and then remediating.
The OpenChain M&A Summit 2022 brings together key law firms and service providers helping clients with M&A. You will come away from this event with a clearer understanding of global trends around open source mergers and acquisitions. Free and open to everyone.
Timing
This event takes places at 14:00 UTC on April 28th and runs for around three hours. That translates to:
07:00 PDT
12:00 EDT
16:00 CEST
19:30 IST
22:00 CST
23:00 KST
23:00 JST
Agenda
An Overview of A Typical M&A With OpenChain Leon Schwartz, GTC Law
M&A From The Perspective Of Security Jan Thielscher, EACG
Checking Compliance With FOSSmatrix Hendrik Schottle, Osborne Clark
Sustainability Of Open Source Licenses Dr. Andreas Kotulla, Bitsea
Specific M&A Transaction Case Study Marcel Scholze, PwC
The OpenChain Project released a Security Assurance Reference Guide in August 2021. Feedback from the community expanded this into its current form: a Security Assurance Reference Specification (Release Candidate 1 2022-03-28). At the end of June 2022 the OpenChain Steering Committee will decide if this Release Candidate:
Becomes a sister standard to OpenChain ISO/IEC 5230
Becomes an optional component of OpenChain ISO/IEC 5230
Remains a reference specification
This is an important moment for the OpenChain Project, explicitly highlighting our work beyond open source license compliance. Your input is most welcome to help inform our steering committee.
Please open Issues on our GitHub here to provide feedback:
More Information From The Introduction Of The Reference Specification Document:
The OpenChain Project is working towards a supply chain where open source is delivered with trusted and consistent compliance information. We maintain OpenChain ISO/IEC 5230:2020, the International Standard for open source license compliance. Adjacent to this the project maintains a large international community, extensive reference materials, and working groups addressing various domain issues. We support discussions around security, export control, M&A and other topics.
OpenChain ISO/IEC 5230:2020 is a process management specification that identifies inbound, internal and outbound inflection points where a process, policy or training should exist. The identification and tracking of software used and deployed is an inherent part of getting this right, and this also allows our standard to also be useful for security or export control.
The OpenChain Project community noticed that OpenChain ISO/IEC 5230:2020 was being used quite often in deployment discussions and we wanted to support our broader community around these use-cases. The reference specification you are now reading is focused on the security domain. It is intended to identify and describe the key requirements of a quality Security Assurance Program in the context of using Open Source Software. This early iteration of the document focuses on a narrow subset of primary concern: checking Open Source Software against publicly known security vulnerabilities like CVEs, GitHub/GitLab vulnerability reports, and so on.
This document focused on the “what” and “why” aspects of a quality Security Assurance Program rather than delving into to “how” and “when.” This is a conscious decision to ensure flexibility for companies of any size and in any market to use this reference specification. This approach, along with the types of processes identified, is built on more than half a decade of practical global feedback around the creation and management of such programs. The result is that a company can frame a program that precisely fits their supply chain requirements, scoped to a single product or a complete legal entity, and take this solution to market quickly and effectively.
The scope of this reference specification may expand over time based on community feedback.
This introduction describes the reference specification’s purpose. Section 2 defines key terms used throughout this document. Section 3 defines the requirements that a Program must satisfy to achieve a core level of Security Assurance. Each requirement consists of one or more verification materials (i.e., records) that must be produced to satisfy the requirement. Verification materials are not required to be made public, though an organization may choose to provide them to others, potentially under a Non-Disclosure Agreement (NDA).
This reference specification is licensed under Creative Commons Attribution License 4.0 (CC-BY-4.0). Because it takes the form of a Reference Specification and is therefore intended to fit into the mental model applied to specification creation, it is not designed to be modified outside of the formal editing track. You can take part in editing this document via the OpenChain Project bi-weekly calls. You can learn about joining these calls and our other activities here:
The OpenChain Industry Survey 2022 covers a big topic: the global status of corporate engagement and management of open source. We are considering this from a “strategy” perspective rather than a “development” perspective. Our goal is to help inform project, product and supply chain decisions in the year ahead.
Join us on April 26th at 3:00 pm CEST/1:00 pm UTC/9:00 am EDT/10:00 pm JST for a webinar with Shane Coughlan, OpenChain General Manager at the Linux Foundation, and Peter Giese, Head of the SAP Open Source Program Office, about key requirements of a quality open source compliance program. With his extensive knowledge of open source governance and process development Shane will explain what is important for a healthy open source environment in organizations, while Peter will talk about SAP’s experience getting ready for the OpenChain certification to help to establish trust and reliability among all the participants in software supply chains at SAP.
Speakers:
Shane Coughlan | OpenChain General Manager at the Linux Foundation
Peter Giese | Head of the SAP Open Source Program Office
