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).