When developing Requests for Proposals (RFPs) and working through the entire software purchasing process, there are a significant number of details that need to be considered. One issue that should be on the minds of the software purchasing organization is, “how am I going to manage this software once I purchase it – this includes knowing where it’s installed, what I’ve purchased and reconciling software installations against entitlements to ensure the organization is in compliance”? Depending on the overall maturity of the SAM process for the organization, answers will vary significantly. This article provides contract and RFP suggestions your organization can use to ensure the manageability of software and license reconciliation as well as to set the stage for future automated procedures.
Download the TagVault.org flyer that provides details on how your organization can help facilite the much needed capability of accurate and authoritative inventory in the software market.
What you need to know is that if the management of the software is not handled properly the purchasing organization can be setting itself up for an audit that disrupts business operations. If the audit results in a negative finding from a license compliance perspective, that could require unexpected and unbudgeted additional licensing costs as well as potentially large fines, loss of market respect and potentially even further legal challenges.
Managing software licenses is difficult in today’s nearly infinitely varied IT environment. However, standards are starting to be created that will help with the on-going management of software license reconciliation. These standards are being created by ISO/IEC and the details of these standards are summarized in the standards overview article published by TickIT International (see page 17 of the Journal).
How can TagVault.org help your organization mitigate the risks associated with software license management? Essentially, TagVault.org can ensure that software you purchase provides specific details for software identification that are consistent, reliable and standardized. TagVault.org is the registration and certification authority for software identification tags (based on the ISO/IEC 19770-2:2009 standard). All software publishers who are members of TagVault.org can certify their tags to ensure they conform to the ISO/IEC 19770-2 standards requirements as well as conform to additional market requirements as specified and documented by TagVault.org members. This means that when your organization does a software discovery, it can discover software installation details on every device (regardless of platform) that indicates exactly who the licensor of the software is, the specific title of the software (that will match the vendors details provided on the software purchasing paperwork) and other details that will assist in the SAM reconciliation process. This is done without relying on an application recognition engine that attempts to identify software installations via an archaeological process that may or may not be accurate, consistent, or in agreement with the software vendors expectations or terminology.
How can you make certain that software your organization purchases includes accurate and useful software identification tags? Specify the requirement in the initial RFP and utilize these requirements throughout the purchasing process. The United States Air Force is already starting to require software identification tags in their RFP’s. Your organization can and should require software identification tags as well. But how do you ensure the software identification tags conform to the specification and have data consistent even for one publisher, let alone multiple publishers with multiple applications for multiple platforms? You specify the requirement up-front in the RFP and ensure that tags have been checked and certified for consistency. Here’s some language you can use in your software purchasing process to ensure you get software identification tags that your organization can actually use. Note that terminology provided here may not match the requirements for your organization. Validate the expectations and terminology with your own legal council to ensure they meet your organizations requirements. Negotiation points are included to provide details on the principles of the proposed wording so you can ensure the final terminology meet the needs of the organization.
Require accurate and useful software identification tags in every software title
Language to use in RFP/Purchasing agreements
|
All Software purchased under this RFP must include software identification (SWID) tags as specified by ISO/IEC 19770-2:2009 if the software title is released after July 31, 2010. These tags must meet the following criteria:
-
SWID tags must be TagVault.org certified.
-
This requirement applies to all new titles, editions, versions, upgrade, maintenance or patch release, etc (excluding security patches) released after July 31, 2010.
-
Software Suites or Bundles must include certified SWID tags for the Suite/Bundle as well as for every component product that may be installed as a stand-alone product.
-
Upgrade products must include the ISO/IEC 19770-2:2009 specified elements of product_id and upgrade_for.
-
Certified software id tag data must be available in publically accessible TagVault.org repository.
|
Key negotiation points include:
- As an organization, you need to make sure you’re getting accurate and useful information your organization can rely on when doing license reconciliations. You also want to ensure that information you get from one publisher or for a specific platform matches the information you receive from a different publisher or for a different platform – hence the need for support from a registration & certification authority.
- The discussion and agreement needs to include a date by which all releases will include a software tag. The specifics of the date can be negotiated, but should not be left open ended – a specific deadline should be agreed to.
- By including upgrade, maintenance and patch releases, legacy software that may initially be installed without a software identification tag will eventually be tagged as the updates are installed.
- A vendor may choose not to include a certified tag in an urgent security patch to ensure there are no issues regarding the timing and release process for these patches.
- Finally, specific elements may be required to ensure license reconciliation can be handled properly. This includes details for bundles/suites and for upgrade information. TagVault.org is working with the GSA as well as with large end-user organizations to better understand and define the requirements for SWID tag data requirements that ensure software purchasing organizations receive enough specific asset data to effectively manage software assets for their respective organizations. In the case of the GSA, this includes more than 5 million windows computers (not to mention other client and server platforms this will apply to) with a wide variety of software products from a wide variety of software vendors. See the TagVault.org article that provides information on this working group session.
Ensure there are ramifications to software vendor that do not live up to the promises they make on delivering software identification tags
Language to use in RFP/Purchasing agreements
| Publishers have the right to audit software titles purchased under this contract that meet the SWID Tagging requirements as specified in this contract. |
Key negotiation points include:
- Software publishers need to have the rights to audit an organization to ensure they are in compliance with software licensing entitlements and will not give up that right – this statement is not removing those rights.
- This statement does not limit a software publisher from auditing software that is not included in this contract.
- This statement does not require that the software identification tags be the basis for an audit. What the purchasing organization is looking for is that the publisher provides explicit and standardized identification information as part of the software installation for all titles purchased in the timeframe specified. As long as the publisher follows these expectations, there are no limitations on their existing audit clauses.
Finally, help your software vendors (regardless if you’re purchasing directly from the publisher or through a distributor) recognize that they need to help in the reconciliation process.
Most distributors already provide many of these details to their larger customers; there is one key data element that needs to be added to these reports to make them even more useful:
- Vendor will provide an annual report of software purchased under this contract.
- This report must minimally include:
- Product title,
- Quantity purchased,
- The software unique identifier as included in the certified ISO/IEC 19770-2:2009 SWID tag
- etc
|
Key Negotiation points include:
- Software purchasing organizations should get a yearly accounting of what they’ve purchased from a particular vendor.
- By including the specific item of the software unique identifier (one of the mandatory elements in a software identification tag), SAM reconciliation procedures can start to become more automated.
By requesting an annual report of all currently active licenses, the software purchaser is sharing the responsibility of ensuring license compliance. The software purchaser is still liable for an out of compliance licensing position, but this report from the vendor will help with reconciliation procedures.
Including these type of requirements in an organizations purchasing process will help your organization handle your SAM process in a much more effective and consistent manner!