Tucked away (as usual) outside the summary of updates is clause 4.1 - License Verification and to a lesser extent 10.2 - Client's Reporting Responsibilities (applicable to sub-capacity licensing), which compound compliance and reporting obligations - lets take a look.

Firstly, clause 4.1.(a) states the "Client will, for all Programs at all Sites and for all environments, create, retain, and each year provide to IBM upon request with 30 days' advance notice: i) a report of deployed Programs, in a format requested by IBM, using records, system tools output, and other system information; and ii) supporting documentation (collectively, Deployment Data)". Unlike version 10 of the PA Agreement (November 2017) which contained a much more lenient requirement that "Client agrees to create, retain, and provide to IBM and its auditors accurate written records, system tool outputs, and other system information" which would occur simply "on reasonable notice" rather than a regular, annual basis.

Adding to this, where running under sub-capacity licensing as before you are then required to "properly install, run, and maintain the most current version of the applicable license reporting tool within 90 days of Client's first deployment and produce a report. Unless IBM approves a different reporting tool, the Client agrees to the following tools.

• Sub-Capacity Products -Client will use the IBM License Metric Tool (ILMT) and to subscribe to the ILMT support notifications at http://www.ibm.com/support/mynotifications and promptly install any updates.
• Container Products – Client will use the IBM License Service tool and Client is responsible t to correctly configure according to the Eligible Container Product's documentation"​

Ok, no real change there and easy enough right? Well yes, you're still required to run and keep reports at minimum quarterly and retain for a two year rolling period - and remember to have an individual(s) who is assigned the "authority to manage and promptly resolve questions on reports or inconsistencies between report contents, license entitlement, and the applicable license reporting tool". Better check that's been added to the appropriate JD's along the way.  The new clause 10.2.(e), is somewhat favorable to the client in that it provides an avenue to address (with IBMs consent) deviations from the sub-capacity model, which in most cases would probably result from  operating systems becoming non-eligible over time.

What we (and others) have always attested to though is being solely reliant on one reporting tool, like ILMT, can prove very problematic in that where improperly configured you could easily be over-reporting and paying much more than you should - having an independent product (like ComplianceWare) is often the best - or only - way to reconcile outputs and ensure accuracy.

Well, basically now:

• from 1 February 2023 for new IPAA Client enrollments and new IPAEA transactions; and
• from 1 May 2023 for current IPAA Clients notified on 1 February 2023 of the new terms which will be effective for them on 1 May 2023 per the terms of IPAA. 

So nothing new or revolutionary on that front, however the ease of use and in particular the layout, share, download, and notification options provide all of the basic /requisite features you'll need - all in all, a welcome step forward from the IBM licensing team!

Many projects require the expertise of vendors to install, configure and productionize their software and systems, however as the client and end-consumer you need to be aware of what exactly is making its way into your environments.

All too often following discovery we'll find unaccounted for vendor software, which typically after an onerous investigation is found to be remnants from the vendor-led project, anything from desktop clients to entire VM's, each of which can have dire compliance implications and cost.

But "hold-on - we didn't install it - the vendor did" is the common response, however a quick pointer to the relevant contracts will soon expose that this does not offer any defense - the customer is always responsible for compliance, even if it is the very vendors software in question.

At a more concerning level is when a vendor installs another vendors software - while this is not uncommon with the extent of partnerships and interoperability in the modern industry, it still needs to be clearly and formally covered, ideally contractually or by reference to the vendors right to distribute and use any IP they don't own. These artefacts need to be registered and retained in the event of an audit that questions your usage rights - in the worst case scenario  if the vendor has breached another parties IP rights you too could end up subject to an infringement claim, and that's no place you want to be.

And never rely on the vendor's personal emails or assurances that 'all is well' - none of that will hold-up under audit (even if they are still there). When it comes to IP all bases need to be formally covered, and if that's proving to be a problem, well you might want to be even more wary.

A Distribution License Agreement is required for:

• ​Corporations and organisations that want to distribute Acrobat Reader or the Acrobat Reader mobile app on a company intranet site or local network.
• Commercial vendors that want to bundle Acrobat Reader or the Acrobat Reader mobile app on physical media such as a CD or DVD, on OEM hardware such as computers and mobile devices or with OEM hardware such as scanners.

Individuals interested in the software for personal use can download it free without applying for a Distribution License.
​
Note: You do not need to apply for a Reader Distribution License if you prefer to direct users from your website to Adobe.com to download Reader.

In the absence of strict procurement practices and robust record keeping its all to common to see organisations struggling to retrieve their records of purchase backing-up their claim to entitlements. In fact how often do we hear "yeah we've got 20 licenses for that - they're listed on Dave's spreadsheet".

Now lets be clear - the fact that it's on Dave's, or Susan's or anyone's spreadsheet does not constitute evidential fact. For that, you'll need the Proof of Entitlement if issued by the vendor, or the (signed) Contract containing the license grant, or the Order issued under it for the products in question. At a minimum if those are lost in the tracks of time (no doubt residing only in someone's email who has long departed the employ of the company), you'll need the latest invoice that shows the products and quantities that were covered by the last payment (ie. either actual purchase or renewal).

Again, its all too common that it's not until an audit that organisations are forced to scramble through the purchasing, legal, IT et al records looking for some artefact to substantiate the otherwise baseless right of use claim for the vast overage of licenses that have been deployed! This trek down memory lane can be the most time consuming - and often fruitless - use of specialized resources, the cost of which is not generally recognized by management and similarly overlooked in the justification of a dedicated SAM function.

So what's the alternative? Quite simply a process that ensures those essential records are properly recorded in an organized and readily accessible system, and are kept current through routine and ongoing ownership - once established this is not as much of an overhead as it might seem, and having all of that data at hand when challenged by a vendor can go a long way in underlining your disciplined approach and credibility in such a way that you'll be last on the next audit round list, if in fact on their radar at all.

Now this will no doubt rally those skeptics with their "wait - I just call my reseller and say give me a list of what we own" approach, and while this might offer some solace it doesn't necessarily constitute proof in the same way that last document of fact - the invoice - does. How's that? Well for one example think of step-up licenses that will be printed there for all to see, but what about the original license it is based on (and worse, what if that original license is actually still in use!), or those 'from-SA' uplifts that require unravelling potentially years of purchase history to properly determine entitlement. All best avoided by having a routine practice supported by a specialized system in the first place ... 

In part one of this series we covered the importance of a full data collection across your data sources and contract and licensing information, now we look at how to bring that together into a compliance position.

The first realisation is - wow! - that's a lot of data we have out there! So just as we needed tooling to perform the data gathering exercise we are going to need analytics to decipher not only what's important but how to interpret it all, for which there are two aspects:

1. Scale Reporting; and
   
2. Direct Examination and Querying.

Now what exactly do we mean by 'Scale Reporting'? Basically this means a reporting facility that enables you to stipulate variable parameters from product to vendor to company, with the output organised by device in a concise and easily readable form - for example ComplianceWare's powerful python & pandas based analytics engine that slices and organises the data into output as a familiar Excel workbook.

A snapshot of the output as below:

The analytics should also consider base licensing metrics such as server core and PVU minimums, apply relevant bundling rules  to avoid double counting, and recognise non-chargeable installations such as clients and free-edition software.

So we now have our first view of what's deployed where - and that's a good start, but it doesn't mean the jobs done. You'll want to perform some spot / sanity checks across the report, and that's where the 'Direct Examination and Querying' comes in. Here, your tool should allow you to easily interrogate your data collection (which can span many millions of rows) for further review and confirmation, and that's accomplished via smart features that enable you to slice, limit and target the fields and items of interest. Again, with ComplianceWare as an example you can easily navigate through the data by vendor, product, data source, and perform smart searches with inclusion and exclusion parameters to dynamically find exactly what you are after.

Now it gets interesting - does what's reported as deployed match what we're actually entitled to? While some products can be automatically tallied (eg. products with simple install or device metrics) others will require more effort such as resource based metrics like cores or logical licenses such as users, and those in more complex environments such as virtual environments where physical v virtual considerations must be taken into account.

Here there are no short-cuts - it will require a knowledgeable individual (preferably with prior experience in the environment) to work through each product in a methodical and calculated manner to (a) derive the optimal licensing construct and then (b) reconcile against the recorded (and evidenced) level of licensing. As this progresses it is imperative to capture your findings and ensure they are lodged as an artefact for audit readiness and as a baseline for future reporting cycles (again with ComplianceWare this can be stored as 'Verification' material alongside the updating of actual usage figures).

And just how often should the whole exercise be performed? We'd recommend that you cover your major vendors at least annually, and institute a program of work that targets a select number of products or vendors quarterly. The good news is that once you've completed one cycle others become easier as you'll have a baseline to compare or commence from.

So to summarise:

• Make sure your tooling includes a specific and effective software analytics engine;
• Ensure results (and data) can be reported, interrogated, and manipulated as required;
• Look for built-in smarts that alleviate some of the licensing complexity (eg. core / PVU counts, bundling);
• Invest in at least one knowledgeable and experienced individual assigned fully to your SAM function;
• Ardently track results and store the output of each exercise;
• and as with Part One - repeat as necessary!

If it seems that your vendors are unwilling (they'll say unable) to accept a termination for convenience clause these days, you're not alone. Often this will be justified by citing their companies accounting rules and practices aligned to the 2014 revenue recognition changes post Enron where they'll refer as below:

What they don't refer to is the fact that where termination charges are provided full contract revenue can be recognised:

Of course the "substantive" qualification is the issue - just how substantive should it be?

Well there are no firm guidelines in that respect, other than simply compensating a supplier for services or deliverables provided up to the effective date of (early) termination will not be regarded as substantive. Guidelines only advise that "judgment has to be applied with consideration given to quantitative and qualitative factors". Government contracts typically require a termination for convenience clause and will  state (in part) something similar to the below:

• any reasonable costs incurred by the Contractor that are directly attributable to the termination;

thus (1) putting the onus of quantifying the charges on the supplier, and (2) vanquishing their argument for full revenue recognition.

Having negotiated the termination for convenience clause we're now comfortable that all is good right? Well no, there are further issues to contend with. If (and thats a big 'if') the matter gets to court there would likely be consideration as to whether the contract was 'illusionary' based on the very right to terminate at will, or that the termination was not enacted in 'good faith', or even as far as not following the termination right explicitly which opens the door to damages!

So what other options are there? Well that of course depends on what exactly is being contracted, but consider the following:

Key to all of the above is explicit language that clearly defines the criteria by which the clauses can be invoked - when things break down to termination your vendor will not be overly receptive to subjective positions, ambiguities, or plain old opposing points of view.

And while the lawyers are endlessly debating the virtues of limitations of liability and insurances and everything else basically immaterial just ask yourself when you actually last went to court, and then ask what typically goes wrong with your contracts - invariably its performance based and for that, you just need an appropriate provision for ...