Software Licensing Education Series – 400s Track Now Available!

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

The 400 Track videos include:
SLES 401 – Services Issues 2
SLES 402 – Maintenance and Support 1
SLES 403 – Maintenance and Support 2 (special 1-hour course)
SLES 404 – ASP and SaaS Issues

(500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

Advertisement

Mistakes

In contracts, we have two main types of mistakes:  mutual and unilateral.  One is “good” for the people affected (mutual), one is “bad” (unilateral).  The difference is based on fundamental contract principles of having a required “meeting of the minds” during contract creation.  If there isn’t because both sides were mistaken about the purpose, intent or meaning of the agreement, then the agreement can be dissolved.  On the other hand, if only one side says they were confused, then the contract will probably hold as written – as it’s not the responsibility of one party to explain to the other party how a contract will operate.

This is important because as a contracts person, it is your responsibility to know the language in your agreements and know how such language will be used to guide behavior.  You do not and will not have the luxury of pleading ignorance.  Which is why, when I see something like this, I have the tendency to get a little upset.  I had the chance to take a cruise last year.  It took me all of about 3 minutes to learn how cell phones would operate once on board.  The cruise line sent me a book about onboard topics two months prior to sailing… and there was even a guidebook in my room explaining it all again.  It’s pretty simple, actually.  The ship has an onboard cellular system designed to provide cell signal while at sea.  It’s a repeater – takes your signal, boosts it and forwards it to a satellite system to enable communication.

For this service, the cruise line bills you through your carrier.  Your phone will tell you that you’re roaming, too.  But if you’re near a land-based cell system (like when you’re sitting in port), it’s possible that your phone will pickup the ship’s repeater and not the nearest land-based transmitter.  Which is apparently what happened to that gentleman.  He didn’t know which system it picked up – and he gambled with a two-hour “call”.  He lost.  Sorta’.  Now AT&T ate part of the bill from a customer service perspective – good for them – based on the idea that somehow, the guy should’ve been told that the ship’s system was active, even when in port.

This is a unilateral mistake.  And a potentially painful one at that ($28,000 for an individual isn’t cheap).  Did AT&T have to reduce the bill?  No.  Should they?  Maybe.  But your vendors (or customers), now, more than ever, are going to be less likely to eat a unilateral mistake – even if it’s an honest one.  Lesson?  If you don’t know the answer, ask!

Stratactical

By now, I’m sure you’re innundated with blog posts and articles about how you can use the current economic situation as a means to beat the other side into submission (I’ve seen articles that say this for both side’s, actually).  You’ve even seen me blog on the subject of using time (which is what this really is) in a very strategic manner.  At the end of the day, however, we (as contract negotiators, procurement professionals, lawyers, etc) need to find a way to blend strategy and tactics into a coherent plan.  We need to find a way, to slightly borrow another phrase, to act tactically and think strategically.

Let’s go to the definitions.

Strategy.  A careful plan or method.

Tactical.  Made or carried out with only a limited or immediate end in view.

To me, then, the combination of the two is “strategical” – but Webster’s already has that defined as being strategic.  Stratactical?  Just doesn’t have the same ring, but it’ll have to do.  😉  My new word for the year.

Ok, so why the word-play?  Well, sometimes just having a word for it makes it easier to do.  It helps you focus on the how and not the what.  So I was trying to coin a new word to help me remember that I can beat the other side up today – but that sooner or later, the tide is going to turn again… and I might find myself on the receiving end.  So, being stratactical means that I have to use the current situation to my advantage, with limits.  I will take the opportunity to renegotiate contracts that are more tied to the ebb and flow of economic reality.  I will think twice about establishing short-term contracts that don’t provide long-term value.  I will reconsider the notion of partnership and what it means to be dependent upon others for my long-term survival.

I might still make less-than-perfect choices – but I will do so with my eyes focused properly and not simply blinded by the glare of the current situation.

Employment

Whether you have a job or are looking for a job, the time has come for contracts, procurement, sourcing and negotiating professionals to band together to help match each other with the right opportunities.

So, I would like to start a resume database.  Send yours here and we’ll see if there are opportunities that match the skills.

Oh, and if you have a job in this industry, let me know about it.  I won’t send you resumes that don’t at least match the basic requirements.

No money, no fees.  No referrals, no spiffs.  Just professionals helping professionals.

Net result?  I dunno’.  I make no promises.  But if we can keep at least one person employed, I’ll consider this experiment a success.

(Oh, and if someone would like to create an entire jobs board in my forums area, contact me to discuss it.)

Contracts as Business Tools

Douglas Gries over at Dymond Reagor Colville wrote an excellent piece on his blog about using contracts as value added business tools.  I couldn’t agree more.

I joke a lot about contracts being for the divorce, not the marriage.  But the reason that this joke is accurate is that the contract is (supposedly) the best piece of material you have to review when a relationship starts to go bad.  The contract represents the world as the lovers saw it at the beginning of the relationship – full of possibility and promise, and perhaps a little bit of caution, too.  Because of this, it’s a great document to review when you’re trying to repair damage and correct behaviors.

Unfortunately, too many agreements aren’t written in a way that actually gets at the intent of the parties.  Instead, they’re filled with lots of appropriate terms and conditions – legal phrases and jargon.  Which is fine, but when you’re trying to reconstruct each parties’ intent, falls flat.

In the old days, this was resolved with a lot of “Whereas, Now Therefore” clauses at the beginning of the agreement.  You would use the Whereas statements to highlight the background of the relationship and the Now Therefore to indicate that the contract was the resulting action of the Whereases.  But I think even well-crafted Whereas statements don’t get to the real heart of the matter.

So sometimes, I’ll try something a little different.  A “Purpose” statement.  Near the top.  Right under the introduction about who the parties are, but before Section 1.  The purpose is to lay out what is happening and why the contract is being signed.  It can be as simple as “The parties are creating this agreement to provide the base terms and conditions for the vendor to provide service to the client.”  or it can be super-specific: “The vendor is going to provide xx software to accomplish yy tasks along with zz support/training/installation services, as more fully described herein and in any attached SOWs.”

This type of purpose statement helps a subsequent reviewer (the divorce attorney, if you will), figure out some of the initial intentions and what a particular contract is trying to do.  Sounds silly, perhaps, but I just reviewed a few dozen contracts in the last few days – and not one of them told me what the product or service was.  Which meant that I had to try to figure it out based on what I knew the vendor offered – or based on clues left throughout the agreement.  Not easy and not fun.  But it made the review more challenging because I needed to know the scope of the offering before I knew what things to potentially look for or add to each agreement to cover the associated risks.

Oh, and if you think that cover sheets, memos or other documentation created at the time the contract is negotiated will explain it – well, perhaps it will.  But you’ve got two problems with it:  1) it almost never makes its way with the contract; and 2) you can’t rely on it from an evidentiary perspective (we’re going to avoid the conversation about parol evidence here, but you might be interested to learn more).

FriendDA

Funny, but I wouldn’t rely on it for anything.  🙂

No Sleep Til Brooklyn!

Thanks to everyone who entered my little contest last week.  All non-winning entrants received a free copy of the Software License Risk Matrix, just for playing.

Congratulations go to Andrew from lawshucks.com!  He was the winner of the random drawing from all correct entries – deciphering the title of my post: Eight weeks til BN as a reference to the Beastie Boys seminal album, Licensed to Ill – and specifically to the song, No Sleep Till Brooklyn.

For his extensive knowledge of 80s white Jewish rappers (the only others being 2 Live Jews, which, while researching the link and how to find them, had way more albums than I remembered), Andrew received the complete set of Software Licensing Education Series videos, a $225 value.

Again, congratulations to Andrew – and thanks to everyone who entered.  Keep looking for other ways to win free stuff.  🙂

Service Levels and Remedies

We’ve been discussing Service Levels for the last few weeks.  We covered construction, setup, drafting and even some recommendations on how the Service Levels might look.  But what happens in the event that the Service Levels aren’t met (they’re “blown”)?

We should start with a review of why we sought Service Levels in the first place – which is usually because you really just want what you’ve been promised in terms of service or performance.  In this case, remedies for blown Service Levels should be two-fold:  1) to get service restored as quickly as possible, and 2) to recompense for any damages caused as a result of the blown service level.  So you’ve probably even drafted the Service Level metrics so as to put a lot of importance on fewer outages or less downtime – with significant financial penalties.  But you don’t really want the money, you want great service.  The net result is that in the event of a blown Service Level, you probably won’t enforce the financial penalty… it’s more bark than bite.  But you are a stickler for responsiveness and attentiveness, and you will enforce the remedies if you feel that not only have the Service Levels been blown, but that you’re getting ignored, too.  This is justifiable.

But maybe you’ve got a little more jaded view and you already know that you’re not going to get exactly what was promised.  You drafted the Service Levels with really tight controls – trying to count every little thing (without regard to what’s really important) in the particular deal.  You instead feel that software or services are exact sciences and that if the vendor is silly enough to make a promise, you should get everything you’re “entitled” to.  The result is that at the first hint of a blown Service Level, you’re on the phone with the vendor asking for service credits (never mind restoration of service).

Personally, I hope you’re in the first group of folks and not the second.  Software and Services, by their nature, are going to have hiccups.  This is just how it goes.  Even older, established products can have difficulties (environments are constantly changing).  So instead of trying to beat the vendor with your contract, you use the contract strategically to make sure that you’re getting what is really important to the deal … and not some sort of small financial benefit for each blown level.

However, there are times where it is absolutely justifiable to use the contract as a sword and a shield.  One of these cases is what’s known as “death by ducks” – the situation where you have many small Service Level issues.  None of them, on their own, would be worth enforcing as a true blown event.  But together, you get pecked to death by the small things because they cumulatively add up to a significant performance issue.  Here, you should have anticipated this issue and have a small extra section in your Service Level language detailing the remedies available in the event of x number of small issues that add up to a certain Severity Level.  Heck, you can even define it as a certain number of Sev3’s = a Sev2.  And a certain number of Sev2’s = a Sev1.  How would you handle it?

Understanding (Your) Technology

Ken Adams recently posted about the destruction of confidential information that would otherwise be found on backup media. Beyond the discussion of suitable contract language is a conversation about a contract professionals’ understanding of the technology about which you’re drafting contracts.

The long and short of it is that you need to have a passing understanding of the technologies involved in any contract you’re reviewing. Why? Well first, it’s a requirement of the Five Fundamental Skills for Effective Negotiation (Information Gathering).  Second, assume for the moment that you are going to replace your network infrastructure from one manufacturer to another (these things happen more frequently than you’d imagine). To replace the existing technologies wouldn’t make sense without some amount of upgrades and network re-architecture (replacing old hubs with switches, etc). So the new vendor is offering a swap – hub for hub, switch for switch. Sounds good, right?

Before I tell you if it’s a good deal, what do you know about hubs and switches? Do you know how they work? Hmmm… that might not matter. It would help, however, to know how the devices are constructed. Hubs and Switches are physical devices that connect pieces of networks together. To do this, they have ports on them that accept ethernet cables… lots and lots of them. In other words, the value of a hub or a switch is not based only on whether it’s a hub or a switch (switches are more expensive), but on how many ports it has. So in this particular situation, you don’t just want a like-for-like swap, but also a port-for-port swap, otherwise, you could be giving up money without even knowing it.

Now, this issue also comes into play when you’re negotiating with smaller software vendors (called mISV’s – micro Independent Software Vendors) who sometimes sell software of a smaller dollar amount.  The mISV is quite sensitive to the costs, time and effort needed to work through their license agreement.  In fact, there’s a discussion going on right now over at Joel Spolsky’s Business of Software discussion boards on this very topic.  The mISV’s see the attempt at negotiation as costly and potentially harmful and their reaction is to tell the negotiator that no changes are allowed (they even use EULAs as a way to say it’s a non-modifiable form).

If you’ve taken the time to understand the product/service, there’s a chance that you won’t have to make a sweeping amount of changes to the document.  So, for example, if the product is a small desktop-based (non-networked) product, that doesn’t use ANY network resources (no internet access, for example).  Then I can relax my standards just a bit because now, if the product breaks, the likelihood of it taking down our network in the process is smaller.  So rather than lots of changes to their EULA, I will work with my legal and business folks to agree to only make two changes to the document:  1) Insert a warranty for exactly what the product does/not do – ie: no network access, doesn’t transmit anything, wholly desktop contained, etc; 2) Make the mISV liable for damages only if they breach this warranty.

In this way, I’ve lowered our risk, and I’ve only really made it risky for a deceitful mISV.

Oh, and while you hopefully have a subject matter expert hanging around to help you… you can’t count on them understanding the language enough to know to even ADVISE you of this issue. Because chances are they will make two fatal errors: 1) They believe what the vendor tells them, and 2) Absent blind faith in the vendor, they will also believe that technical people are all on the same page and that it’s only LOGICAL that the swap would be port-for-port.