The ITAM Review

News, reviews and resources for worldwide ITAM, SAM and Licensing professionals.

Software Audit Code of Conduct [DRAFT]

Updated 25th April 2014 – The first version of the Code of Conduct is now live here:
http://www.clearlicensing.org/audit-code-conduct/


This code of conduct from the Campaign for Clear Licensing is a first draft. Please leave your comments or contact me to discuss any suggested edits or feedback. Thanks in advance for your help. ~ Martin

Thanks to Rory Canavan, Glenn Thompson, Martin Chalkley, David Foxen and Kylie Fowler for helping put together this first draft.


CCLPreface – Current Market Observations

  • Technology exists within the current market to restrict the use of software that is not licensed correctly. Many software publishers choose not to implement such controls – preferring an approach to software control that enables flexibility and openness to customers developing solutions with their technology
  • Historically, software management controls have been two steps behind license program changes. Software is typically poorly labelled and customers are provided insufficient tools or guidance to accurately assess their consumption or clarity regarding changes to licensing programs.
  • Historically end user customers have been either poor at building controls for deploying and using software in their estates or found difficulty in managing their software audit functions.
  • End user customers accept terms to contracts that they do not clearly understand either through choice or ignorance
  • Software publishers have the ability to use the lack of clarity over software, licensing and audits to their advantage during sales processes or contract negotiations, resulting in general market dissatisfaction and distrust.

Introduction

Software publishers audit their customers to examine if software is being used within agreed terms. This code of conduct defines a set of acceptable practices for behaviour during such audits.

This code of conduct covers types of audit, defining scope, the introduction of third parties, agreeing objectives and discussing results and outcomes.

Guiding principles:

  1. Software publishers have the right to protect their intellectual property
  2. Software publishers have the right to exercise clauses in their agreements and contracts
  3. End user customers have an obligation to manage licenced software within the terms of the agreements
  4. End user customers have the right to deny audit requests that are not the result of contractual obligations or evidence based breaches of intellectual property
  5. End user customers have the right to professionalism, complete transparency, clarity and openness throughout the audit process

 In a nutshell…

  • For customers: If you can’t manage it, don’t use it
  • For software publishers: If you can’t demonstrate how to manage it with everyday tools and techniques, don’t sell it

Terminology and Types of Audit

Any audit activity should state the type of audit as outlined below; is it voluntary, contractual or legal?

The table below summarizes the most common types of audit:

Type of Audit

When Initiated

Commonly known in the market as…

Obligation to participate

Voluntary Audit Adhoc or speculative,  during sales process Audit, Review, SAM Review, Assessment, Self-Audit, Friendly Audit Voluntary
Contractual Audit Contract event or during sales process Audit / True-up Contractual
Legal Audit Breach of intellectual property Audit Legal

Notes:

  1. Audits and reviews may be incorrectly associated with, or labelled as, formal audits
  2. Pre-sales led audits and voluntary reviews can be a positive experience to benchmark an environment.  They must not be used inappropriately to benefit the sales or new business process, e.g. threaten legal recourse.

Audit Engagement

All audit communications should be routed through normal account management channels with appropriate escalation as appropriate.

Initial audit communications should cite:

  1. The main point of contact
  2. Nature/type of audit as mentioned in the table above
  3. Grounds for audit or supporting evidence
  4. Contract, Agreement or other unique identifier
  5. Audit scope in terms of products, geographies, environments, device types etc.
  6. Date for audit to be conducted, results to be collated and published
  7. Resolution process to be followed in the event of irreconcilable differences

Agreed Measurement Criteria

The software publisher shall publish clear guidance on what constitutes entitlement, installation and usage:

  • The software publisher will provide proof of install for all titles in scope.
  • The software vendor will provide proof of entitlement for all titles in scope.
  • This software vendor will include in its licencing terms and condition examples of evidence they would accept as “rights to use” the software in audit scope.

Data and Working with Third Parties

Third parties (companies involved in the audit but not the customer or software publisher) should declare all commercial interests (either customer side or vendor side) before audit work commences.

Commercial interests may include:

  • Profiting (directly or indirectly) from the outcome
  • Compensation for audit work
  • Relationship or commercial interests outside the audit work
  • How and when data relevant to the audit is shared

Timing

Both parties will agree on a date by when the audit will commence and complete.

If any install inspections are to be conducted by the software vendors or a nominated third party, then the processes and timing to complete such information capture are to be agreed by all parties.

  • Voluntary Audit: At client discretion
  • Contractual Audit:  Minimum 60 day notice prior to commencement unless otherwise agreed
  • Legal Audit: According to local jurisdiction

Onsite Inspections and Operational Details

The third party conducting the audit on behalf of the software vendors is to liaise with the client to confirm the operational aspects of the audit.  This might include (but is not exclusive to):

  • Access to hardware systems, duration of time permitted on site(s)
  • Arrangement of a client chaperone to escort the auditors about the client’s premises
  • Access to auditing software systems.

All information captured or created as a result of the audit is to be classed as commercial-in-confidence and not relayed beyond the software vendor, the third party auditor and the client, without the express permission of all parties.

If a third party does conduct any on-site data capture on behalf of a software vendor, then such data capture is copied to the company being audited.  100% Disclosure between Software Vendor and Client is essential, so that both parties understand what data is being used to derive any potential fees owed.

Audit Results

Dispute resolution

The software vendor is to confirm the calculation of any licence fees owed, including how final figures were arrived at.  A summary figure here is not fit for purpose, as it fails to account for a comparison to existing market prices, or pre-arranged contract prices that might be in force but forgotten about.

Note: Detailed transparency regarding shortfalls can also help organizations with root cause analysis – preventing such short falls in the future, benefiting all parties.

 Audit results / closure / recommendations

Both parties reserve the right to dispute the figures arrived at; and take recourse via mediation with the CCL, arbitration with an agreed arbitrator to be agreed and appointed by both sides, and legal proceedings.  It is important that an escalation route exists in the event of any dispute arising over the any fees felt due.

The Auditor / Publisher or Third party should explain any discrepancies, the likely root causes of any discrepancies and what steps the organization might take and best practices the organization reference to prevent the same issue happening again in the future. Audit results and recommendations should be delivered in plain english with minimal technical or licensing jargon so that the key messages can be understood and acted upon across the organization.


The Campaign for Clear Licensing will consider all complaints against organizations that have not followed the code with a view to stamping out unprofessional behaviour and raising standards. Contact us in confidence to discuss breaches of this code.


This code of conduct from the Campaign for Clear Licensing is a first draft. Please leave your comments or contact me to discuss any suggested edits or feedback. Thanks in advance for your help. ~ Martin

Thanks to Rory Canavan, Glenn Thompson, Martin Chalkley, David Foxen and Kylie Fowler for helping put together this first draft.


About Martin Thompson

Martin is owner and founder of The ITAM Review, an online resource for worldwide ITAM professionals. The ITAM Review is best known for its weekly newsletter of all the latest industry updates, LISA training platform, Excellence Awards and conferences in UK, USA and Australia.

Martin is also the founder of ITAM Forum, a not-for-profit trade body for the ITAM industry created to raise the profile of the profession and bring an organisational certification to market. On a voluntary basis Martin is a contributor to ISO WG21 which develops the ITAM International Standard ISO/IEC 19770.

He is also the author of the book "Practical ITAM - The essential guide for IT Asset Managers", a book that describes how to get started and make a difference in the field of IT Asset Management. In addition, Martin developed the PITAM training course and certification.

Prior to founding the ITAM Review in 2008 Martin worked for Centennial Software (Ivanti), Silicon Graphics, CA Technologies and Computer 2000 (Tech Data).

When not working, Martin likes to Ski, Hike, Motorbike and spend time with his young family.

Connect with Martin on LinkedIn.

31 Comments

  1. Jacobo Senior says:

    Great draft. Serves as a wonderful starting point of what each party should expect from the other during an audit.

  2. Robbie Richmond says:

    As this is the Campaign for Clear Licensing, I feel the initial draft focuses too much on the audit process, as opposed to clearer license agreements etc. The Code of Conduct should be aimed at software vendors who utilise unclear or misleading terms or clauses in their agreements

  3. Anonymous SAM bloke says:

    Very good Martin. I shall start using today as I can see some relevant points set out that can be used in my discussions with vendors who are unknowingly vague in their request for an audit.

  4. Rory Canavan says:

    Fair comment Robbie – It’s on the CCL agenda to produce “Bridging documents” that take license legalise and spell what is meant in plain(er) English.

  5. farrah says:

    I think the agenda seems to have slipped. Unless the licensing terms are agreed and
    a clarity is spread across vendorsed and that is acheived , We can then move to the next which is Audit….

  6. jay says:

    2 comments. First, the 5th guiding principle should echo that the customers also have the same obligations around professionalism, openness, etc. that is expected of vendors and third party auditors. Second, in the first bullet around measurement criteria, it should include usage, not just install, as there are many usage-based measurement criteria out there.

  7. Duncan Jones says:

    I agree with Jay and would go further – the focus should be on usage exclusively. Clear Licensing should prohibit charging based on installation only (e.g. for accidentally deployed software that hasn’t been used)

  8. Duncan Jones says:

    The “Agreed measurement criteria” aren’t clear to me. My advice to clients is to insist that the publisher provides a) a complete version of the current contract between the customer and them, showing clearly which terms from the original contract have been amended by subsequent agreements, and c) a complete list of the customer’s entitlements, according to its (the publisher’s) records.

    This is to prevent them using the ‘secret amendment’ ploy where they produce some order from signed by a staffer as evidence that the customer accepted a whole new set of Ts & Cs, even in some cases a complete change of license metric.

  9. Duncan Jones says:

    Under Audit Results I would suggest an “accidental over-usage” provision. Provided that the client has tried hard to manage usage within its license agreement, then it should be able to rectify inadvertent mistakes that the audit discovers without buying more licenses, if it chooses to do so. For instance, the customer might be using a reputable license discovery tool but that tool has a flaw in its logic, or maybe the licensing rules are unclear and the customer didn’t understand what the publisher intended, or maybe an end user or IT person has used something without realizing that there would be a licensing implication.

  10. Ryan Hardcastle says:

    I like the idea of this but I can’t see both parties signing up to it and sticking with it. I can imagine a situation where software publishers / vendors are in good faith adhering to this CoC (because if they didn’t, word would get round) but the end-customer elects to be fast and loose with their obligations because they suspect they might have a shortfall, this is much harder to prove and NDAs would prevent anyone else from finding out.

    Put it another way – if you can’t adhere to the terms of a licence, what hope is there of you adhering to the terms of a code of conduct? All contracts rely on a degree of trust in the other party to stick to what they agreed. If that trust is broken in any way it can only be damaging. This works both ways.

    I’m picking on the end-customer deliberately here as it’s usual that the publishers are seen as the ‘bad guys’ in these audits. They are just exercising their rights to collect what is owed to them, as would any other business. Yes they can be a bit aggressive at times and I don’t always agree with the methods and reasoning but we have to keep things in perspective.

    The whole document is summed up nicely in the ‘In a nutshell’ paragraph – If you can’t (or won’t) manage the software (or are not willing to pay for it), don’t use it. ‘Use’ in this instance means ‘install, deploy, access, run etc.’ You can’t get much fairer than that IMO.

    The second bullet point deals with the other comments about the importance of tackling the licensing T&Cs, but IMO until that happens it would be incorrect to suggest that the audit CoC are off-topic. Audits will continue to happen and contracts pre-CCL will still be enforceable under their existing T&Cs. These CoC apply regardless of the contract.

  11. James says:

    Great draft Martin! Some minor points:
    In the Preface (4th bullet) – most users “click through” the agreement because it’s not simple enough to read. If you look at any software manufacturer EULA, it’s like a book and too much legalese. Who has the time to read through it and actually understand it.
    All the audit terminology and audit conduct is a nice to have but because the objective is clear licensing, more focus is needed on the vendors to be more “clear” and transparent in how they “count” software licenses. The audit stuff is still very good to have.
    I believe you summed up the objective in your two paragraphs of “In A Nutshell”. If we can expound on that that will be more concise and clear

  12. Charly Haversat says:

    One comment and one question. Comment:
    the audit scope should include clarification as to whether it’s a
    retroactive audit (i.e. pay for past installs) or a true up going forward. It’s been my experience that can save a lot
    of teeth gnashing. Question: where do VAR/LARs fit into this?
    Do we need to consider that there may be additional participants in the
    audit: the software vendor, the LAR/VAR, the purchaser?

  13. Keith Dobbs says:

    Great initiative and first draft. I’ve mailed comments to Martin but a key one is
    “Software
    Publishers have an obligation to make their contracts complete, understandable
    and common pitfalls identified to the client. “
    In the Oracle world, contractual licence definitions and rules are basic and incomplete. Too much is left to “Educational use only” documents and hearsay with examples concentrating on the obvious and simple, not the real world complex cases.

  14. Delano Michael says:

    Good draft. This good starting point of what each party should expect from the other during an audit.

  15. itsmreview says:

    Agenda is as agreed and as driven by members. Audit activity is a key concern and directly linked to license programs.

  16. itsmreview says:

    Good points thanks Jay

  17. itsmreview says:

    Our goal is to make licensing clearer, not force the market to standardize or go in a certain direction.

  18. itsmreview says:

    Great points thanks Duncan

  19. itsmreview says:

    Agreed. Good feedback thank you.

  20. itsmreview says:

    Great points Ryan, thank you. I absolutely agree that this shouldn’t be used as a shield to cover up inadequate internal controls for managing software. The goal is clearer licensing programs and better trading relations – not defending poor practice. Both parties have responsibility.

  21. itsmreview says:

    Thanks James. Yes I agree clear measurement criteria are key.

  22. itsmreview says:

    Thanks Charly good feedback on retrospective audits. We’ve tried to cover VAR/LARs under the working with third parties section. Let me know if this could be expanded or clearer.

  23. itsmreview says:

    Received with thanks via Email – thanks Keith.

  24. Duncan Jones says:

    You don’t have to force but you can advocate and persuade. My point is that “Install” implies an out-dated focus on the pre-cloud pre-mobility software world. Different publishers use different measures of “Usage” that they believe match the way their software delivers value to customers – e.g. active login IDs, page visits, sales transactions, actual peak sub-capacity. Some may continue to measure installation, but they will become a minority – so why have that as the main term mentioned over and over in the document?

  25. itsmreview says:

    Via Email:

    “Many thanks for sharing the code of conduct. As a relative newcomer to ITAM, it has helped to clarify some of the facets of an audit and will allow me to put the right controls in place to manage the vendors. It’d be great to see the vendors pick this (or derivative of this) code of conduct up. In particular, I appreciate the 3rd party component to understand interests prior to the audit taking place. This definitely has an impact.

    An element which can be tricky during audits is the cost to the business being audited. The costs can be considerable especially if the vendor (or more likely the 3rd party) don’t run the audit efficiently. Is there an expectation that the audit will outline the expected effort for the business and clearly list tasks to avoid audit cost sprawl?”

  26. itsmreview says:

    Via Email:

    “I think you missed something that applies to all scenarios,,

    -SW Audits of all types should not impact normal business operations and should be conducted during normal business hours”

  27. itsmreview says:

    Via Email:

    “I think the statement “For software publishers: If you can’t demonstrate how to manage it with everyday tools and techniques, don’t sell it” is particularly pertinent. An example of this is the fact that Oracle provide no licence training at all to customers which makes Oracle licence management particularly challenging! The fact that you have to run scripts on Oracle databases to get a full licence position and that installers of software can unwittingly install separately licensed elements if they’re not unselected when installing increases the compliance risks to end users.”

  28. Paula says:

    Great concise writeup of a Software Audit CoC! Clear and fair both ways, as it should be. Now if only the licensing terms could be so clear!

    Regarding Duncan’s comment about used vs. installed, manufacturers auditing perpetual-licensed desktop software will focus on installed copies and can’t be expected to care whether the software is really used.

    On the end-user support side, it’s clearly my responsibility to police the installation of software on my systems — whether installation options allows the selection of unlicensed components or not. However, preferred manufacturers would make it easy for the installer to know what’s in a license and what isn’t!

  29. Kylie Fowler says:

    In my experience of audits, the majority of discovery data used to determine installs / usage has been supplied by the end user. I feel there should be something in the code of conduct that specifies the end user organisation should provide a full and unadulterated data set in this situation.

    End users should also be given the opportunity to validate the results and produce more evidence of compliance – in complex estates you often only see a ‘hole’ in the entitlement or realise that the vendor has interpreted the deployment data incorrectly (yes, that has happened!!) when you get the audit results back from the vendor – you need to have additional time to track down the extra entitlement or figure out why the deployment data looks so different from what you expected.

  30. The first version of the Software Code of Conduct is now live on the Campaign for Clear Licensing website:

    http://www.clearlicensing.org/audit-code-conduct/

  31. I really like the draft. This good starting point of what each party should expect from the other during a legal or vendor audit.

Leave a Comment