OpenTeams - The Future of Software
E20 podcast thumbnail


E20: Shane Coughlan, improving open source compliance processes with OpenChain

In this episode, I chatted with Shane Coughlan who leads the OpenChain project.

OpenChain is an initiative run by The Linux Foundation. Listen to this podcast to learn how your company can improve it’s open source compliance processes.

Some of the topics that we discuss include:

  • Patent families and the Open Invention Network which is the world’s largest patent licensing community
  • The benefits of using OpenChain as a process standard for open source software compliance
  • And how OpenChain helped companies like WindRiver and Toyota improve their bottom line.

Note: Open Source For Business is produced for the ear and designed to be heard, not read. We strongly encourage you to listen to the audio, which includes emotion and emphasis that’s not on the page. Transcripts are generated using a combination of speech recognition software and human transcribers and may contain errors. Please check the corresponding audio before quoting in print.


Henry: Shane thanks so much for joining me on the podcast.

Shane: It’s my absolute pleasure. I see I’ve been in a position of following a great roster of speakers performing, I hope to do it justice.

Henry: I’m sure you will do it justice. We haven’t actually had someone who’s been working in your field, so I’m really excited about what we’re going to discuss today. You’re currently the general manager of OpenChain, which is an initiative run by the Linux foundation. And prior to joining OpenChain, you were the Global Director of licensing at the Open Invention Network. Now I’ve heard of this before, because we had Amanda Brock on the podcast, so you’ve definitely know Amanda.

Shane: I’ve known her since she actually started in open source, so I think we’re going back about 13 years now.

Henry: Were you a canonical?

Shane: No, no. I was organizing a legal network for in-house and outside counsel in Europe and she was relatively early participants. Well, in the end, there’s about 300 people in the world involved in open source governance around legal matters, so they all know each other.

Henry: Everyone. I find that’s kind of the case for most of the disciplines in open source. But the Open Invention Network for those listening is the largest patent licensing community in the world for open source software. Now, I’m curious to learn a bit about the work that you did at this organization,

Shane: Open Invention Network started back in the middle of 2000s, and the basic concept was to address concerns about how large corporations and small corporations that own patents would act on core open source technology like Linux Kernel, and the solution was to have companies agree to non-aggression over these technologies. It wasn’t about giving away patents, but it was about saying in this space, we’re not going to leverage our patents in an aggressive manner.

When I joined OIN in late 2009, there were 59 companies in the cross license agreement. And by the time I finished in late 2015, we’d scaled to almost 2000, now it’s well over 3000, so it just keeps on growing. Indeed, it’s a simple enough proposition. There’s no reason at all to be aggressive around core open source, and there’s lots of reasons to collaborate in that space and not to interrupt in any way.

Henry: By creating this non-aggression zone for companies to innovate, the Open Invention Network must bring confidence to those that are part of the network. But I can definitely imagine that before the network was established, companies would have wasted a lot of time and money on remediation and other processes. So, can you walk us through what that process looked like for companies before the group of people came together and said, okay, we’re actually not going to use patents against each other?

Shane: Well, I think we must distinguish between different jurisdictions. For instance, in the US, you’d have a situation where there’s essentially two things that can happen with patent infringement. One is unintentional infringement and the other is intentional. Intentional leaves to triple damages. It’s a very serious thing. And naturally, no company wants to do that.

So, the area which was gray really is unintentional infringement. What if company X happened to have a core operating system patent, and by using Linux, you infringe that. This is a hypothetical it’s never actually happened, but it was on the table. And every company addressed that in an individual manner, thinking about what’s our personal threat profile, what’s our patent portfolio that could push back and so on.

OIN gave a simple recipe just saying, okay, here’s how we fix the ecosystem. So it lifted the entire burden of, oh, I have to solve for this, and it became, this is how we do this as a community. And the dollar price for me is zero, [unclear04:58] which I’m pledging non-aggression is not where I plan to essentially monetize my patents.

A no brainer you could say, but it did take a few years before everyone coalesced around that because it’s a relatively new thing to have a massive cross-licensed community, not based on revenue, but rather based on saying, okay, I’m not doing revenue here. And of course it’s not altruistic it’s based on the fact that open source is far more valuable as it is than it would be if it was hindered by people not being able to engage.

Henry: One thing that we discussed off-air that really intrigued me was the idea of patent families, so what are patent family?

Patent families

Shane: So a patent family is essentially where you have one or two very strong patents. Let’s say you invented something completely new, and then around those, you hang adjacent innovations. And those adjacent patents might not be super interesting per se, but they help fill out the area. I’ll give you an example, which is a oversimplified version, but you might have a patent on the wheel and that’s a great patent, but around that, you start to have additional patents like a break patent for the wheel or the axle bolts for the wheel. And these individual patents, aren’t super exciting, but they’re relevant. And if you have all of that family together, you have a pretty strong innovation lock on that wheel approach, so that’s how you build a patent family. You find something really strong or a couple of patents and you build out from there.

In the modern world, companies would often not just build the patent families, but occasionally package them and sell them onwards. And a patent family is a really easy thing to digest because instead of looking at 30 individual patents, you’re looking at three patents plus all their best friends.

Henry: How does that compare to licensed families?

Patent families vs license families

Shane: So the licensing families are different in that they might be covering completely different technologies. The licensing families, they’re simply a way of saying this is how I’m granting around the copyrighted software. So while patent families are very much about saying, here are interrelated temporary monopolies on technology – licensing families are where you’re saying, this is my general approach to licensing software. And inside this general approach, I have some options with more or less restrictions for users. So it’s a different mental model though, of course, fundamentally when you pull back, what you’re looking at is intellectual capital, whether it’s an invention in the patent or the hard mathematical work of software, and ways that you can leverage that either forgetting or control or indeed ranting to everyone, depending on your preference. So patent families, it’s about building out specific innovation locks. Licensed families, it’s about having an approach to granting rights and then insights that approach having closely related licenses that give you nuance options. This is really fun stuff for parties.

Henry: I’m sure you could get into a very, very long conversation at parties about how all this works. And I’d now like to shift gears and focus on the work that you’re currently doing at OpenChain. So for those listening, OpenChain has essentially created a process standard for open source software compliance, that’s amazingly being compacted down into a seven page document. And after looking through the website, it’s clear that it helps to define what quality open source looks like. And in short, it’s a process approach that removes uncertainty and potential confusion that companies face around the license compliance.

So onto my question now, what kind of complexities has this help reduce in the supply chain, and why is it important that companies and suppliers adopt OpenChains standard?

How OpenChain helps businesses

Shane: We’ve been doing open source now for about 30 years in the corporate space. And for a lot of that time in a similar manner to patents, people were doing their own thing and they were solving for how to address license compliance on their own. Many companies did an excellent job in this, but there’s an issue when you look at the supply chain. And to get any product to market, you’re looking at 20, 30, 40 companies in a chain going from basic Silicon through to injection molding through to final product. Or if it’s a cloud product, you’re looking at people building the stack from the core technology of the server, all the way to the web app that you’re using. And the issue became not how well can my company be compliant; it became how well can the supply chain manage compliance. And the problem with being bespoke and solving it on your own is that every company is doing something a little bit different and therefore a little bit incompatible with each other. So, they might mean different things when they say, oh, we scanned internally, or they might mean different things when they say, oh, I check the software coming in.

To give you an example – not that long ago in Taiwan, one of the companies was using over 20 spreadsheets to address the different requests from their customers. And you can imagine that if it’s the same product but 20 different slices on how you have to talk to your customers about it, the stakes crawl in. So what we had to do was essentially look at a couple of decades of mistakes and isolate when they happen. And as it turns out, they happened in the same places all the time. And once we’d done that, we simply said, okay, these are the failure points, have a process here. And if every company follows that, you know exactly where someone should have a process.

And if something goes sideways, let’s say you find a piece of code that’s not correctly licensed; you can quickly start asking everyone, did you scan this piece of code at inbound? And all of them will have the same answer. Yes, we scanned it inbound or eventually one will be like, oops, and quickly you can fix it. And this is very different from the past where you had to route through the supply chain and go through different questions and answers. So, it used to take three to six months to remediate errors, with something like OpenChain. You’re looking at days possibly less because everyone’s moving in the same direction. So OpenChain is license compliance, but it’s not the dry matter of, oh, we must follow the license text. Of course that’s the consequence, but it’s really about supply chain efficiency. So we get things done a lot more quickly, a lot more accurately, and that saves us so much resources in going back and forth. And of course, it prevents any product stoppage.

Naturally, if you isolate an issue with something like licensing with intellectual property, you don’t want to go to market with that. And that slows you down, and that’s critical in many industries. If you slow a car down, you’re looking at serious costs. If you slow a cell phone to market; you’re looking at the potential you’ve killed its market position, so it’s an incredibly important area. And it’s one that while not neglected; we hadn’t found a consolidated approach to. In 2016, we launched this standard and it very quickly gained a lot of traction. 2020 it graduated as an ISO standard instead of just being a defacto standard and it continues to accelerate. The reason of course, is that it’s rather good. And it’s rather good because so many hundreds of companies got together and said, here’s where things go wrong and try to make sure that instead of a ridiculously long checklist, we caught the essence of it. And once we caught the essence of it, companies were free to implement in this specific way they needed to.

Henry: I definitely imagine that being very useful in the supply chain because of the cascading effect. If one person makes a mistake and isn’t either quick to notify or to be able to say that it happened, and then on the other end actually fix it, it would just be an absolute mess. It seems like a really interesting way of, like you said, saving resources both in time and money spent on fixing those mistakes, but also making it a lot faster to go to market and making sure that there’s no upsets along the way.

Shane: Yes. And when it comes to something like consumer electronics, you’re looking at approximately one to three months of primary sales, and then it’s a long tail, but that’s not really profitable. So if you delay one month market, you’ve really damaged your bottom line.

Henry: So definitely companies listening, if you’re not a part of this and you’ve got anything to do with the supply chain, but also which we’ll discuss later, there are other use cases and you’ve mentioned them before. Just in this, in this conversation, I think definitely check it out on their website. But based on my understanding OpenChain of looking at the website, it standardizes a process of collecting different artifacts about compliance at different inflection points for a company.

And off air we talked about the three inflection points being inbound, inside and outbound. So, can you explain this process a bit for those listening?

Three inflection points managed by OpenChain

Shane: Of course. The very basic thing is that when you’ve got software coming into a company, you want to know what software it is, what version it is and what license it’s under. And if you isolate those three things, as your developer team gets hold of it, customizes it, or simply integrates it; they won’t make mistakes like putting software together that might functionally work, but in licensed terms is incompatible. And that’s a really important thing to get right. Internally, of course, then you want to make sure that your team is educated enough to understand what the licenses are, for example, and that as they work, they can monitor stuff. The last thing you want is your team to identify incoming software, but then turn it into a binary and give it to another team internally and that other team has no idea what it is. And that stuff really happens, especially in multinationals – so internal training and also tracking.

And then finally on outbound, it’s the sanity check. And it’s basically making sure that the inbound and internal matches what the outbound scan sets. Quite frequently in the supply chain in company internal, something happens inside completely unintentionally. In fact, I’ve never encountered a company purposefully violating the license. If something happens internally, someone took a chunk of code out of something and then forgot the license, and these unintentional errors happen internally and you’ve got to catch them on outbound. It’s a very simple concept. I mean, there’s no quantum physics involved here, but it describes where we know things go sideways. And once you introduce it in a company, we found that the engineering teams, the project managers don’t really have a burden in doing it. In fact, it’s less burden than someone at outbound saying, oh, you screwed up. And if you don’t have internal processes, you really have to go manual.

Henry: And how is all of this tracked? Is it in a word documents? I know you said that’s done historically; is it a case where you kind of turn the 15 pages of word documents they would have for many different processes or areas within the company and you put it into one, or what kind of process do you use there?

And then also, you mentioned training, does that involve going out and making sure that the different teams are aware of these processes so that if one person in one engineering team actually does add an open-source software library – how does that process work? Do they then need to tell or notify the other teams? Or is it as simple as just adding that to the document or whatever process you suggest they use?

Shane: So nowadays virtually all companies are either automating or wish to automate these processes. So you’re looking at scanners doing this inbound or monitoring development and catching outbound. I’d say we’re somewhere in halfway between the transition of the manual world, which was Excel spreadsheets or custom databases and having automated tools. Its volume has a problem. I mean, the Linux kernel alone has many millions of lines of code and people are using thousands of packages. So doing it manually inherently reduces errors, I mean, automation helps. Some people use service providers for automation and some people use open source tools. Quite frankly, it doesn’t really matter what you use as long as you’re scanning; everything out there is pretty good, so it’s really a budget issue. Do you want to pay someone to take the responsibility of supporting and maintaining the tool or do you want to save that money and maintain it yourself? What resources do you have?

Some people are still using Excel spreadsheets to track their software bill of materials and stuff. For instance, in Japan, there’s a bunch of companies doing that. And it’s fine as long as they make it nice and clear. Particularly nowadays we use something called software bill of materials, and that uses standardized tagging. So whether you are using a tool that’s automated or you’re using a spreadsheet, the tags are fundamentally the same. So, if you give them a spreadsheet, they can then use their tool to read the spreadsheet and integrate into their workflow. And if they come out the other side and someone needs a spreadsheet, they can dump that into a spreadsheet. So that’s really the link and the line between manual and automated is blurring, and the spreadsheets are not optimal – that’s for sure. But they works for small companies, quite frankly, for small companies, it’s not a burden. If you’re moving a hundred million lines of code an hour, like a large multi-national; the spreadsheet would kind of be pushing the limits of what you can do.

Henry: So it’s definitely a consideration of these smaller companies need to have is yes, start with the spreadsheet, which is quite okay, but would work for a little bit – get out of the dinosaur ages and move into something a bit more advanced. And so, it seems like it’s quite different across companies based on size and also industry. And I can assume that a lot of those larger and medium sized companies that have adopted open source with an idea of trying to make it work for them, knowing all of the software coming in and out, it sounds like largely that would be automated by a lot of these tools. What are some of the best tools out there for automating that process?

Best OSS auditing tools

Shane: Well, right now there’s probably scamming tools which are light in open source. Like scan code is one, another is FOSSology, and these are ways to quickly scan a Corpus of code. Then there’s more integrated management tools that are scanning and tracking such as, or open source review to tool kit. And I think probably right now, we’re looking at an even split across the industry ScanCode, FOSSology and [unclear19:42]. I think most people tend towards ScanCode for getting started. It’s the lightest to get started. And for process integration, a lot of people now in Europe are using more. FOSSology is something that goes from scanning into complexity, and quite a few companies have been using it for quite a few years. I think it’s probably the most mature solution out there, though not necessarily the most popular in all jurisdictions. I mean, you’re looking at how long does a piece of string. Companies are so different that it’s hard to pick any winner out there. It’s really more of a portfolio of options.

I know on commercial tooling, you have much of the same thing. You’ve got companies like FOSS-ID, laser-focused on scanning for compliance and bit of security. Then you’ve got companies like Synopsis who own Black Duck who are doing the same thing, but also integrating into all kinds of project metrics and so on. And then you’ve got companies like PWC that you don’t really hear about in the context of open source compliance, but they have incredibly sophisticated holistic process management for their customers. So again, it’s how long is a piece of string?

What a bank wants is very different from what a router company wants. And the only thing I’d say is that most companies are margin constraint. I mean, a few companies like Google or Facebook print money and they can afford to do whatever they want. But if you look at a company in the middle of the supply chain, putting together a router; their margin is one, two or 3%, so that helps determine what they choose as much as the effectiveness of the solution or the sophistication on it.

Henry: And it’s funny you mentioned Synopsis because we had Paul Chen, who’s a manager of open source compliance and enablement at Synopsis as one of the early guests on the podcast. And I was stunned when I heard the amount of audits they do every year. I think it was something like 600 or more. And it definitely shows that that is quite a mature market, we have the technology today. I guess you could develop it internally, but it’s probably best to look externally ones since we are such a mature market in that space. I was wondering if you could share an example of other company using OpenChain standard and explain how it affected their bottom line.

Example of OpenChain impacting businesses bottom line

Shane: I think one good example is Wind River, which isn’t a company that most people have heard of. They basically work in the background on integration. They’re involved in everything from helping people with consumer electronics through to space programs. So, if you want to build a Mars Rover, you might talk with Wind River about how to get started. They’ve been using OpenChain since the beginning and for them, it was integral in two ways. One, it displayed a path forward for supply chain management. And remember, Wind River is somewhere in the lower middle; they’re above Silicon, but below application. And for them, it meant a path to not dealing with a hundred different requests from customers. And it also meant path to just unequivocally stating that yes, we are using the standard for this; there’s no question that we’re using the correct standard.

So, they’ve been deriving value since we launched in October, 2016. They were the first company conformance. There’s been conformance with every revision, and they use it extensively in their marketing and support materials. I think their benefit was they deal with a lot of customers, including the most demanding in the world in areas like aviation and events and so on. So for them, a portfolio of clear standards is the optimal solution. You don’t want something where you say, oh, we do this in the way that we invented and that’s great. Your audience will typically look at you and be like, and which standard does that fall? So, that’s how they did it.

Another example is Toyota, which adopted OpenChain as an ISO standard on the day of release. Obviously, they had a preview of the standard and we’re working on it for a while. For them, it’s simple; they’re at the very end of the supply chain. And as car companies will often tell you, they’re not a manufacturer, they’re an integrator. They really don’t make anything; they put stuff together really effective. And for a company like that, with thousands of suppliers, it’s a statement of how they want their supply chain to align. And it’s all about efficiency and accuracy. I do remember one of the Toyota crew telling me that Toyota’s primary capital is trust – customer trust, and everything that increases that is valuable to them, and anything that challenges, it is a core issue. So, OpenChain isn’t about license compliance to Toyota, per se. It’s about saying in this new domain and this domain of software, here’s one of the ways you can trust us. And of course…

Henry: Like OpenChain can lead to. And when researching for this podcast, I read that OpenChain standard had also been applied in other domains. And you hinted at that at the beginning of the podcast some of the things that came to mind were security and venture capital.

So, can you talk a bit about the different ways that this standard has been applied outside of the supply chain?

OpenChain applied outside of the supply chain

Shane: Yes. To some extent it’s been surprising the extent that OpenChain has been used in different domains, given that we’re a young standard. I mean, in the international market sense, five years is young and we’re just out of ISO for five months. So it’s a case of, oh, this is a youthful standard. But yeah, it was applied almost directly into new domains, and it continues to be. We just finished our project survey for Q1 2021, and we found that over 50% of organizations engaging with OpenChain were up to something else apart from conformance or internal compliance health checks. And you look at that metric and you’re like, ah, that’s interesting, I wonder why. And then you look at the satisfaction metric and virtually everyone was saying, oh, we’re very satisfied. And you think, gosh. But the reason is that OpenChain distilled identification and management of software at a very basic level.

And particularly in a domain like security, what OpenChain accomplishes is pretty much exactly what you and need for security – identification of the software and the version. You might even care about the license from a security perspective, but you care a great deal about the first two. On a core level, there isn’t much else you’d want to do on security for identification of software; OpenChain covers all those core bases. So, it just slots into your existing approach to security. It’s like, oh, okay, here’s how we do the open source identification process management, and thus it is people are using it that way – other domains as well. So, venture capital and merger and acquisitions… I think M and A came up first. We found that companies were leveraging OpenChain to ask acquisition targets – are you OpenChain conformance? And most of them would say no. And then they’d ask, do you have processes at the points for OpenChain requires? And most of them would say no.

And at that point as an acquisition company, you can start to find out what processes are they missing. And you can also do things like negotiate on pricing and so on. So it became a tool immediately in M and A. I don’t want to say that it was a mercenary tool that everyone just wants to negotiate lower pricing; we’re talking about the whole thing when you’re doing M and A, you’ve got to vet companies. And the question is, how do you vet? Using the industry standard makes the most sense. Same for venture capital, again, you’re looking at a situation where you’re about to roll the dice on a new company, or you’re entering a young company. And probably your biggest question apart from the quality of the team is how chaotic is it in here?

And you can see how that played out in certain markets. Like, we worked in one of the most fascinating train wrecks in recent IPO history. It’s extreme case, but it shows that a company that’s young and has been operating for years can still be utterly chaotic inside, and OpenChain helps close one of those chaos zones. Do you use open source? The answer is always yes. And if they say, no, you have a red flag because of course they do. Everyone does. And then, do you follow process management on compliance? The last thing you want to ingest as a VC is bad intellectual property, so it fits. And we found it using the other domains as well. Like, people using OpenChain for export control. Again, similar to security, it just touches on the right domain points.

So quite frankly, we are accidentally successful at a pace we didn’t expect in a wider range of domains than we had foreseen. We had foreseen in security, we had thought about export control, but we didn’t think we’d be leveraged by VCs as early as we are. There you go. And of course we work hard to support all of these use cases, by first of all, making everything public domain in terms of documentation, second of all, just letting people use our infrastructure for self-certification assessment and so on. So you can just tell a company or tell yourself, go use the web app and see how many questions you can answer yes to. It’s nice and simple, and there’s no limitations. We don’t limit it to licensed compliance, and that’s good because over half of the people are not using it for license compliance, and that’s accelerating I think. We’ve had defense companies and aviation companies turn up increasing numbers. Naturally, they’re looking at a whole range of things that they’re covering, so they’re using us in multiple domains.

Henry: Okay. And definitely anyone who’s listening, check out OpenChain’s website and see how you can apply this standard. If you want to save time, minimize waste, increase the speed at which you can solve some of these compliance problems, it sounds like a great resource and also community to be a part of. And also, whether you’re M and A, venture capital, export control – really anything, it seems like you’ve got a big range of companies now using it, so make sure you do check it out. Is there anything upcoming that people should be aware of that are listening?

Well, I think on the closing note with OpenChain, since we became an ISO standard, we’re ISO 5230, we are now in a state of maturity where we’re not planning to change the standard for quite a while, but we are planning to build explicit guidance, documents, or extensions to help companies using us for M and A for security and export control, VC and so on. So, get involved in our community if you’re interested in those domains, as much as compliance. Not only do we support you currently, but we’re building explicit documentation based on the experience of user companies, just to make it easier. We work closely with things like the national standardization committees in countries like China, US, Germany, UK and we work closely with international bodies like ISO, obviously, because we’re an ISO standard, and we also keep in communication with entities like Oasis and so on.

So I’d say, watch this space. What we’re doing now is extensions in terms of guidance, documentation for OpenChain, and we’re working on integration with other standards. It’s like, how do we make sure there’s no gap between the various standards, there’s nothing to slip through as you go from your functional safety standard to your security standard, to your OpenChain standard and so on? So, it’s a case of watch this space as we iterate and refine guidance documentation to make it as quick and as effective as possible, no matter what the use case.


Henry: So Shane, thanks so much for joining us today. I definitely learned a lot myself and I’m sure everyone listening learned a lot through this conversation, so thank you.

Shane: My pleasure. Thank you for having me

Henry: And to everyone who’s listening, if you like what you’re listening to today, then please leave a review on apple podcasts. Or if you’re watching this on YouTube, live, leave a comment and like this video letting us know what you think. It really does help out. Share it with a friend, get it out there because we want to make open source thrive; that is our goal. So, thanks very much everyone. Thanks, Shane. And until next time, thanks you all.