Open Wha?

[OK… my bad… things got a bit busy yesterday.]

I live in Raleigh, NC – home to RedHat Software. Most of you have heard of RedHat as a result of their linux offering. But more than that, almost everyone has heard of RedHat because they sell free software. Initially, this was absolutely dumbfounding, confusing even seasoned contract negotiators with the world’s first broad introduction to the concept of free software, also known as open source software.

[Let’s clear something up just in case there are still any misunderstandings. “Free” software, is not actually free. The term “free” is meant to refer to access to the source code, not to financial costs. As a result, it’s better to use the term “open source” when talking about this access.]

Open source software, then, is based on the idea that the source code would be provided along with the object code at no additional charge. In other words, you still end up BUYING the object code, but you get the source for free and a license to make changes (and distribute the source code per the constraints of the license if you make said changes).

But all of this open distribution leads to an absence of definitive liability. The result is that if you have licensed open source products for use in an enterprise environment, you can have problems with indemnification, warranty, and other “missing” traditional contract terms. So the trick is to understand the scope of the open source usage in your environment in conjunction with the license provided. This obviously can become a large issue.

Additionally, there are currently more then 50 “accepted” open source standard agreements. Each one is unique in some form or fashion – and thus each one provides at least a small difference in terms of the rights and obligations apportioned. The net effect is that each of these licenses has to be read very carefully. Any vendor looking to use open source software (and any customer looking to use a vendor who uses open source software) needs to read, re-read, and triple-re-read the license to understand the specifics of what is provided, what has to remain “open” in the future and what kinds of protections you have in the event of a problem. At the end of the day, then, what you have is a completely custom software license that has to be read with a fine-tooth comb. DO NOT TAKE THE USE OF OPEN SOURCE SOFTWARE IN VENDOR PRODUCTS LIGHTLY!!!

ICN offers a slew of conferences and presentations on a variety of contracting and negotiation topics. In June, the Technology Procurement Conference in Chicago will offer attendees the chance to deep-dive into technology contracting-related topics in a series of 3-hour sessions. It sounds like one of the topics for this conference is going to be on Open Source procurement. Check it out (especially since I’m going to be there as a presenter)!

Contract Management

In a recent Ken Adam’s posting, he discusses some of the tension that exists in organizations between the business folks and the legal folks and asks some good questions about how the two can work together to better serve the organization itself.

These questions stem from long-standing assumption the neither party really respects the value provided by the other. Business folks assume that the lawyers are simply there to be the “Order Prevention Department” (Ken called it the “Business Prevention Department”) and Legal folks assume that the business people will buy anything shiny (or with a power cord) put in front of them without considering anything other than “do we have enough money to pay for it?”. But the truth is that neither side is actually as bad as the other sometimes believes. The trick is getting people to work together for the common goal of helping the company move forward efficiently.

So, if it’s really that simple, then, how do we make it happen? Well… yes, saying the words is simple. Walking the talk, well, not so much. The problem is that each side has a competing interest with the other. Like any good negotiation between disparate parties, then, the key is to find the common ground and to build off of those shared goals to craft a relationship whereby both sides feel that they are getting what they need, but are allowing the other side to “win”, too.

It’s complicated at times, of course. Even if you have a business unit that recognizes the importance of legal, a particular deal (usually a result of some sort of end-of-year fire sale) that has to get done now will derail even the most stable legal-business relationship. Likewise, for smaller in-house legal teams, larger business distractions such as lawsuits, high-level corporate governance issues and other items seen as more pressing than contracting, sometimes takes away legal’s ability to be responsive to the needs of the business units.

Although I’m obviously biased as a contract negotiator myself, I feel it only proper that such organizations should have an internal contract management group. This is a dedicated team of specialists who understand the contractual terms and conditions (and know how to get support from legal when they need help or see something new or particularly difficult)… but they also understand the shifting and sometimes hurried needs of the business, too.

A contract management team is NOT an administrative group of paper-pushers, though. The team members must be highly-skilled professionals (sometimes even lawyers themselves). They have to receive continued and intensive education on contract review, drafting and negotiation. They must be able to spot potential risks and know how to mitigate those risks without sinking the deal. Additionally, most also need to have a solid grasp on many facets of the business units to which they provide support, so much so that in some medium-to-large organizations, contract professionals are even sub-specialized to these units. The end result is perhaps a contract management department that has an IT contracts person, a facilities contracts person, a services contracts person and sometimes even a dedicated HR contracts person (just to name a few).

This team then works diligently to assist the business units in closing their deals (by the way, this specialization works in sales-organizations, too, with sales contracts people) as efficiently as possible. In companies that really understand the value of how this group can work, they allow the contract management team the ability to function autonomously – managed by the organization, of course, but not controlled by the groups they work to serve. They have priority access to Legal – as the lawyers learn to trust the contracts professionals to come with key, important and already-reviewed issues… allowing the lawyers the ability to only have to provide tactical contract assistance and review, rather than read/negotiate the entire document from top to bottom.

At the end of the day, I’ve never seen an organization that creates a contract management group ever disband it. Centralizing this function offers a high level of benefit to the entire company, and in my personal experience, these groups are usually well-respected in their organizations for providing prompt, sound business and contractual judgment and advice. I would be interested in hearing your experience with these groups (though I suspect that many of you are in these groups).

Software Licensing Handbook Wiki

A few weeks ago, I was asked by a reader if I had thought about creating a digital version of the Software Licensing Handbook. He suggested the creation of a database based on the book, using the sections as the key articles. I really liked the idea, but struggled with a way to make it interesting and useful not only to those of you who don’t have the book, but also valuable to those that do. In essence, I wanted to add additional value to the book, not replace it.

Continuing to think about it, I came to realize that a semi-static wiki was perhaps the best way to electronically “publish” access to the bulk of the content of the book (some sections are harder to translate to a database/digital form). I’ve created the wiki with pages for each term, categorized the terms and I’ve limited the reader to a read-only view (with the ability to add comments, but not edit the main article itself).

My goal here would ultimately be to license access to the wiki – the main article would remain as it is/was in the book… but readers could add information/suggestions that are perhaps industry-specific, or country/region specific (as I would love to hear what other countries laws do to US-style software licenses).

I want to do this efficiently and effectively. So I’m looking for some folks who would be willing to serve as beta testers. I’ll provide you access for a beta period where you can play and explore, and even add comments. In sum, you’d have “full” reader access during the beta period. If you don’t already own a copy of the Software Licensing Handbook, this would also provide you with a serious review opportunity of the content of that guide.

I’m thinking that 10 people (and I would prefer them to be scattered throughout the world, as I see I have readers in just about every country) would give me some good feedback. I make no promises on duration or future accessibility… this is merely an indeterminate beta trial period.

Any takers? Please e-mail your name and e-mail address to me (the wiki is password protected and I will need to give you the URL, too). I would like to know where you’re from geographically and what you can contribute in terms of feedback, beyond just the ability to look at the wiki. For example: are you a lawyer in Germany? a contract negotiator in Spain? a paralegal in Australia? are you an author? a student? an internet god?

I look forward to hearing from you!

NCMA Book of the Month

Don’t worry, there will still be a regular Tuesday posting… but I just saw that the Software Licensing Handbook was selected by the National Contract Management Association as the April, 2007 Book of the Month!

I’ve never received this kind of recognition before, so it’s exciting to me. Thanks for letting me share. I’ll now return you to your regularly scheduled programming, but stay tuned for an exciting announcement next week!

Service Levels

The last thing most people want to consider while starting a relationship is what happens if the deal goes south. As a result, areas of the contract having to do with breach, termination and service levels or performance guaranties tend to lack the same depth as others.

Specifically with respects to service levels, the goal is to create a measurable set of steady-state obligations that are able to be met by the product. The first two steps are then to list the obligations themselves and their associated performance level. This could be as simple as saying that the product will operate uninterrupted to a certain percentage of the day, or as complex as 30 or 40 individual operational features that have to perform to a certain degree or quality (such as providing a report generated in a specific time period).

After you know what obligation(s) to watch and the required operational level, the next step is to make sure that the obligation actually can be observed. Many SLAs are good in theory, but don’t provide practical metrics simply because there’s no way to know whether they have been met. For example, many parents want to know that their newly-driver-licensed children can’t or don’t exceed the speed limit… but until there was a device that could watch maximum speed, reliance was upon the integrity of the driver.

Next is determining WHO is responsible for tracking the SLA. This entirely depends upon the product – I’ve seen the responsibility equally distributed between both licensors and licensees… just make sure the party who is tasked with the job knows that it’s their responsibility. But, especially with services-related tasks (or ASP/SaaS products), the job normally falls to the vendor/licensor, as they’re in a better position to watch performance.

The “watcher” should then also be in charge of reporting the metrics to the other party on a regular/consistent basis. If the obligation is that a service will be available 24x7x365 with 90% uptime, then it’s reasonable that each month a report will be created showing any downtime and how that compares to the 90% requirement.

Lastly, and usually of primary importance to the licensee/buyer, is the issue of what happens if the metric is “blown” and the SLA is missed. Contractually-based remedies are my preferred method for handling this what-if – but unless the true damage of missing an SLA is calculable prior to the missed service level, there’s the chance that any contractual remedy will fall short of actually fixing the issue. So rather than focusing on penalties, which is often what happens in the negotiation, focus attention on how much effort will be used to solve the current problem and prevent future problems.

If a vendor is then unable to prevent the problem from recurring, or in the event that the SLAs continue to be missed, financial penalties can be included as a last resort to return some of the fees paid for the lack of 100% guaranteed service.

So, when creating SLAs, take the time to discuss the needs behind the SLAs with each other. As with other sections of the agreement I’ve discussed in the last few weeks, a little open, honest communication at the beginning of the relationship can avoid lots of future problems.