The OpenChain Interview Series continues with a deep-dive into the strategic background of creation and release of IEC/ISO 5230, the International Standard for open source license compliance. We are very lucky to welcome Max Sills, ex-Google and currently Square, to share part of his multi-year journey in building one of the largest governance communities in the world.
Q (Shane): Let’s dive straight in. How does OpenChain ISO 5230 reduce friction in making deals and why did you get involved?
A (Max): Put simply, ISO 5230 identifies the minimum number of things you need to have a quality open source compliance program. It sets out common terms for the obligations a company might incur due to using open source software, and defines reasonable, industry-standard risk mitigation procedures. Easy stuff, like track the licenses of the software you are using. Train your employees on IP basics. Understand and comply with distribution obligations.
Now the scale of my involvement is a much longer story. It started with my general frustration at the length of time it took to close commercial deals with open source issues. 15 deals in the same month might present identical value and compliance profiles, but I’d get back 15 different perspectives from the other side on how open source software was used, what was permissible, etc.
Worse, sometimes parties would promise anything you asked, but fail to be able to produce a bill of materials, indicating deeper, structural problems with their use of open source.
Q: Unpacking that, can you expand on the scale of your involvement in ISO 5230 and how it differed from what we might term “general industry engagement”?
A: I joined the Open Chain governing board during a key moment of its evolution. The was a transition period from around 2017 to end 2020 where ISO 5230 gained momentum as a de facto industry standard and then converted into a formal international standard. At the time I was leading Google’s open source legal practice, and I worked with friends from Facebook and Uber to help with this process.
We represented a slightly different mix compared to the existing board of consumer electronics, automotive and infrastructure companies already on the board. The board represented a really nice mix of diverse industries, with unique compliance requirements. I came in thinking OK, let’s get this standard out there and into our contract templates so I can waste less time. I had no idea about the serious and different challenges faced by heavy industry and automotive. It made us all reflect on common goals. We balanced commercial expediency with methodical and careful planning.
Q: Was this a period of risk for the project and standard?
A: The transition from de facto standard to formal international standard was all about momentum. Standards live and die on real world deployment. This was a critical factor in getting ISO 5230 to the place where it could reduce friction on a substantial number of deals.
Q: Two questions here. The first relates to the diversity of companies on the OpenChain governing board. Were there any tensions during this formative moment? The second question relates to implementation. What did traction mean in the context of ISO 5230 in the 2017 to 2020 period?
A: The OpenChain Project has a big board. About 20 companies. The initial board membership was legendary. It had decision makers from member companies, so things moved fast. I learned a lot from that board. Dave Marr from Qualcomm taught me Robert’s Rules of Order, for which I thank him every time I see him.
Given the size of the board and the vastly different industries of the member companies, it may be surprising to learn that there was a clear, shared vision throughout. Ultimately open source requires the same governance approaches in every industry, and our mission in OpenChain was always crystal clear. There was agreement on the strategic approach. When we turn to implementation, naturally everyone took their own business sector, culture and requirements into account. However, the overarching theme was clear. Educate the supply chain. Include ISO 5230 in procurement discussions. Use the standard as an optic to judge quality in open source compliance processes.
Q: What was the greatest challenge you had to address regarding ensuring the success of ISO 5230?
A: As companies representing new sectors entered the OpenChain ecosystem – like telecommunications, defense and aviation – it was important to continually refine and improve the supporting material and project resources. Everyone came to the table with their own perspective, and it was important to be sensitive to that. While we all had the same basic requirements that ISO 5230 could address as a process standard, it had to align against existing industry processes without friction.
We had to be humble, put our needs aside, and listen to the other members. ISO 5230 is designed to slot into workflows rather than overturn them, and that messaging needed to be matched by a welcoming community at every turn. Its best design feature is that ISO 5230 represents what most people would agree needs to be done anyway, but didn’t have a common language for until now.
Q: Can you give a concrete example of ISO 5230 being used to reduce friction in deals?
A: Sure. First, there was this new reality of how open source could be addressed in procurement contracts. Instead of pages of bespoke language being required around open source compliance you could use one sentence. “Be ISO 5230 conformant,” or “I promise that we are ISO 5230 conformant”. We rolled it out on a few deals to test the market – the impact was immediate. We were immediately cutting a week from our deals.
Second, now there was a strategic litmus test that could be applied more broadly to deals. Beyond the paper contract, why were we doing business with the company? What were our risks and what did we expect? Was the company open source license conformant? If not, why not? Did this reduce our confidence in the deal? Put simply, when ISO 5230 was applied it made things simpler because we knew what to expect. When ISO 5230 was not applied, it meant we needed to pay extra attention, and that costs real money.
Q: To what extent is ISO 5230 used today?
A: Less than ISO 9001 but probably more than ISO 26262. More specifically, ISO 5230 is a young standard. It only converted from de facto to ISO standard in December 2020. The cross-industry traction has been and continues to be fantastic. That said, standardization and adoption is a marathon. It can take years for boilerplate in deal templates to disseminate across the market and to provide similar positioning to a quality standard like ISO 5230.
What I can say with certainty is that OpenChain has grown faster, and gone into the supply chain more deeply and more quickly than any of us thought was reasonably possible.The Board credits you with that the most, Shane. Your work evangelizing the standard has been amazing. It’s quickly becoming a norm in industries like automotive, and it’s untangling thorny governance issues in consumer electronics. Because it is so short and simple and supported by such a large community, it is incredibly easy to bring into negotiations, and that’s what we see happening increasingly around the world.
Q: Wrapping up, how does ISO 5230 fit into regulation-heavy industries like finance?
A: Elegantly. It’s a process quality standard like ISO 9001 or ISO 14001. It demonstrates that there is structure applied to open source compliance. It works in an unambiguous manner. Transacting software and services is the same in finance as it is in other industries: understand and mitigate your compliance risks, train your employees well, put scalable processes in place to double check policy is followed, and do as open source authors request when you redistribute their software. The least you can do when someone gives you something awesome for free, is to be polite and do what they ask in exchange.
Q: Thanks for your time today!
A: My pleasure!
