Warning to readers: this blog post, while inspired by a true story of a license agreement gone awry, is not really about license agreements.  Rather, it’s a reflection on what an impressive living those attorneys in the business of writing legal contracts must make. While I don’t necessarily think there’s a global conspiracy, it’s no joke when they say that lawyers craft language in such a way as to guarantee their own job security.  It takes a lawyer not only to draw up a license agreement in the first place, but another lawyer to interpret the agreement for the signing entity, and yet more lawyers to testify for, litigate against or defend parties who obviously didn’t hire the best lawyers to perform the previous two duties. 

If I’d been aware of this brilliant ponzi-like scheme back in my early twenties, heck, I might have applied to law school to learn the fine art of “legalese” (lawyer-invented jargon that leads the average person to question their own intelligence or assume the caffeine hasn’t yet kicked in from their morning coffee).  I mean, did someone really get paid to come up with this gem?:

(more…)

An article caught my eye this morning in Manufacturing Business Daily summarizing the results of a recent Ernst & Young survey that focused on software asset management philosophies and practices among software vendors and their customers.  

Before discussing the results, I should point out that I’m pretty skeptical about studies conducted and published by firms with a commercial interest in the topic being explored.  Because Ernst & Young dedicates part of its business to IT governance, internal auditing, and compliance services for large enterprises, it’s virtually impossible for the firm to be objective in its research methodology or interpretation of results–in fact, they offered no information about their approach to the survey.  (For example, is there inherent bias among those selected to participate?  What were the roles with respect to compliance of those individuals or teams that actually completed the survey?  Why did they recruit end-user organizations that averaged over 10,000 desktops [organizations of this size comprise only 0.1 percent of all US companies over 100 employees]?  Is it possible to draw conclusions relevant to the marketplace with so few participants?  The list goes on and on.)

Nevertheless, the results are interesting and at least on the surface validate what we’ve long suspected to be the true motives behind vendor audits; software publishers are far more interested in revenue generation than they are in protecting their intellectual property or helping customers be successful in managing their software estates.  Only four of the eight “major” software publishers surveyed stated that protection of intellectual property rights is an objective of their compliance programs, flying directly in the face of the very legal platform software vendors and the BSA claim as the basis of their actions.  It’s also ironic that only 38% of vendors suggested that their compliance programs, which are generally advertised as “SAM” programs, have customer education and/or process improvement as a stated goal. 

(more…)

The following bylined article can also be found in the April issue of IAITAM’s ITAK Magazine and the April edition of FAST IiS Kaleidoscope.

Since the dawn of the desktop era, IT departments have struggled to keep track of software installed across their corporate networks.  Accurate software inventories are crucial to ensuring installed applications are properly licensed, understanding whether or not they’re being used, and budgeting for future software purchases.  Unfortunately, no standard methodology exists across applications and manufacturers for correlating installed program executables with actual application titles.  This leaves asset managers and the software discovery tools they utilize with any number of half-complete approaches to application recognition.

Driven by licensing challenges stemming from inaccurate and incomplete software identification, the ISO/IEC 19770-2 software tagging standard has been developed, providing publishers with guidelines for “tagging” their applications in a standard way that makes identification straightforward, automated, and virtually foolproof for discovery tools.  Yet despite the technical ease with which software tags can be implemented, publishers have been painfully slow to adopt the standard, and end users have not pressed vendors hard enough to spur them to action. 

(more…)

I came across this Computerworld article as I did my weekly scour of the news media, and wow, did it ever bring new meaning to “going rogue.”  Companies understandably worry about employees “blowing the whistle” on unlicensed software–a practice promoted (and rewarded) by the BSA that’s become a primary tool for uncovering and combating corporate software piracy.  But this column describes a much more seditious plot by an IT systems administrator, who, as far as I’m concerned, wins the prize for “Most Creative Way to Trigger a Software Audit.” 

In short, a 7-year employee of a $250 million retailer located in Pennsylvania (who shall remain nameless), created and operated a bogus storefront to sell more than half a million dollars worth of Microsoft, Adobe and SAP software to his oblivious employer.  The scam began to unravel when the company received a call from the BSA, informing them of licensing disparities that suggested pirated software was in use.  As it turns out, Microsoft had traced the sale of illegal software back to the above-mentioned sys admin, which apparently set off the investigation in the first place.  To make matters worse, this enterprising chap turned out to be the only person at the entire company who held the administrative passwords to critical systems such as the network router, firewall and switches, the corporate VPN, the email server, Windows AD and desktops, and more.  Because of the obvious retaliatory damage the sys admin could bring upon the company if not confronted carefully, the firm hired a security consultant who designed an elaborate sting operation that would have made even Dragnet’s Sergeant Joe Friday proud.  

(more…)

In the IT world, we tend to view end users as an occupational hazard—a perilous yet inescapable part of our jobs.  After all, it seems employees will install just about any application they can get their hands on without regard for the potential licensing implications, compatibility issues, security holes, or bandwidth consumption.  But who can blame them?  They’re trying to do their jobs just like we all are, but without the benefit (or curse) of understanding the potential implications of their actions.

What we rarely acknowledge is that the onus is on IT leaders to ensure workers have the information they need—and are held accountable—to make good decisions. It all begins with a clearly articulated and effectively communicated software usage policy that educates end users about the importance of complying with a set of basic standards. Such a policy shouldn’t be long and infused with technical mumbo jumbo.  In fact, the shorter and more straightforward the guidelines, the greater likelihood it will be read, understood, and, most importantly, adhered to.  Not only can a properly developed software usage policy serve to curb risky behavior, but it will also generate goodwill among software publishers when and if they decide to audit you.  If a vendor sees your organization making a conscientious effort to prevent the use of unlicensed software, they’re more likely to treat you as a partner rather than a criminal throughout the software audit process.

The nature of your software usage policy will (and should) depend on your organization’s size, geographic dispersion, and diversity of your software estate, as well as the sophistication of your end users and their technology needs.  If you run the IT department of a small community college, for example, you may wish to prohibit anyone but the IT staff from purchasing or installing software on school-maintained systems. On the other hand, if you work for a technology company with software developers that rely on a variety of commercial and open source solutions to do their jobs, you may need to build more latitude into your usage policy. 

(more…)