4. Broader Community
Main Work Groups:
● Specification (Spring 2016~)
● Education (Autumn 2020~)
Community Work Groups:
● Tooling (Summer 2019~)
● Export Control (Winter 2022~)
● Public Policy (Winter 2022~)
Special Interest Groups:
● Automotive (Summer 2019~)
● Telecom (Spring 2021~)
Regional User Groups
● Japan (Dec 2017~)
● Korea (Jan 2019~)
● India (Sept 2019~)
● China (Sept 2019~)
● Taiwan (Sept 2019~)
● Germany (Jan 2020~)
● UK (June 2020~)
● USA (Dec 2020~)
5. Platinum Member / Conformance Pending ISO/IEC 5230 + DIS 18974 Conformant
Platinum Member + ISO/IEC 5230 Conformant
Automotive Banking Cloud Consumer Industrial SaaS Service Silicon Telco
Example Verticals Impacted by OpenChain
This is a snapshot based on membership and select conformant organizations currently listed on our website. Total conformant numbers are far higher.
Example: PwC Survey shows 20% of companies in Germany with over 2,000 employees already used ISO/IEC 5230.
6. Trillions More In Market Value Touched
(Lockheed co-chairs our spec development)
This is a non-exhaustive list of participants on some of our community lists
9. We Started In 2016
● The OpenChain Project decided to create more trust in the supply chain by
fixing a long-term problem:
○ A lot of open source was used without proper licensing
○ This meant that it created huge legal risk
● The solution was to create a:
○ High level process standard
○ Simple, effective and suitable for companies of all sizes in all markets
○ Openly developed by a vibrant user community and freely available to all
● The standard was released as a “de facto” standard in 2016.
● It became OpenChain ISO/IEC 5230 in 2020, and was official the International
Standard for open source license compliance.
10. We Started Fixing More Problems in 2021
● The OpenChain Project noticed more and more companies using our standards
for license compliance in areas outside of procurement or internal process
○ For example, it was used as a tool in M&A negotiations.
○ And it was being used for security.
● We were particularly interested in the security use. Our standard covered many
of the same processes for security, but it was not designed for security.
● We decided to work on this by creating a guide about *how* to use our standard
for security, and also to consider whether we make a *new standard* for
11. Making A Standard Is Not Just Writing A Standard
● The decision to go from maintaining the ISO standard for open source license
compliance into making a family of standards is a larger strategic step than it
○ On one hand, a family of standards will be interrelated.
○ On the other hand, there will have to be many decisions about to build the
● Luckily OpenChain was ready in terms of project strategy:
○ Our vision is a trusted supply chain, not limited to licensing
○ Overall processes - we made a standard in a way that could be replicated for a
● Our approach was automatically suitable too. See next slide.
13. Making A Standard Can Be Fast
● Once we decided to go from a guide to a sister standard, actually writing the
material was pretty quick.
● When we finished it, it was also quick to submit to ISO.
● And ISO were quick to vote on it.
● We passed and are being published as OpenChain ISO/IEC 18974 in the next
couple of weeks.
● You will already find us on their website as OpenChain ISO/IEC PRF 18974
(that means we are approved and pending final publication)
14. Our Transformation Is Complete
● This is the point where I talk about what this means.
● The biggest picture is:
○ The transformation of the OpenChain Project from process management
around open source license compliance to more general critical open
source process management is functionally complete
● And… we are already working on a new contribution standard.