26 Aug Selling Kubernetes Services: 3 Key Legal Considerations for Software Firms
Kubernetes continues to gain ground as a container-orchestration platform of choice for many companies. Four years after Google’s release of Kubernetes 1.0, the platform holds ninth place in GitHub commits. Major firms such as VMWare and NetApp are doubling down on it, investing in Kubernetes startups and acquiring them left and right. And the number of software firms offering outsourced Kubernetes support to large companies expands each day.
As a software consultancy that supports Kubernetes, it’s important to understand some of the key legal issues that underpin your relationships with your clients. This article describes three legal best practices to ensure happy and profitable client relationships.
1. Clarify the Intellectual Property that you provide to your clients
Your client agreement should carefully define what exactly you are selling and what I.P. provisions apply to it. Firms that work with Kubernetes usually offer some combination of three products:
- Professional services consisting of helping migrate clients to Kubernetes or manage clusters.
- Software-as-a-Service (SaaS) products that enable customers to manage or work with their own clusters.
- Writing new custom code to help clients manage Kubernetes. (Even if you are not retained primarily to write new code, your engineers may write new scripts on the fly during a project).
Legally, these are three different things, and client contracts should handle each of them appropriately. For example, if you offer a SaaS product, you’ll have a traditional SaaS clause that gives the client access or a license to it and defines the scope of permitted use. State whether you offer limited warranties or disclaim warranties altogether, and your liability clause should limit the amount you’ll compensate customers for harm caused by the product. If you offer a Service Level Agreement (SLA), check that your own product’s uptime guarantees do not exceed those offered by your hosting platform, or even better, don’t offer a detailed SLA at all.
For consulting services, always clarify the standard of quality that you pledge to meet. Typically a vendor promises to provide “professional and workmanlike” skill and should resist requests by customers to meet higher standards like “best-in-class.”
And if your engineers write any new code in the course of a client engagement, your contract must say who owns that code. Customers often insist on owning that new code (rather than merely receiving a license to it). As a vendor, that’s usually fine to agree to that, as long as you also grant your own company a “license back” to re-use that same code and derivative code for other customer engagements. (Otherwise you’re stuck reinventing the same wheels in the same use cases for each new client). Remember, once you “assign” (give) ownership of the code to another company, you retain no rights to use that code unless you negotiate to keep those rights.
Alternatively, your customer may agree to let you keep ownership of new code as long as you license it permanently to the customer. Either approach is usually fine for both the vendor and its client. We recommend whatever approach gets the client to sign your contract with the least friction, and usually that means offering the client ownership with a license back to yourself.
2. Ensure that your company owns the I.P. that you’re providing to clients
Before you can offer Intellectual Property to clients, whether in the form of SaaS or custom code used with the client’s Kubernetes infrastructure, your company must own that I.P. itself. That in turn means ensuring that all independent contractors and employees who write code, anywhere in the world, have signed specific written agreements transferring their code’s rights to your company. These are simple documents usually called “IP Assignment Agreements,” though the relevant legal language is also sometimes found in a larger Independent Contractor Agreement or employment contract.
This may sound obvious, but it’s common for software firms to overlook it. If you don’t have an in-house H.R. team ensuring that every new hire returns a signed I.P. assignment agreement, it’s easy after a few years to find that a few of them never signed it. Good news: this can easily be fixed after the fact, but it generally requires offering something additional of value (e.g. a small bonus or a gift card) to the employee or contractor if she signs after her service to the company began.
3. Get your data protection house in order
Many of your larger customers will require you to sign lengthy, granular Data Protection Policies when they hire you; often they will ask to attach it as an exhibit to your own client contract. These policies can contain anything from ISO/SOC certification requirements to pledges that you will follow not only Europe’s GDPR but the local privacy laws of dozens of other countries.
It’s not unreasonable for companies to ask you to sign those policies, but it can take your engineering team time to confirm whether your personnel follow all of those rules. And the requested certifications often require even more time as well as an investment. A better approach is sometimes to come to the negotiating table already armed with your own written, robust Data Protection Policy that you share with your potential client. In some cases, companies will agree to rely on your own Policy (once their own engineers bless it) and dispense with the need for you and your attorney to review theirs. This approach can save you legal fees, instill confidence in your client and get the deal signed quickly.
