This post is contributed by David Fligor.
As a modern SaaS company, you held the line against on-prem. The advantages of having your customers use the cloud have included keeping all of them on the latest version, rolling out bug fixes and improvements quickly, lower support costs, and a scalable, recurring revenue business.
You may not have been thinking about it, but your multi-tenant hosted services model has allowed you to avoid distributing software. At least for the most part. This has meant you haven’t had to deal with legal and compliance issues that old school software distributors have grappled with, such as the scope of license rights and particular conditions of open source software licenses.
Now, the CISO and CIO at your Fortune 500 prospect are sold on your software, but they want to deploy on-premises. This Fortune 500 prospect is your biggest potential sale to date. You are picturing the name and logo in your customer list on your website and in your pitch deck. Putting aside a nice bump to ARR, this might help you close your next round of funding and be the reference customer you need. So you’re going to do it. But what should you expect?
Create a New Template for On-Premises: The Software License Agreement
If you can avoid starting with customer paper, you’ll want to. The procurement department’s form is drafted with no understanding of your business and is often very one sided. It’s going to take some work to convert your MSA template into a Software License Agreement, however. At least three things likely will need to change:
1) License Grant. The rights provided to customers will be different for on-prem. Your current MSA most likely just provides the right to access and use your multi-tenant hosted SaaS offering. Now you will need to grant a license to use your software in object or executable code form with an appropriate license scope and with appropriate restrictions. You should aim for Goldilocks. Not too broad, not too narrow. Just right. And remember that you will also want to address the fact that there is almost certainly third-party code in the software you provide. For open source software, the customer should get rights under the applicable open source software license, not under your commercial license.
2) Usage. Now that the customer has a copy of your software, will you be able to monitor usage in the same way? If your business model was based on the number of authorized users or number of concurrent sessions, how will you handle this in the on-prem model?
3) Support. In traditional software licensing models, maintenance and support was a separately charged item that determined whether or not the customer was entitled to new versions of software as well as updates and perhaps even bug fixes. For SaaS models, there are typically service level agreements that define the level of support, and there is no concept of customers remaining on older versions. It’s worth discussing with your legal and accounting folks whether or not you should include maintenance and support in the license cost and whether or not you need to mention software versions in your support agreement. For example, you may want to limit support to the most recent two versions of your software.
Build New Processes for Open Source License Compliance
To date, you have avoided distributing software. Accordingly, you’ve heard that you don’t need to think very much about open source software licenses.
At most, your team has probably made a point of maintaining any copyright notices and license files provided by the authors of the open source code. By not distributing software, you didn’t have to think about notices to recipients of software that open source software is incorporated in your code. Your team may have been on the lookout for Affero GPLv3, but even there, most people only run across that license if using MongoDB. If they determine they are not modifying MongoDB database programs, they typically are not very concerned.
You also didn’t have to think about the implications of other “copyleft” licenses such as GPLv2 or GPLv3. Your code probably contains at least some. Your engineers may have even intermingled some GPL code with proprietary code because they understood, rightly at the time, that the copyleft license conditions only kick in upon distribution of software. Now that you are going on-prem, however, you’re going to have to develop more robust compliance processes and policies. The consequence of getting it wrong is not as catastrophic as some would lead you to believe. For example, it is unlikely to lead to an enforceable obligation to give away much of your source code for free as if your software had contracted a virus. It could expose you and your customers to assertions of copyright infringement, breach of contract and other claims, however.
Fortunately, there are tools available that help you catalog all of the open source software in your code and provide the right notices to your customers. Even if you are not going on-prem yet, it’s a good idea to know what is in your code and think about policies that might make it easier to comply if you ever decide to distribute your software.
TL;DR
To satisfy a Fortune 500 prospect and others with the same requirements, you’ve decided to add an on-prem option rather than sticking solely to a hosted services model. You’ll need to make several adjustments to how you contract with your customers and how you handle open source software. These are not reasons to skip adding an on-prem option, but you should go in with eyes open that there will be new administrative costs and risks to be managed.
David Fligor is on the team at Paradigm Counsel. He has been helping software and other technology companies with licensing, intellectual property strategy and complex dispute resolution in Silicon Valley since 2001.
