How can software executives, investors, salespeople, and customers test and improve their assumptions and decisions?
An additional competitive resource is the artifacts created by other companies in their litigations.
They include product development details, pricing, sales contracts, and “confidential” e-mails. Lawsuit pleadings are a unique corporate and career resource. They deliver robust case studies of “train-wreck” software business situations. Studying lawsuits can save serious screw-ups in several segments of your business.
One example is a big-bucks battle that began in 2009 and ended only days ago. It offers actionable lessons for strategy, product design, product development, launches, marketing, licensing, compliance, and exit events.
Over $1,000,000,000 (endnote 1) depended on a recent lawsuit in Austin, Texas between NEON Enterprise Software and IBM. What are its facts and lessons?
NEON built and in mid-2009 began pitching “zPrime” software. It enabled IBM z series mainframe users to offload processing workloads to cheaper processors – contrary to IBM’s business model and customer contracts. Both software and hardware IBM sales were threatened. IBM questioned both (a) NEON’s selling as inducing customer violations of IBM software licenses and (b) zPrime’s intellectual property (IP) propriety.
Slowed by IBM’s queries and prospects’ caution, NEON sued Big Blue, asserting antitrust and other claims. And it sought a ruling that IBM’s in-field licenses failed to preclude prospects from picking up NEON’s new program.
IBM counter-sued. It claimed that NEON breached both (a) the no-reverse-engineering commitments of NEON’s prior authorized-ISV IBM contracts and (b) the Digital Millennium Copyright Act’s anti-circumvention terms (endnote 2).
What business wisdom for all software segments can be gleaned from this mainframe competitors’ wrangling?
Lesson #1: latency is for losers when looking for license “right and tightness”
If Big Blue can bungle a bit, then can’t we all? If IBM can have bugs in coding its customer contracts, can’t your colleagues too?
It wasn’t just a feisty competitor and restless customers who questioned the quality of Big Blue’s contracts. A federal judge explicitly held that IBM was partly wrong about its understanding of its own software licenses. The parameters of IBM products “authorized use,” supposedly specified in customer contracts, turned out not to be a slam dunk (endnote 3):
“… the Court finds that processors may run only the workloads that are expressly authorized. But because there are no express authorizations in the IBM customer contracts, the contracts are incomplete …. As a consequence, extrinsic evidence must be examined …. This is a fact issue that the Court leaves for the jury. …”
After the start-up’s challenge, IBM apparently revised some contracts, clarifying what IBM asserted was understood all along.
The judge, who denied IBM any easy or early victory, observed a valuable management lesson: “A party who fails to properly protect itself in a contract must suffer the consequences of poor drafting” (endnote 4).
Business Wisdom: Has your company both recently reassessed and carefully tightened both its software licensing prose and its ongoing contract administration practices?
Software company mergers, newer technologies (e.g., virtualization and cloud offerings), and other causes have triggered important gaps and tricky ambiguities in many contracts.
Stale or uncertain licenses have triggered dozens of unpublicized recent litigations. Those suits strive to interpret old, now-uncertain sales contracts. Confusion about prior-deal obligations, audits, and compliance tangles relationships, upgrade plans, and new-buy budgeting.
A common ambiguity is what portion of post-signing contract ordering and operations can be moved from paper to Web? And just how can older enterprise contracts be amended to effectively address new products, platforms, and licensing models and pricing? What refinements were implemented in your company after the September 2010 ruling on the U.S. copyright “first sale” doctrine?
As in personal investing, past practices aren’t reliable predictors of future excellence or even survival. Assess with “fresh eyes.” Don’t just guess, or ask company insiders or “warhorse” veterans who likely are included to assume, sometimes incorrectly, that all’s well and optimal.
Best Practice. “Debug” your selling. Don’t just “drive on old tires.” Don’t assume. Proactively and periodically re-analyze whether there are gaps, ambiguities, and/or conflicts in your selling documents and/or processes.
Lesson #2: late compliance and risk mitigation looks foolish
“Oh yeah, can you prove it?” That’s more than a schoolyard taunt. It can be become a painful price of staying in business.
In this billion-dollar Texas tangle, IBM argued that NEON achieved key product features by cheating. Big Blue said the start-up broke its contracts (endnote 5) with IBM by reverse engineering portions of Big Blue’s code.
Initially, a NEON senior coder claimed he never created design documentation. Instead, he kept his innovations “in his noggin’.” And a corporate “e-mail retention policy” implemented soon before product launch was re-characterized by Big Blue as a belated “evidence destruction” process.
IBM dug deeper. Further, expensive fact-finding by defendant-and-counter-plaintiff IBM forced NEON to admit to reverse engineering, after initially asserting that it had only deployed a standard debugger tool.
Code creation credibility counts. IBM’s litigator raised the “in-noggin’ ” story with not-so-subtle skepticism when arguing IBM’s evidence destruction motion in the May 25 hearing, which this author attended. When NEON’s litigator stood to argue its defense, the judge commented, “You’ve got your work cut out for you.”
Also, NEON’s effort to buffer from external eyes its internal IP analysis within the company and its legal counsel looked leaky. Smart software shops strive to deploy the “attorney-client privilege” to achieve non-disclosure of self-evaluation of awkward IP issues. Big Blue sought to see “who knew what, and when did they know it.”
Business Wisdom: What if your confident “wildcatting” developer “finds oil” in your backyard? What if your outsourced coding subcontractor cuts costs or meet deadlines by shortcuts over third-party legal “territory?” Can you produce a certain, complete “land title,” years later, entitling you to drill, sell, and get rich? To successfully monetize your software “gusher,” create and keep timely, credible records specifying the particular “digital real estate” you’ve custom-carved.
Future investors and business partners will require “due diligence” investigation. Your “exit event” may depend on your ability to confirm that your new product design, development, testing, and documentation processes are legitimate (endnote 6).
Expect that the same competitor whom you dilute or destroy now, you may see in serious litigation later. Like NEON, you may face not just features, pricing, integration, and support challenges. Instead, court-required production of product development records, sworn depositions, interrogatories, and other “discovery” costs, tasks, and challenges may be required. And if in-house counsel hold blended business/legal roles, or outside the U.S., the candid self-critique of the “attorney-client privilege” may be unavailable. Enable your enterprise to prove not just your product’s benefits and quality, but also your code’s particular “genealogy” and “DNA.”
Best Practice: Be well prepared to be called to account about your R&D details, with timely, complete, credible records.
Lesson #3: drive new product development defensively
Are software investors and executives negligent if they let developers operate without specific, structured oversight?
NEON v. IBM suggests “yes.” IBM’s litigation team made much sales and marketing mileage by proving that NEON’s development team broke the rules.
The NEON zPrime product non-success story serves up the saga that every founder doesn’t want: having to assert that bad IP news was a sudden surprise. NEON’s chairman swore that he was sandbagged by missing product development data.
No software entrepreneur wants to be forced to downplay a key coder’s corporate role while defending new product development. Yet NEON’s chairman made the strange disclaimer that his own programmer, proven to have done initially denied reverse engineering, “was not an officer of Neon.”
Business Wisdom: Software industry litigation indicates that SCM (source code management) is under-resourced by some software companies. Other lawsuits about license payments, engine bugs, and other issues reveal lost data on version control, code contributors, and other R&D history. Partially “disappeared” data makes overall past R&D efforts look suspicious. And prior programmer deployment of open source code without adequate management notification or permissions remain a problem in many codebases.
Reputations are assets. Verify, don’t just trust, the propriety of your product’s IP.
Film fans favor the old movie shtick by the famous Monty Python comedy troupe that “Nobody expects the Spanish Inquisition!” Companies that aspire to displace competitors should fear and expect hard, granular inquiries from those vendors that they discomfit (endnote 7).
Best Practice: “Clean rooms” aren’t just for semiconductor manufacturers. Expect and prepare for tough tests of your R&D propriety and intellectual property “bona fides” (good faith) in court, not just tests of features, pricing, and support in the marketplace.
Lesson #4: compliance audits: many catalysts
Why me?
There’s a new wave of more frequent compliance audits from software suppliers. It’s an emerging challenge for both vendors and customers. Varying possible causes for audit selection are offered by market analysts, cynics, veteran software industry lawyers, and investment analysts.
The NEON v. IBM pleadings raise a troubling question: can threatened transition by a customer from an incumbent vendor to a new supplier cause an “incoming!” audit?
IBM asked the judge to preclude NEON’s litigators from suggesting to a jury that audits by IBM of customers who were considering or testing NEON’s zPrime, were intended to dissuade such prospects from changing suppliers.
Business Wisdom: Many enterprise software product customers wonder why they had the misfortune to “get picked” for license compliance scrutiny. Recent analyst reports suggest that IBM is regularly auditing many of its customers to confirm contract compliance, as a matter of course, in situations where no major new-competitor threat exists. So auditing old enterprise software license compliance now is “old news” and standard industry operating procedure.
Best Practice: Like they say in the movies, “Prepare to be boarded!” It’s been predictable in recent years that license compliance audits can be caused by vendor mergers, customer mergers or divestitures, major product “end of life” transitions, sloppy or suspicious customer usage reports, or merely vendors’ obligations to shareholders to protect and monetize their intellectual property. So all licensees should prepare for being audited – including software vendors who get components, tools, and languages from upstream suppliers.
Lesson #5: indemnification insertions aren’t illusory
What if your company’s name appeared among the NEON customers disclosed in discovery and other court pleadings? Wouldn’t you soon be saying “I want my indemnification!”
The court’s May 31 Permanent Injunction issued – agreed to by NEON as a ticket to the lawsuit’s dismissal, and cancelling the trial that was to start on June 6 – should worry every mainframe manager who tested or transitioned to the now-withdrawn zPrime product. Here’s a key feature of NEON’s new court-ordered “anti-business plan:”
“ 1.a.… NEON … shall … at the earliest possible date … terminate all outstanding licenses of zPrime. NEON shall also promptly request, for each terminated license, certification …discontinued all use …, uninstalled it and has destroyed all … copies …, and … invoke any available contractual rights to obtain such certification. NEON shall … concurrently provide identity of such licensee) to IBM. …”
Now no Big Blue salesperson will fear NEON knocking at a customer account.
Business Wisdom: Oxygen evaporates from sales meetings when legal eagles wrangle with indemnification.
But what if such what-if worrying was right? Will you be entitled to remediation of tangles that wriggled into your business from your suppliers’ missteps?
Best Practice: Don’t dismiss the potential business benefits of inserting “well-coded” indemnification prose in all your “incoming” commercial software supply deals. If you’re a software vendor, the same goes for licensed components, languages, and tools.
Conclusion: better business comes from studying ugly battles
For everyday car wrecks, don’t bother to “rubber-neck.” But with software “train wrecks” – lawsuits among your peers and competitors – look closely and learn. Then drive your enterprise toward safer traffic through a challenging, competitive world.
Henry W (Hank) Jones, III is a 30-year software lawyer, executive, and consultant who has served on the senior management teams of three publicly traded global technology vendors in blended legal/business roles. He has supported over 150 vendors and dozens of licensees in thousands of software development, customer license, OEM, and other channel transactions. Hank has delivered over 200 training and seminar presentations in five countries including chairing and speaking at the open source software session at a Sand Hill annual conference. Based in Austin, Texas, he works nationally, is a member of the California and Texas Bars, and can be contacted at memphishank@aol.com.
Endnotes
1. That’s the financial size of the IBM mainframe market that was threatened by this courthouse drama. The initial judge recognized that “despite the savings effectuated by zIPPS and zAPPs, … customers are still shelling out billions of dollars to run workloads … on Central Processors.” The successor judge noted that “this is a billion dollar lawsuit.” And IBM’s financial expert filed a report asserting $33,458,686 in lost revenue from zPrime “trialees” and 21 actual licensees, as a subset of IBM’s alleged damages.
2. IBM initially included copyright infringement claims, but then later dismissed them.
3. The court’s opinion also denied “summary judgment” to the start-up. So both companies were forced toward the further, significant uncertainty, delay, and expenses of preparing for a full trial.
4. Excerpt from summary judgment ruling denying both parties’ motion for early interpretation of IBM’s customer contracts.
5. IBM’s “statement of the case” specified NEON’s breaching two contracts, as half of its four key contentions.
6. Non-infringement of current, direct competitors is only half the battle. In recent years, compliance with literally dozens of potentially applicable open source licenses is another minimal component of competent software company management.
7. Indeed, many publicly traded software vendors’ U.S. S.E.C. filings explicitly explain to current and possible future investors that intellectual property lawsuits occur particularly often in the software and IT industries.