Every company uses software, obviously. There isn’t a technology industry keynote that passes without a besuited evangelist telling us that ‘every business is a technology business’ – and they may even pepper in the old ‘hey Uber has no cars, Amazon has no bookstores’ chestnut if they really want to check all the boxes.
But software these days rarely comes on a CD-ROM or in a box, even when it is a commercial off-the-shelf (COTS) software product. The downloaded, continuously updated nature of software creates what the industry likes to call the ‘software supply chain’. Because an increasing amount of this software is open source, we need to understand what implications this has for the shape of the chain.
Free as in speech, not beer
It is important to remember that open source doesn’t necessarily mean free. In the words of Richard Stallman, this is free as in speech, not as in beer. Developers are usually free to download open source software and work with it until the point that they commercialize and monetize their product, at which point the original owner may ask for commensurate monetary payback. Other open source software is free to use, but the original owners may charge for maintenance and support. Other open source licenses stipulate that the ‘locked down’ non-dynamic unchanging version of the original source code is paid for – useful if you want to run an air traffic control system with it.
Duncan Clark, head of PatSnap Academy points out that open source software can enter customers source code, including their internally developed proprietary code, in many different and often undocumented ways. Managing this process is key to working with open source channels effectively.
“This makes it notoriously difficult to identify, let alone manage, in terms of associated licencing obligations and risks. Intellectual property risks include copyright infringement, lawsuits and fines, combined with bad publicity. Meanwhile, misuse of open source software or issues of non-compliance can cause complications when it comes to company valuations for investment opportunities or mergers and acquisitions,” said Clark.
Academy by PatSnap provides free online video courses so individuals and organizations can broaden their knowledge of Intellectual Property (IP). PatSnap’s Clark points to recent reports which suggest that 74% of codebases audited as part of the 2018 Open Source Security and Risk Analysis (OSSRA) report contained components with license conflicts – this is where the software is distributed under different terms than individual open source code components stipulate – the most common of which were general public license (GPL) violations.
Individual decisions, wider impact
Meanwhile, 96% of the applications scanned contained open source components, with many applications containing more open source than proprietary code. What begins as a series of decisions taken by an individual developer, or small groups of developers, can create much wider risks to the business.
“The financial implications of non-compliance can be costly. As Linux.com reported in 2017, the US District Court ruled in favor of Artifex, a US-based software developer, against Hancom Office, a South Korean developer of office applications, after the latter had incorporated Artifex’ Ghostscript library into its solution and subsequently distributed it without a commercial license,” said Clark.
As cybersecurity experts Blackduck explain: “While courts have found that breach of an open source license can result in IP infringement, until now courts had not definitively ruled whether breach of an open source license is a breach of a contract.”
The above case was eventually settled between the parties out of court. Meanwhile, a lack of knowledge at BMW Australia caused bad publicity when the organization refused to supply the source code after it was requested under the terms of the GPL. Once the situation escalated, BMW did provide the requested code. PatSnap’s Clark argues that the situation in these scenarios gets worse when software appears to have no license at all attached to it.
“Any software that looks like it hasn’t got a license to it actually is more risky because there is no definition about where it came from, whether there are warranties or not, and so actually using software without a license is more of a risk than using software with a license,” said Martin Callinan, founder of Source Code Controland director of OpenUK, an industry association for open source software.
The official line from Source Code Control is that every single open source component should have a license attached to it.
A supply chain of software
Martin Callinan provides this advice, “Think of it as a supply chain of software. What are the third-party components that developers are using, or reusing, which ultimately are going to get shipped to customers – and is that going to ship a risk to the customers which could come back to bite the organisation?”
Academy by PatSnap has partnered with Source Code Control to deliver a free five-part video series that covers key areas organizations need to address. These include how to identify obligations and risks, what the implications of different open source licenses are and advice on who should be responsible for this. There is also guidance here on the pragmatic steps organizations need to take to shield themselves from open source software dangers.
Core takeaways and truths here center around the undeniable fact that the technology industry has ‘gone open’. In a world where ‘Microsoft loves Linux’ and the hivemind power of collective community contributions has been widely argued (if not proven) to outweigh closed proprietary development of any product or service, we need to understand how to ‘do’ enterprise open source all the way down the software supply chain.
Open source innovation is theoretically limitless, but its deployment policy controls in contemporary enterprise software environments demands boundaries.