SaaS and GPL v3 – the 5-minute guide

Lately I have been advising several Cloud / SaaS startups and this topic came up multiple times, so I thought of creating a quick blog post. You can write a huge essay (or a book) on the broader subject of software licensing and how it plays well (or not) with SaaS applications but this is meant to be a 5-minute primer, so here goes:

The broad consensus at this point is that “distribution” is the triggering event for strict copyleft provisions in GPL v3. In other words, as long as the end-user is interacting with your software over a network and you control the hardware / infrastructure the software is running on, that is not considered distribution. This is almost always the case with SaaS applications, whether they are multi-user or single-tenant, and it means SaaS companies can utilize GPL-licensed libraries or packages without sharing their own code or modifications to the code. This is also known as the “SaaS loophole” in GPL v3, without which a fair number of SaaS companies or even cloud service providers who offer a fully-managed service / control-plane on top of GPL-licensed software would be in trouble. On the other hand, if you are offering your software as a downloadable package or binary, then this loophole’s protection does not apply. You are required to provide the entire source code and any modifications you made to the original code to comply with the copyleft provisions of GPL. On the other hand, with a permissive license like BSD or MIT, these considerations don’t apply and you are free to commercialize the derivate software without open-sourcing it. Perhaps the most famous example of this is MacOS, originally “derived” from FreeBSD.

Recent variations of the GPL license such as AGPL (Affero GPL) aim to close the SaaS loophole and enforce full copyleft provisions on all derivative software (cloud-hosted or not) that use it. But that is out of scope for this post and we will talk about it another day.

And finally, it is worth noting that the GPL v3 does not preclude or prevent the owner of the modified software from creating their own licensing terms around how that software can be used. This is typically called a EULA (end-user license agreement), and if you are procuring a software package you should carefully examine the EULA for any restrictions it might impose on your business model. If you are not happy with the EULA, you are free to choose a different vendor or modify the base open-source package yourself. EULAs are typically written in a business-friendly manner since the owner is trying to sell the software after all, and burdensome licensing terms can be a deal-breaker for many potential clients.

Personally, I have always found the notion of “paying” for FOSS or open-source software fascinating, but it makes a lot of sense since software is never a finished product. What you are really paying for is software maintenance (bug fixes – don’t tell me your code never has bugs!), technical support (especially when running the software in a complex cloud environment), and product updates / feature updates for the duration of your license. Last but not least, software developers who produce high-quality software deserve to get paid well, so when you purchase a paid software license you are encouraging the developer and supporting the entire ecosystem.

My favorite example of this in the WordPress ecosystem is a caching plugin called WP Rocket. Yes, you can hand-roll your own caching plugin using a bunch of open-source packages but it is a very complex undertaking. With a plugin like WP Rocket, you get immediate bug fixes and security fixes every time an issue is identified. And you also get frequent product updates like support for Google’s Core Web Vitals which is absolutely essential to your SEO.

I will end this post by saying that using GPL v3 licensed software is by no means a deal-breaker for your SaaS business. While it is possible that your specific use-case is unique enough to warrant further examination (in which case you should consult a lawyer), the vast majority of traditional SaaS applications will be fine. If you need an informal consultation on this topic, or would like me to advise you on your SaaS business in general – feel free to reach out!

Leave a Comment