Are SaaS companies immune to open source risk?

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.

1. Legal risk for SaaS companies using open source

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.

Lastly, most companies with SaaS offerings also distribute software. A very common architecture these days is a mobile client front end with hosted back end. The client software is distributed and therefore beholden to GPL obligations. More subtly, many SaaS applications use client-side JavaScript code—if you see any kind of animation or slick graphic interaction in your browser, it’s probably JavaScript. It’s not apparent to the user, but the slick graphics are enabled by the code being downloaded to and actually executed on your computer. Most lawyers consider that distribution. Most companies that host applications need also to pay attention to the GPL for those parts of their software that they distribute.

2. Security risk

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.

3. Operational risk

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.

4. Strategic risk related to SaaS and open source

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.