Regardless of what you’ve heard about the GPL SaaS loophole, SaaS companies using open source components are not immune to these four open source risks.
The brief answer to the question of whether SaaS companies are immune to open source risk is no. While there’s a grain of truth with respect to the use of the GPL-licensed components, SaaS companies are not immune to legal risks. And there are other elements of open source risk to which SaaS companies are actually more exposed than non-SaaS vendors.
The GPL licenses are the most common open source licenses and generally the most problematic for companies developing software. SaaS companies are more free to use GPL licensed-code because the obligations of the GPL are triggered upon software distribution and SaaS software by nature is not distributed. (This is often referred to as the GPL “SaaS loophole.”)
However, SaaS companies still need to be concerned about software licensing. First, there are a number of licenses, most notably the AGPL, that are (according to the AGPL preamble) “specifically designed to ensure cooperation with the community in the case of network server software.” In essence, the obligation to make source code available is triggered not just by distribution but also by allowing use over a network. These licenses are much less common than the GPL, but are still out there and are designed to plug what has been considered the SaaS loophole in the GPL.
The other “license type” that SaaS companies should watch out for is no license. In the vast majority of audits we perform, we find code that has been appropriated from the internet, but with no clear license. The default of copyright law is that if it’s not your software and you don’t have permission (i.e., a license) you don’t have the right to use it. Therefore, there is risk in doing so.
If SaaS companies are less concerned about legal risk, the internet accessibility of their offerings makes them more concerned about security. Open source components overall are no less secure than other forms of software, but last year over 4,000 new vulnerabilities in open source were publically reported. And the OWASP Top 10 web application security risks includes “Using Components with Known Vulnerabilities.” Many companies are using open source components with known security problems.
Security is related to the operational risk of getting behind on versions. Using old versions of components exposes an organization to known vulnerability problems. The good news with open source is that once a vulnerability is identified in an active open source project, “antibodies” in the community usually swarm in and quickly patch it. However, if you are not tracking what components your developers are using, it’s nearly impossible to keep up with the latest version. Apple and Microsoft remind me weekly that I should be installing security patches on my laptop, but there’s no entity to provide such a reminder for most open source components.
So there are risks even with “active” open source projects. There are worse risks in using components that don’t have an active community around them, maybe started by two people in a garage who have since lost interest. A seasoned technical advisor to acquirers recently told me, “The biggest problems I see are with ‘dead code.’” He meant components with no active community, the users of which are essentially on their own to find and fix problems.
If you build an application to be accessed only as SaaS, don’t plan to distribute it. I once managed a product portfolio that included a SaaS service. Two large overseas telcos approached me interested in hosting the software themselves and willing to pay big bucks for it. My excitement was quickly deflated when the savvy engineering manager who built the product schooled me on the GPL license and how dependent our architecture was on GPL-licensed code. No big bucks, rather a big bummer.
Ventures that might be looking for an M&A exit in the future should consider how dependent they want their applications to be on GPL. You might have a vibrant SaaS business, but potential buyers may be interested in also offering an on-premises version. (IBM, for example, seems to look for this routinely.) The more dependent your offering is on GPL-licensed code, the harder it will be to make it distributable. There may be good reason to use GPL components, but do so consciously and be aware of the strategic limitations.
On net, using open source is a huge positive and, as Mark Driver at Gartner once said, not using open source puts a company at a “competitive disadvantage.” It is the case that with respect to legal risk, SaaS companies have a bit more latitude. However, SaaS companies are far from “immune” and certainly need to manage the range of risks that may come with using open source for those who do not know their code.
Phil is General Manager, Black Duck On-Demand. He works closely with Black Duck’s law firm partners and the open source community. A frequent speaker at industry events, Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group. With over 20 years’ software industry experience, Phil came to Black Duck from Empirix where he served as Vice President of Business Development and in other senior management positions, and was a pioneer in VoIP testing and monitoring. Prior to Empirix, Phil was a partner and ran consulting at High Performance Systems, a startup computer simulation modeling firm. He began his career with Teradyne's electronic design and test automation (EDA) software group in product, sales and marketing management roles. Phil has an AB in Engineering Science and an MS in System Simulation from the Thayer School of Engineering at Dartmouth College.