Skip to content

The MEGABYTE Act becomes law

A bipartisan US bill made software licence management a statutory obligation for federal agencies, with automated discovery written into the text. The reasoning behind it applies well beyond government.

The MEGABYTE Act — formally the Making Electronic Government Accountable By Yielding Tangible Efficiencies Act of 2016 — was signed into law on 29 July 2016 as Public Law 114-210. It passed with support from both parties, which is not something you can say about much legislation, and it did so because the underlying problem was not ideological. The US federal government was spending very large sums on software without knowing what it owned.

The Act is short, and its ambition is narrow in a useful way. It does not attempt to reform procurement. It requires agencies to find out what they have, keep track of it, and report on it.

What the Act requires

The Act directs the Office of Management and Budget to issue a directive requiring each agency’s Chief Information Officer to develop a comprehensive software licensing policy. That policy must:

  • Establish a comprehensive inventory covering 80 per cent of software licence spending and enterprise licences in the agency, by identifying and collecting information about software licence agreements using automated discovery and inventory tools
  • Regularly track and maintain those licences
  • Analyse software usage and other data to make cost-effective decisions
  • Provide training relevant to software licence management
  • Establish goals and objectives for the agency’s software licence management programme
  • Consider the phases of the software licence management life cycle — requisition, reception, deployment and maintenance, retirement and disposal — when making decisions, and incorporate existing standards, processes and metrics

The clause worth dwelling on is the first one. The statute does not say “establish an inventory”. It says establish one using automated discovery and inventory tools, and it puts a coverage threshold on it. Whoever drafted that had seen enough spreadsheet-based licence registers to know how the exercise fails.

Why it was needed

The Act follows a Government Accountability Office review published in 2014. GAO examined 24 major federal agencies and found that 2 had comprehensive policies covering things like clear roles and central oversight authority for enterprise software licence agreements. Eighteen had policies that were not comprehensive. Four had no policy at all. GAO’s conclusion was blunt: inadequate management of software licences was costing the government money it did not need to spend.

The sums involved make that conclusion easy to believe. GAO recorded federal software spending at more than $9 billion a year across more than 50,000 separate transactions — a fragmented market in which the same publisher is frequently negotiated with dozens of times over by different parts of the same government. In the same report, GAO recorded one agency saving approximately $181 million in a single financial year by consolidating its enterprise licence agreements, and it did so with an oversight process the report describes as ad hoc. The saving was available to an agency that was not even managing the process well.

Source: US Government Accountability Office, GAO-14-413, Federal Software Licenses: Better Management Needed to Achieve Significant Savings Government-Wide (2014).

Pooling: the saving that needs the best data

The largest structural opportunity in an organisation of federal scale is pooling. Where one department holds a surplus of licences and another is about to buy the same product, the surplus should move rather than the budget. Done across an entire government, that removes an enormous amount of duplicated purchasing.

Pooling is also the hardest thing on the list to do safely, because it is the one where being wrong makes you non-compliant rather than merely inefficient. Whether a licence can move between departments depends on the agreement it was bought under, the entity it was bought by, and in some cases the hardware it is currently assigned to. Get it wrong and you have created an exposure while trying to save money.

That is a data problem before it is a policy problem. It needs a complete, current picture of what is deployed, matched against what was purchased, with the entitlement terms attached to the purchase records — not held in someone’s memory of the contract.

What that looks like in practice

Two things have to be true before pooling is safe.

The first is complete discovery. Not just Windows desktops: CerteroX ITAM inventories Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris with the same native agent, and reaches the machines nobody has told you about through network discovery across NetBIOS, SNMP and ICMP, plus agentless and standalone collection for locked-down and air-gapped systems. Anything you cannot see is an unknown quantity in the pool.

The second is entitlement that has been reconciled against deployment. CerteroX SAM holds licences, transactions, agreements, maintenance, suppliers and publishers alongside the inventory, with dedicated engines for Microsoft, Oracle, IBM, SAP, Adobe and Salesforce, and computes the Effective Licence Position continuously — purchased, used, available, required, variance and exposure. “Available” is the number pooling depends on, and it is only trustworthy if it has been calculated with downgrade rights, second-use entitlement and licensing exclusions applied.

Once both are in place, moving a surplus licence from one part of the organisation to another is an operational decision rather than a gamble.

The wider point

The MEGABYTE Act is US federal legislation and most readers are not bound by it. The reasoning behind it is not jurisdictional. A large organisation that cannot produce an accurate inventory of its software will overbuy, will fail to reclaim what it has already paid for, and will discover both facts at the worst possible moment — during an audit, when the publisher has the better data.

The Act’s answer was to require automated discovery, continuous tracking and usage analysis, in that order. It is the right order.

To see what a complete position looks like across all five asset classes at once, book a demo.

Related reading

Other posts covering the same ground.

  • Device-based licensing and access control

    Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.

    • ITAM
    • SAM
    • Governance
    4 min
  • Gartner Myth Buster – Part 1

    A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.

    • ITAM
    • SAM
    • Governance
    7 min
  • The role of good data in software audits

    An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.

    • ITAM
    • SAM
    • Governance
    8 min
From reading to evidence

Put the hardest claim here
to a technical person.

Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.

No gated download at the end of it.