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.