In “Managing software legal compliance” in the February 22, 2010 edition of Network World, Sorin Cohn-Sfetcu and Kamal Hassin write that “ascertaining the legal compliance of software is just as important as assuring the quality before pressing it into production”. This assertion raised some interesting questions in my mind about the contractual provisions that should be incorporated in outsourcing contracts, and in particular application development and maintenance (ADM) agreements.
I think it has become pretty common practice in well written, customer-friendly outsourcing agreements to include provisions either forbidding the use of open source code and other third party materials or, more realistically, requiring the vendor to obtain the customer’s consent before using them. Also, it is common to include robust audit provisions that would allow auditing of the vendor’s code, as the authors of the article cited above suggest. Both requirements provide the basic tools allowing the customer to have an open source usage policy while requiring the vendor to comply and audit compliance.
Of course, when the relationship is based upon the vendor’s form, the vendor probably has not given the customer any meaningful audit rights. In addition, the vendor may have included language that gives it the right to use open source wherever it sees fit. In a transaction I recently negotiated, the vendor proposed language giving it the right to incorporate open source at any time without providing notice. Clearly, we pushed back on that idea. Even worse, some vendors will just incorporate open source without letting the customer know that they are going to do so.
Even where customers have a contractual right to impose an open source policy and to audit compliance, one has to remember that having a contractual right to do something and actually seeing it happen are two entirely different animals. Provisions buried in the boilerplate are often forgotten and worse, ignored from the outset. The concept of service levels and service level credits (the penalties the vendor pays when it fails to meet service levels) came into being as a way of keeping the focus on issues that are fundamental to service quality. Service levels are frequently used to measure and maintain many kinds of metrics measuring productivity and performance.
If compliance with an open source policy is important to the customer (and it should be), shouldn’t compliance with the open source policy be something that is addressed as a service level? The value of a service level measuring compliance with the customer’s open source policy is that it would shine attention on this issue on a monthly basis, and require monthly measurement of compliance. If any issues are found, correction of any non-compliance at no charge should be a required part of the service level response, as well as a service level credit for missing the service level. What will constitute correction will, of course, depend upon the type of open source that was used. In some cases, correction might even mean rolling back to a previous version of the code and making the changes again from scratch (without using open source this time, of course). Also, what will constitute correction may be impacted by whether the program in question is used internally or distributed. Keep in mind that using the code as part of a website may constitute distribution. The reporting requirements, obligation to correct improper usage at no charge and the potential service level credits would elevate the importance of the issue in the vendor’s eyes, making compliance arguably more likely and achievable. Depending upon the contract terms, repeatedly missing the service level might also be grounds for termination.
In a subsequent post, we will discuss the way a service level for open source policy compliance might be drafted, what the appropriate service level metric might be, and what behaviors this service level might drive.