What Did I Really License? – Article

[NOTE: This is another in the series of repostings of my previously-published articles. This article was written in 2003 for Practical Technology Contract Review News email newsletter I used to publish. It was part of a series of articles explaining the various sections of IT agreements and how to think about them. This article is a companion piece to the "5 Ws of License Grants" article I reposted today.]
What Did I Really License?
I want to take a closer look at the fundamental issue of what you are licensing. I’ll give you some tips for analyzing whether the contract language you have is adequate, especially as it relates to software. I am constantly surprised at how often the definition and description of software being licensed varies from what both parties intend.
Software companies have a tendency to use old software license forms long after they have outlived their usefulness. These agreements often leave many issues unaddressed and invite problems in the future.
Your mission in negotiating these agreements is to document what you are actually paying for. Many times, that may take more work than you might expect. Here are five items to put on your checklist.
1. Accurate Definitions. What does the definition of “Software” actually say? Is it what you expect? Often, program names turn up in contracts that are different from the program names you expect. Do not assume that the name you see in the contract is correct. An agreement for another program could have been reused for your agreement and may indeed have the wrong programs listed. Are all necessary components or modules listed? Expensive results may occur if key components are left out.
Are there necessary utilities, installers or other programs that should be included? Are you getting the current version, the Windows version or whatever other version you need? Don’t be afraid to ask for specific details.
2. Number of Copies. Does the license include the right to make the copies you need. Many licenses are quite specific that you can only make one backup copy of the program. In today’s world, that makes no sense. Multiple copies of the software will probably reside on backup tapes. Most organizations today prefer to use installation disks for workstation installations, create disk images and have multiple backup and even disaster recovery operations. I like to specify these normal uses and “copies incidental to the operation of the computer,” since the program will be copied into RAM, a browser creates history and temporary Internet files and no one knows how many copies Windows makes of everything and where it stores them.
What about copies for notebook computers and home computers? Does your remote access system “create” another “copy” of the software for the remote user? Perhaps these may seem to be minor issues in the big picture, but the “copies in RAM” issue has been litigated with a finding that the copy in RAM was a reproduction for copyright infringement purposes. Also, why start out under an agreement of which you are in technical violation from the date of installation?
3. Versions, Upgrades, Updates and Similar Creatures. The world of software has a bewildering number of terms, all with slightly different meanings, for modifications to software. There are fixes, patches, updates, modifications, upgrades, point versions (e.g., 3.1, 3.2), versions, and even more. In your agreement, you care about which you have to pay for and which you do not. Try to avoid being silent on this issue. You will not like to be forced to pay for an upgrade that seems to you like an update or a full version that seems like a point version.
Ask the specific questions and memorialize the deal accurately. Deals can fall through on these issues. Also, be sure to know what happens if key features of the software are moved into another package (especially important in the case of a change in ownership) or if the company no longer supports or develops the software. Not complicated enough? What about required upgrades that force you to move to a new version of Windows, for example? Spending a little more time addressing the drafting issues upfront will avoid expensive business issues latter.
4. Source Code and Object Code.The object code of a program is the form of code readable only by machine. The source code is what the programmers write and is, at least in theory, understandable to some humans. Almost all software is licensed in object code. However, if your deal contemplates any modifications or development by you, you must have a license to use and modify the source code. If you are dealing with someone on the other side does not understand this, you must find someone else who does.
Licensing source code raises a number of thorny issues, include whether to have a source code escrow agreement. In your review, you will want to see assurances that the source code is the actual source code, that it is written and documented in a way that programmers can reasonably understand, that it also includes all code and tools to enable the program to operate, and that you continue to get source code for any modifications.
5. Documentation. Don’t assume that because you license the software you’ll be getting copies of the manuals for all your users. Some license agreements fail to mention documentation. Some license agreements fail to describe it adequately. Some license agreements limit you to a single copy of the manual and documentation. Check the language and then ask that it be changed to reflect what you want.
If you are going to sign a software license, it only makes good sense to make sure that it actually describes what you are getting. Start asking the right questions.
[Originally posted on DennisKennedy.Blog (http://www.denniskennedy.com/blog/)]

This post brought to you by Dennis Kennedy’s legal technology consulting services, featuring RSS and blogging consulting, technology audit, strategic planning and technology committee coaching packages especially for medium-sized law firms (15 – 100 lawyers) and corporate legal departments. More information on the “Second Pair of Eyes” packages for legal technology audits and strategic planning may be found here (PDF).

The 5 Ws of License Grants – Article

[NOTE: This is another in the series of repostings of my previously-published articles. This article was written in 2003 for Practical Technology Contract Review News email newsletter I used to publish. It was part of a series of articles explaining the various sections of IT agreements and how to think about them. It really doesn't get any more basic that getting the license language to match what you want in your deal, but you'd be surprised how often that is not done well, especially in the first drafts of contracts.]
The 5 Ws of License Grants
Nearly every technology contract today contains at least one license grant provision. Most commonly, there will be a software licensing clause, but trademark, copyright and even patent licenses have become common in everyday technology contracts.
I have often been surprised when I review a contract prepare by a vendor to find that the license grant is not even close to what is anticipated by the deal, let alone what either the licensor or licensee actually wants. License grants are not “one size fits all” clauses. Because the license is a key to the deal, a license grant provision should never be treated as a stock or off-the-shelf clause. It’s one clause that you want to get exactly right because if you don’t get the rights you need now, you will probably run into problems later.
Getting a license grant right takes some effort, but simply focusing on the simple five Ws – who, what, when, where and why – that we were taught in school will put you ahead of 95% of people reviewing license grants. These may seem like basic questions, but, believe me, there are no stupid questions when it comes to reviewing license grants. You want to make sure that you understand the language and that it covers what it is supposed to cover.
1. Who? Don’t take this question for granted. Who is licensed? Your company and employees? Yes, but is the correct company licensed? What about affiliates and subsidiaries? Employees of affiliates and subsidiaries? Do you use part-time employees or other independent contractors who are technically not “employees”? How about third party consultants who install, maintain or work with the software? Customers? Potential customers you want to allow to demo the software? Other users? I’ve seen questions come up in each of these categories.
2. What? What exactly is being licensed? Is it just object code of software? Do you want source code as well? How about documentation? Trademarks? Copyrights? Compare what you think you are getting to the license grant language to make sure that you are getting everything you expect.
3. When? Many license grant provisions do not spell out a duration of the license grant, leaving at least three interpretations – the grant is perpetual, the grant is equivalent to the term of the license agreement or the grant is for a “reasonable” period. Nail this question down and save yourself from any later trouble. As a general matter, setting the duration of the license grant equal to the term of the agreement (including renewals) is the most logical approach.
4. Where? I once reviewed a license for a mobile software application that was going to be used by technicians in their cars. Incredibly, the first version of the license grant provision from the vendor included language that the software could only be used at a specific address! Obviously, someone had simply used an old license agreement as a model with no awareness of the consequences. Sadly, I am sure that some licensees simply signed this “standard contract.”
Site licenses or machine or location specific licenses were common in the mainframe era and that type of language occasional slips into today’s license agreements. In the case of software especially, you want to determine where the software will be used and be sure that the license grant authorizes use in those locations. Will employees be running the program at home or on a laptop? Will they be accessing the program remotely? PDAs and wireless devices also may require modifications to standard license grant language. Be wary whenever you see any type of site license language.
Another “where” issue arises in the case of license grants for particular territories. Check the definition of territory carefully and consider how it may affect e-commerce or web marketing.
5. Why? Why are you obtaining the license? Is it exclusive or non-exclusive? You’ll want to proceed with caution any time an exclusive license is involved. Also, it has become fairly common to grant licensees the right to “use” software or other intellectual property rights. Unfortunately, “use” is not one of the exclusive rights granted under the copyright statutes (reproduce, make derivative works and publicly display are a few examples) and it is only one of the rights patent holders have (make, sell and offer to sell are others). It is, therefore, important to spell out exactly what rights you want to license using the precise terms, especially if you want to make derivative works or to grant sublicenses rather than to rely on a court later interpreting the word “use” to include these rights.
The license grant may well be the single most important section of any technology agreement. If you aren’t specifically granted the rights, you probably don’t have the rights. Why take chances?
By using the simple 5 Ws approach, you can go a long way toward quickly getting a license grant provision in shape. You will not only have better and more accurate language, but you can then use your attorney more effectively to work on more important issues than simply making sure that the language at least covers the deal. As a result, you’ll shoot to the top of the class in being able to review license grants.
[Originally posted on DennisKennedy.Blog (http://www.denniskennedy.com/blog/)]
This post brought to you by Dennis Kennedy’s legal technology consulting services, featuring RSS and blogging consulting, technology audit, strategic planning and technology committee coaching packages especially for medium-sized law firms (15 – 100 lawyers) and corporate legal departments. More information on the “Second Pair of Eyes” packages for legal technology audits and strategic planning may be found here (PDF).

“By Request Day” – What Are Those Funny Symbols in Some of Your Posts?

Here’s what I’d like to say: Writing on the Internet requires that you consider a different type of reader and that you accommodate a reader who likes to scan. Although some recommend avoiding long posts, like I have been known to write, if you write long (or short) posts, you want to break things up into short paragraphs, use headings, bullet points, bold and italics, and make the posts easier to read and visually interesting.
The funny little symbols and characters, I’d like to say, are a clever device to create visual interest and give my readers something break up the parade of words on a page.
That’s what I’d like to say.
Unfortunately, the real story is this:
I sometimes write posts in Word. In the case of my reposted articles, I create the posts from Word documents. I might also copy portions of Word documents into my posts when I write them.
Unfortunately, in some Word documents I had turned on the “smart quotes” or “curly quotes.” For reasons I don’t understand, my version of Movable Type does not handle those curly quotes as regular quotes. Even worse, I cannot see that there is a problem when I “preview” he post before I published it. Even worse than that, I don’t see the problem in my newsreader when I view the RSS feed for my blog. That’s important because I don’t often look at my blog in my browser, but I do look at the feed in my newsreader.
What I’ve learned is that the “smart quotes” and the “smart apostrophes” turn up as odd symbols and characters on my blog rather than as regular quote marks and apostrophes. I then have to edit the original post, change the quote marks and apostrophes (which are visible at that point in Movable Type) and republish the post. It’s a pain and it’s not a task that ranks high on the priority list.
I’ve now found a few tricks that usually catch the problem before it happens, but the problems occurs every now and then, especially in the reposted articles. I’ll eventually find a more or less fool-proof method, but that’s the explanation. If you can visualize a quote mark or apostrophe when you see those funny symbols, you’ll know what I meant – but you were probably already doing that.
[Originally posted on DennisKennedy.Blog (http://www.denniskennedy.com/blog/)]
This post brought to you by Dennis Kennedy’s legal technology consulting services, featuring RSS and blogging consulting, technology audit, strategic planning and technology committee coaching packages especially for medium-sized law firms (15 – 100 lawyers) and corporate legal departments. More information on the “Second Pair of Eyes” packages for legal technology audits and strategic planning may be found here (PDF).

“By Request Day” – Read Any Good Books Lately?

I’m always interested in what books people are reading and what they like. I always try to read books that people recommend to me. Lately, my brother and I have been recommending spy novels and thrillers back and forth. A few years ago, I gave him a Robert Ludlum book and he stayed up all night reading it. That started us on passing books back and forth.
There are two books that I’ve read recently that I highly recommend for the audience of this blog.
The first is Gerry Riskin’s The Successful Lawyer – a great collection of practical wisdom on a variety of subjects involved in the practice of law or any other profession. It’s also available with a companion audio CD through the ABA Law Practice Management book store.
Earlier in my career, I had the chance to participate in the Edge Group’s rainmaker education program at my law firm. I’d rank it among the very best training I ever received as a lawyer. I mention this because this book includes the core principles from that rainmaking course. They’re solid, practical and well-supported by my experience.
The book has 49 short chapters, each of which is packed with a punch and great practical tips. In fact, each chapter is like the conversation you would have liked to have with a mentor or experienced colleague during your career. It’s a book that you can read quickly, if you want, but also one that you will want to return to again and again and work through the ideas and exercises in it. Add me to the long list of fans of this book. It’d be a great gift for yourself or for a lawyer you know.
The other book I want to recommend is Bob Burg’s Endless Referrals, just out in a third edition. Ironically, I met Bob recently via email when I committed one of the cardinal sins of emailing people you don’t know – accidentally using the wrong name in the salutation to the email. Even worse, I didn’t realize who Bob was until he sent me a polite reply and we exchanged a few emails and got to know each other a bit.
Finally, I realized that Bob was the author of Endless Referrals, a book that I had found quite valuable when I began my solo career. Bob told me that a new edition of the book was out and asked me if I wanted to get an early review copy. Of course, I would.
Bob sent me a copy and I devoured it in one setting. I think that this is a gem of a book that is required reading for anyone who has customers or clients or works with other people. That, I believe, would be everyone. The book is about principles of business networking, but it goes far beyond that.
The money quote:
All things being equal, people will do business with, and refer business to, those people they know, like and trust.
Think about blogging in that context.
Like Riskind’s book, this book is full of practical information that you can really use, including suggested language for certain conversations. I dog-eared a lot of pages in this book. I was also surprised to see how much of Burg’s advice from the earlier editions I had internalized and made part of what I do. Even if you have read the earlier editions, the third edition is still a must-read.
As an aside: I’ve been sounding out a few people about using Skype chat to create a book group to discuss books like these on a regular basis. Let me know if you might be interested.
[Originally posted on DennisKennedy.Blog (http://www.denniskennedy.com/blog)]
This post brought to you by LexThink!(TM) – The Conference, Re-imagined. LexThink! – Think big thoughts, do cool things, change the world. Ask us about private LexThink retreats and conferences for your firm, business or organization.

Seven Dangers in Using “Standard” Forms for Law Firm Technology Use Policies – Article

[NOTE: This is another in the series of repostings of my previously-published articles. This article was written in 2004 in connection with a presentation I did on technology use policies for law firms. Although it focuses on the issues that face law firms, the same principles apply in many different contexts. Forms can be quite helpful as long as you know how to use them]
Seven Dangers in Using “Standard” Forms for Law Firm Technology Use Policies
“We need a technology use policy. Why don’t you hop on the Internet and grab one that we can use?”
This conversation is all too common. The question asked is meant to be a rhetorical one. You will be better off if you treat it as a real question and think carefully about the answers to that question.
There is almost no limit to the dangers you can run into when you “grab a form” off the Internet. This article talks about seven of the most worrisome dangers.
Danger #1. Forms May Be Used As Something Other than Checklists of Issues. When I was co-teaching a law school course on drafting technology agreements, we started the course with a discussion of the use of forms. Our key point was that you have to consider forms as checklists for issues to consider, provisions to include and points to clarify. They should not be seen a complete in any sense or as covering all possible issues. They definitely should not be seen as something to grab and use. Take a form and think through the application of each section to your situation. Does it apply? Does it reflect the approach you would take? Does it raise other issues? Use a form as a checklist, first and foremost.
Danger #2. Forms May Be Outdated and Wrong. How comfortable would you be using a technology use policy from 1995? If you grab a form on the Internet, how do you know that you are not doing exactly that? Be aware that policies you find might be outdated and not cover issues that now affect you. Even worse, they may reflect an approach based on a misunderstanding of applicable law, a failure to consider applicable law or a misguided approach to relevant issues. Be very careful about assumptions that you are making.
Danger #3. Forms May Not Even Address Your Issues. Law firms have some unique issues because of confidentiality obligations to clients, ethical rules and other issues that affect the legal profession. A standard form that you find on the Internet or in a form book might not even address these issues, let alone address them correctly. The form you find might not cover home computers, blogging, instant messaging or other issues that are important to you. It is too easy to treat a form as being “complete” and, as a result, fail to cover key issues.
Danger #4. Forms May Make Decisions For You without Appropriate Consideration. There is not a single, perfect approach to technology use policies. Each policy reflects a consideration of unique issues and a large number of decisions. Similarly, any form will embody a large number of decisions on issues. Some forms take a middle of the road approach. Some forms, unknown to those who use them, take more radical approaches. Your only guarantee is that it is all but impossible to expect that any form you find will reflect all of the decisions that you would make on each of the underlying issues. Every sentence in any form could be written differently depending on the underlying policy. When an issue later arises, it will not be comforting to keep saying, “But, it was in the form.”
Danger #5. Forms May Let You File and Forget. The use of a standard form makes it very easy to file and forget your technology use policy. The whole approach trivializes the importance of the policy. Rather than posting it, publicizing it and training people to follow it, you will likely file it and forget about it. That will come back and haunt you.
Danger #6. Forms May Relate to a Different Regulatory Scheme.b Surprise! The legal profession has its own ethical rules and regulatory issues. Other industries have their own rules and regulations. If you grab a form, you may inadvertently use a form from a company with different requirements while missing rules and regulations that apply to you. Neither result is a good one.
Danger #7. Forms May Allow You to Avoid the Real Work You Must Do. When you grab a form off the Internet, change a few words and announce your new policy, you neglect very important aspects of creating a technology use policy. You do not do the research necessary to understand how people use technology in your firm and what unique issues your firm may have. You ignore the value of putting together a team to put a policy together. You also treat the policy as fundamentally unimportant. You guarantee an unhappy experience in the future.
Conclusion.
The best approach to creating a technology use policy is to do the hard work, make the hard decisions and move to drafting the policy at the point that you are ready to document and memorialize your decisions. A form that you find can serve as a model or as a checklist, but should not be anything more than that. Your policy should be your policy – your policy should not be dictated by someone else’s forms.
[Originally posted on DennisKennedy.Blog (http://www.denniskennedy.com/blog/)]
This post brought to you by Dennis Kennedy’s legal technology consulting services, featuring RSS and blogging consulting, technology audit, strategic planning and technology committee coaching packages especially for medium-sized law firms (15 – 100 lawyers) and corporate legal departments. More information on the “Second Pair of Eyes” packages for legal technology audits and strategic planning may be found here (PDF).