You are here

Software Contracts

What licensing (usage) rights come with the software you’re buying?

You almost never own software; you lease the right to use it. You may have perpetual (permanent) rights to use it, but that’s not the same as ownership. Your rights are limited to uses spelled out in the contract, and it’s these uses where most complexities arise in negotiations and related financial discussions.

Software publishers offer a wide range of licensing plans from  la carte menus of options to a single choice. Consequently, you must know your needs in order to ask the right questions and to make the most informed licensing choices.

A good approach is to plan on usage changes and have contractual mechanisms that are flexible; otherwise, you’ll end up repurchasing software or re-licensing it, as the vendor dictates—both likely to be expensive propositions. During contract negotiations, create a spreadsheet model to use as a guide and input forecasts of current and future costs based on different licensing scenarios, such as an increase or decrease in number of employees, expansion overseas or switching to a different software vendor. For example, if you purchase a perpetual license for 1,000 users and your company grows to 2,000 users 10 years later, you won’t automatically have usage rights for the additional 1,000 employees unless your contract is flexible. The second 1,000 would be a separate transaction or an opportunity to negotiate a new deal for 2,000 users.

Know your needs

Term vs. perpetual: Know how long you need a license

Typically, SLAs feature either a perpetual or term license. Perpetual means you can use a version of the software under your licensing terms forever, without having to pay additional fees as long as you comply with the license terms.

Perpetual licenses are always preferred, but if a limited term is required, the best practice is to include the option to terminate the agreement and renegotiate terms (a smart safeguard in case prices go down) and a right to renew at predetermined rates and on the same terms.

Term licenses expire after a period of time. Application service providers (ASPs) and software-as-a-service (SaaS) arrangements are term licenses.

The choice between license types hinges on economic and software asset management factors. Pay close attention to renewal language and future pricing considerations. If the agreement automatically renews, require written notice prior to renewal with sufficient time to permit you to terminate.

Know who will use the software, where and how

Scope of use is the term referring to where and how the software will be used, and by whom. Scope of use can dramatically affect pricing. For example, home and office use may be more expensive than office use only. Unlimited use by a large number of people is sure to be more expensive than shared (concurrent) use by a fixed number or users. Software scope of use is generally tied to a measurable maximum—the purchaser’s number of users, employees, location, CPUs, power of CPUs or for a defined set of uses. The metric, or method of measuring software use, should be easily calculable and verifiable. Also be sure to calculate in your total the needs of users, such as outsourcers, consultants, temporary hires, overseas locations, remote or home use, not just your local personnel.

Low-cost, limited scopeof-use licenses can save money initially, but they come with heightened administrative burdens of monitoring and reporting. In the long run, the convenience of more expensive enterprise-wide usage rights, which require little or no administrative management, could be worth it.

Software applications that span companies and encompass hundreds or thousands of end users (e.g., e-commerce, IT service catalog or request applications) present more complex access situations. These should be detailed explicitly in the contract. 

What is source and object code?

Source code is the set of programmatic statements created in a structured (programming) language by developers, permitting software to execute intended functions. Object code is the output of a compiler after it processes source code. The compiler transforms the source code into a program the computer can execute.

License grants are usually limited to object code. In an escrow agreement, the vendor may make source code available. At a minimum, the licensee should be entitled to withdraw the source code from escrow in the event the vendor becomes bankrupt or insolvent, or ceases to conduct business or ceases to adequately support or maintain the software in accordance with the agreement. In software asset management, escrow is a legal arrangement whereby source code for acquired software is stored under the trust of a neutral third party and released only when a contractual contingency or condition is met, such as bankruptcy or when a party goes out of business.

Other breaches of the agreement may also serve as the basis for obtaining the source code (e.g., assignment to the licensee’s competitor). When you are paying for the escrow, add audit provisions to ensure the vendor lives up to its obligations (e.g., vendor pays for audit if you discover material omissions in the escrow deposit).

Common mistakes to avoid in software contracts

It seems obvious that a contract for software, or any product or service, should clearly identify what is covered under the agreement. However, in many contracts, the description is vague or too general for the buyer to be certain of the components purchased. It’s in your best interest to ensure that the contract clearly details what is covered, especially if the software has many components or options. Include references to any services included in the purchase price, such as prepaid maintenance, installation, training, data conversion, testing and migration. Also, SLAs should spell out the options included, such as components, databases, operating system, languages, APIs (application program interfaces) and converters. If you do not clearly know what you are purchasing, you could pay later for options you thought were included.

The contract should clearly spell out the list of software you are purchasing by name, quantity and any versions associated (e.g., version number 3.5) and be as detailed as possible. A surprising number of contracts fail to specify such basic information as the manufacturer’s part number, title and description.

Information about which platforms and operating systems the software will run on should also be listed. The list of software and its description should be in an attachment to the main contract (i.e. not the body of the contract itself), which is called a product schedule. This allows you to easily add products later or negotiate price modifications, without affecting the main contract.

A common mistake is allowing the contract to refer to a vendor’s Web site for a product description or legal language, or some other external reference that may change, disappear without notice, or become outdated.

The software list should match the item detail on the invoice you’ll receive from the vendor. Remember to list any important no-charge items as included in the price. For example, compilers, utilities or extra products that are part of a product bundle.

Your contract should detail the software you are licensing. Include the following:

  • Products by name, number, version

  • License fee (future license purchase fees)

  • Delivery terms and dates 

  • Form and media (download, disk, tape, CD)

  • License upgrade fees 

  • Acceptance criteria

  • Is object and /or source code included?

  • Is documentation included (describing what the software does) and in what format (CD, book or other)? Note how many copies you are allowed to make of the documentation.

  • Is education and training included?

  • Are installation services included?

Ten essential SLA considerations for license agreements

Software license agreements, with few exceptions, include terms and conditions in 10 broad areas. This guide presents the subject in plain English in the form of questions to ask and points to consider during the negotiation or contract evaluation process. Our approach aligns IT procurement’s objectives with the business user’s needs. Here are the 10 key areas:

  1. What software are you buying and what services does the contract include?
  2. What usage (licensing) rights come with the software you’re buying?
  3. Where is the software running and who controls it (application service provider,software-as-a-service, virtualization)?
  4. When will you pay for the software?
  5. How much does the software cost now?
  6. How much might the software cost later?
  7. What happens if there is a dispute or suspected contractual variance?
  8. What happens if the relationship ends or changes significantly?
  9. What common terms (“boilerplate”) help define a complete legal agreement?
  10. For custom development or custom implementation, what constitutes acceptance of the customized software? Who will support and control the customizations?
Subscribe to Software Contracts