Email this Article Email   

CHIPS Articles: Software Licensing — Smart Spending in These Changing Times

Software Licensing — Smart Spending in These Changing Times
By Sharon Anderson - July-September 2012
Billions of dollars are invested in commercial software across the Defense Department annually, but licensing rights are complicated and affect the total cost of ownership (TCO) for a command and the Department of Defense positively — if defined correctly — and negatively — if they are not.

Agreeing to standard terms and conditions can be hazardous to your program’s health and financial solvency. Companies change end user license agreements (EULAs) frequently and software buyers must stay on top of current trends and best practices to ensure their money is well spent and their programs are successful. Approaching the purchase of software licenses in a methodical way ensures consistency across the DoD and will yield better results for your organization and the department.

The DoD effort to function as an enterprise means we all should operate with the same commercial licensing strategies and contractual framework; the DoD Enterprise Software Initiative (ESI) was established to assist organizations in purchasing licenses and in IT asset management.

The term “EULA” has multiple connotations for commercial software. Other names include: Purchaser Use Rights, Software License Agreement, Software User Rights Agreement, and there can be others as well.

In this article, EULAs are defined as the comprehensive license agreement between the government and a publisher or reseller — which can extend beyond simply end user’s rights. There are different kinds of EULAs: commercial, General Services Administration (GSA), government and the ESI Enterprise Software Agreement (ESA) version.

When purchasing a license always ask if a government EULA is available and remember that the order of precedence is key in resolving any inconsistencies in the software publisher’s end user license agreement.

Software Acquisition Process

Phase 1. Assemble the Right Team

Assembling the right team is so important for a number of reasons, for example, requirements personnel may understand technology but not licensing which can be complex. Also project personnel may be so focused on the success of their program; they may not have the enterprise perspective in mind when purchasing software. Bringing in contracting personnel as early as possible into your process can go a long way in ensuring that the government’s interests are protected. The software acquisition process is summarized in Figure 1.

Phase 2. Define the Requirement

What do you need to do with the software? Will you need to manipulate data or just view static data? Will the software need to be shared inside or outside your business unit or organization? Define the scope of the project, will a test and development license suffice or will you need a full use license? Describe your requirement by giving examples and definitions to reduce ambiguity. Describe your customer base clearly: government, civilian, military, contractors supporting government. Will the software run on other devices or will there be other uses?

Define the number of years coverage is needed, and whether software distribution has been considered. For example, will you need hard copy media and is it identified and included in the purchase price? Is there a right (free of charge) to make unlimited copies of the software for internal use in non-production instances?

Is electronic download available or are there special distribution scenarios that need to be addressed in the requirement and used in the evaluation for award?

The software industry can be volatile with companies merging or going out of business, will you need an escrow agreement? An escrow agreement, sometimes called a source code repository, is the deposit of the software source code with a third party escrow agent. Escrow is typically requested by a party licensing software (the licensee) to ensure maintenance of the software should there be a "triggering" event. The software source code is released to the licensee if the licensor files for bankruptcy or otherwise fails to maintain and update the software as promised in the license agreement. Escrow is usually only applicable in critical use situations.

Phase 3. Select the Software

Seek advice from consultants, license experts, including the DoD ESI software product managers (SPMs –, a software attorney, or other DoD components that may have valuable experience in the selection and licensing process.

Use existing contracting vehicles when they are available. Define the process you will use to select the product or vendor to meet your requirement by outlining technical evaluation criteria. Ensure you comply with your service component policies for licensing commercial software.

If your process leads you to select a limited or sole source, you must provide brand name justification.

Phase 4. Validate Pricing

At this phase a best value analysis will help determine the true cost of the software. Analysis includes determining the TCO, terms and conditions and price. Do your homework; get a price estimate based on market research. Get the best pricing by considering market research findings and ensure discounts are appropriate for the size of the order. Spot discounting is expected when buying large quantities.

If the product is available on DoD ESI or SmartBUY, you must contact the SPM if you find that ESI/SmartBUY is not the best value. Often, price inconsistencies occur because the negotiated ESI/SmartBUY terms and conditions (Ts & Cs) are a better value, as well as the preferred Ts & Cs for the DoD.

There are several license models to consider:

Concurrent Users. License price is based on the maximum number of users who could be using the software at any given point in time.

Named Users. License price is based on the total number of individuals in the user population.

Processor Based. License price is based on the number of computers (CPUs) and cores to which the software can be deployed.

Enterprise. License price is based on a decision to deploy the software across an entire enterprise (as defined by the customer). This model is used primarily with large, multinational or global customers with a high numbers of users — usually more than 10,000.

Site Unlimited. This model is used primarily with large, multinational or global customers with a high number of users — usually more than 10,000.

Subscription. This model calls for periodic payments instead of a lump sum payment. It may also be selected when a customer does not want to deploy the software within its IT environment, as in a Software as a Service (SaaS) arrangement.

License Type and Use Rights Checklist

Identify how the product is licensed (named user, concurrent user, device, CPU, etc.) and specify if ownership is "perpetual" versus "term" or "subscription." A perpetual license allows use of the software for an unspecified period of time. The license is paid for once and does not need to be renewed. A term or subscription license grants end user rights for a specific period of time and must be renewed for continued use.

Identify the entities that are permitted to use the software (government and contractor) and fully define terms such as: enterprise, program, affiliate, internal use and subsidiary. Check for additional rights, for example, some licenses allow home use or on a laptop, in addition to the office setting.

Check for unusual license metrics such as usage charges tied to virtual machines or remote access.

Check for specific license restrictions such as those related to hardware make, model or geographic location.

Contracting Vehicle Priority Sequence

You must use the preferred methods of purchase in order of precedence as defined in Federal Acquisition Regulation (FAR) 8.002 and Defense Federal Acquisition Regulation Supplement (DFARS) 208.002 which specify use of government supply sources for purchasing software licenses. Considerations most pertinent to commercial off-the-shelf (COTS) software acquisition:

  • DoD ESI Inventory — check for "Inventory Box" at;
  • DoD ESI/SmartBUY;
  • DoD ESI specifically cited in DFARS 208.74;
  • DoD SmartBUY policy memo of Dec. 22, 2005. Visit and;
  • DoDI 5000.2, Enclosure. 5, paragraph 1. c. 6: "When the use of commercial IT is considered viable, maximum use of and coordination with the DoD Enterprise Software Initiative shall be made;"
  • Component-specific policy;
  • GSA schedule;
  • Other existing contracts; and
  • Open market.

Figure 2 summarizes the process for a DoD program to follow when it has been determined that: (a) commercial software may satisfy the DoD program’s requirement and (b) ESI has an agreement in place for the product(s) required.

Although using a DoD ESI end user license agreement will ensure that the terms and conditions have been "scrubbed" for you, you should still specify definitions and examples of intended use to eliminate ambiguity. Clearly define additional license rights and specify the addendum changes that are at no additional cost. Check that a right granted in one area of the agreement is not changed or removed by another provision in the agreement. This is important because COTS software procurement agreements generally involve multiple, and often conflicting, sets of terms and conditions.

Every software publisher has a unique end user license agreement and a vendor (may be the publisher’s reseller) proposal may add additional Ts & Cs. DoD ESI license agreements resolve conflicts in the terms and conditions. ESI/SmartBUY agreements are based on the GSA schedule but with negotiated and enhanced Ts & Cs that provide the best value to DoD for COTS software. Especially when buying software not included in the DoD ESI, check the EULA to ensure that provisions are not in conflict with federal procurement laws. Ensure rights are clearly defined, quantifiable and predictable.

Top 12 Key Clauses

End user license agreements typically include the following clauses: Warranty, Transfer Rights, Third Party Software, Click-Wrap Licenses, Audit Rights, Automatic Renewals, Termination Rights, Governing Law, Order of Precedence, Installation Restrictions, Virtualization and Maintenance/Assurance. Examples of acceptable and unacceptable clauses are available on the DoD ESI website:

Warranty. Understand the warranty protection afforded by the FAR; ensure the warranty begins with productive use, not with delivery and that the buyer’s requirements are adequately documented.

Transfer Rights. Add language in the terms and conditions of your order with those Ts & Cs taking precedence over the EULA that allow for transfer of your licenses within an affiliate of DoD. This is a critical advantage because organizations within DoD frequently merge, realign or are disestablished. Continued use of the software under these conditions ensures that new licenses will not need to be purchased. At a minimum, obtain transfer rights within your component, for example, Department of the Navy, Department of the Army, and Department of the Air Force.

Third Party Software. Embedded third party software could increase the cost of procuring the software over time. DoD must be aware of third party software requirements embedded within the EULA, and you must consider the risk of procurement.

Click-Wrap Licenses. Third party software may include a click-wrap agreement which is unacceptable. Publishers of shrink-wrap software or online applications generally use click-wrap licenses to obtain end user consent. But agreeing to the terms and conditions specified may cause potential compliance problems. Understand what the EULAs state and try to eliminate this requirement in your terms and conditions, in other words, your defined Ts & Cs should take precedence. The ESI end user license agreement includes language giving precedence of the ESI EULA over a click-wrap license, thereby voiding any conflicting click-wrap license terms and conditions. In this case, users can click "accept" if necessary without jeopardizing the terms of the ESI EULA.

Audit Rights. You should pay close attention to audit rights. The DoD recommends incorporating audit rights specifying that the buyer (DoD) should perform self-audits and report no more than once per year. Ensure self-audit clauses do not allow access to a government network or site without prior consent and by individuals who do not meet the security requirements of your organization. Audit clauses may not contain language that obligates the government to pay for the audit. An essential note here is that you understand the type of license you have and know how to count actual use in your organization. Put in place a process for IT asset management for the program, business unit or organization covered by the EULA.

Automatic Renewals. Avoid automatic renewal clauses. Potential anti-deficiency issues could arise. You should have a process in place that will alert you when subscriptions or maintenance and support agreements are about to expire.

Termination Rights. Understand the implications to software use and maintenance rights if an order is terminated without completion of expected payments. Address retention of rights when vendors are bought by other companies or when products are re-packaged under another name. Beware of any clause that gives the vendor the right to terminate or limit the government’s rights upon termination.

Governing Law. Federal law shall apply and govern the terms of the software license. The terms and conditions of the EULA or the ordering documents shall reflect that federal law \will apply to the government contract and therefore federal courts will have jurisdiction in case of a dispute. Buyers should be careful not to allow a Choice of Law (COL) provision from the publisher. Such a provision would be invalid by law, but it could cause an unnecessary disagreement with the publisher.

Order of Precedence. DoD terms shall take precedence over any conflicting terms in a vendor’s agreement. If you are not able to change the EULA, have the terms of your order take precedence over the publisher’s EULA. If you are working with a reseller, get a letter from the publisher or original equipment manufacturer (OEM) indicating agreement to your terms and conditions.

Installation Restrictions. Some publishers specify installation restrictions, for example: "You shall only install the software on hardware approved by the software vendor." Be aware of hardware restrictions since they could impose significant cost to your program. This is a risk that you may not overcome. It should weigh heavily in your decision to acquire the software. You should be aware of the additional expense to licensing costs in a multicore processor implementations.

Virtualization. If you intend the software to operate in a virtualized environment, you must negotiate this requirement in your terms and conditions. Remember when you virtualize hardware you still need a software license for the virtualized servers. Be aware of this requirement because it can increase your total cost considerably.

Maintenance/Assurance. What does software maintenance include? Understand the terms of the software maintenance. Know your rights. Clearly define the scope of maintenance that is included in the price. For example, updates and patches may be provided as a license right and may not require the purchase of maintenance. Major releases and upgrades may be considered the right to a future version of the software, and therefore, would be considered software maintenance.

A right to future versions is usually considered software maintenance. Technical support is dependent on the publisher and may or may not be included in a maintenance agreement. Other benefits such as training are dependent on the publisher, as well, and may or may not be included in maintenance.

Software maintenance is often considered a "product." GSA schedule definitions have changed; see GSA special item numbers (SINs) 132-33 and 132-34. The determination of product or service could affect the allowable contract coverage period and funding.

One Final Word

The DoD ESI team likes to say — "Measure Twice, Cut Once" — in other words carefully consider your requirements and options, use the Software Buyer’s Checklist available at, consult a software attorney, if you have one in your organization, and consult with other experts and your contracting team to ensure that you are getting the best value for your organization and the DoD when acquiring software.

You don’t have to go it alone! The DoD ESI website features a resource library to assist ESI customers and vendors in locating helpful policy information, tools and links in one convenient location, please visit:

Sharon Anderson is the CHIPS senior editor. She can be reached at

Figure 1. Sample Software Acquisition Process
Figure 2. COTS Ordering Process - there are two basic paths
Related CHIPS Articles
Related DON CIO News
Related DON CIO Policy

CHIPS is an official U.S. Navy website sponsored by the Department of the Navy (DON) Chief Information Officer, the Department of Defense Enterprise Software Initiative (ESI) and the DON's ESI Software Product Manager Team at Space and Naval Warfare Systems Center Pacific.

Online ISSN 2154-1779; Print ISSN 1047-9988
Hyperlink Disclaimer