Why the Progress and NuSphere vs. MySQL AB litigation is about sloppy deal making, not open-source integrity.
Many describe a new continuing lawsuit in federal court in Boston as “The first litigation testing the validity and enforceability of the General Public License” (GPL). So what?
Will this litigation really impact the future of Linux programmers? Does this dispute matter for companies betting their business models on the open-source trend? Will the judge get the chance to punish an arrogant American software vendor that broke the long-known rules of GNU and thereby defend the OSS cause, as some OSS advocates have suggested?
Sorry, probably not. Yes, the case is important. Yes, it is apparently the first GPL court test, by consensus. But it won't foretell the OSS future because it's a dispute about an extraordinarily poor contract in a context of chaotic, changing communications between the parties.
You can't project the prospects of a programming language from analysis of one short, poorly documented application coded in that language. And in this case, the underlying contract is an outlier that's so far from norms of modern prudent software management and licensing practices that by many orders of magnitude, it's off the map. It ultimately will prove more relevant for “Software Product Management 101” and “Beginner Software Contracts” training than for refining OSS strategies.
The story is told in the publicly available court pleadings. The contract underlying the litigants' dispute is a disclosed attachment to the answer filed by the Finnish authors of the well-known MySQL OSS database to the lawsuit initiated by the US software publisher/remarketer. (So the contract and the parties' various arguments, e-mails and affidavits are “open source” for tech managers, lawyers and trainers to study and use to improve work processes.)
This author obtained from court pleadings the original international agreement by which a publicly traded, long-established business software company based in Massachusetts obtained remarketing rights from a young, offshore, small developer in Finland. Ugly surprise: these two companies agreed to do a big-impact, large-dollar deal on a mere nine-paragraph contract. The agreement ran all of 1.25 pages.
Progress Software agreed to pay roughly $300,000 US to a dynamic foreign company in a new, unfamiliar (to Progress) industry segment, on the equivalent of the proverbial envelope. MySQL AB, the Finnish company, blessed the Massachusetts vendor's procurement of its key product by a short statement indicating some future contract would be utilized “later”, triggering “a total of up to $2.5 million”. The resulting fight shows precisely why experienced business people (including lawyers) frown at the optimistic idea of “let's just trust each other and figure out later the deal and the details.”
What's wrong with a little brevity and trust? Think of it this way: why do surgery before taking x-rays or reviewing a medical history? Why not dive head-first in to an unfamiliar river? You can both get hurt and hurt others by launching a major software initiative—OSS or proprietary—without first figuring out the basic rules. That's what happened here.
One purpose of most contracts is similar to the norms of much data processing: benchmarking, testing and standards. Here, fragmentary code got shipped. That is, an incomplete “agreement” was relied upon for too much action, too soon.
What did this short and ultimately bitter contract omit? The majority of terms and conditions found in most software agreements, that's what. Conspicuous by their absence, among other points, were 1) When would the expected “later, superseding agreement” be completed? 2) Within what parameters for the business terms? 3) Exactly what degree of service would be required and provided for technical support? What did they mean by “enterprise level support” and “existing electronic support channels”? 4) Who would be the designated liaisons for intercompany coordination? 5) What does it mean to give your licensee “fair use” rights to your key trademark, as MySQL AB blessed here? What particular variations would be permitted and excluded? 6) What ongoing product enhancement services by the original author would be assured? 7) How would disputes be resolved or arbitrated, if necessary? 8) If there's a dispute due to one party's fault, will the nonbreaching party get its enforcement costs and damages reimbursed by the defaulting party? 9) Why omit all the often-derided generic or “boilerplate” provisions that are included in most contracts precisely because they help prevent disputes and enable enforcement?
Most modern, mature software businesses recognize the many issues that can and do arise in a software distribution deal. They design their deal (e.g., in a “terms sheet” or outline), then “code” (i.e., write a draft contract), then test and document their agreements (i.e., negotiate and refine the base contract and write and revise the necessary exhibits), just as they do their applications.
For example, many software projects identify “user requirements” in detail and in advance. This deal apparently lacked a joint “terms sheet” or “deal summary memo” as the anchor for the agreement.
Most applications get a look-over for quality control by programmer colleagues. Automated code-testing tools get deployed in some complex environments. This contract presumably was shipped out as the handiwork of one individual, or at least of a very small team.
Savvy software professionals include error-message features. This oblique agreement lacked the typical “notice of breach, then opportunity to cure the breach” provision.
Experienced coders include header files and other technical documentation in their work to assist later revisions and debugging. In your software transactions, include specified modes of communications between the author and publisher companies. Decide up front which particular individuals have the authorization to pass commercial instructions, objections and suggestions to some specified person(s) in the other organization.
The contract's brevity means the parties may raise legal issues that will muddy the waters or at least defer the outcome. Remember, the wheels of the justice system can grind very slowly, at least in the US.
OSS loyalists hoping for court affirmation of the GNU model may be frustrated: both sides of the suit have already raised legal arguments unrelated to the OSS issue. For example, MySQL AB has already obtained (on February 28) a partial injunction against Progress and its young OSS subsidiary NuSphere, but on trademark law grounds, not enforcement of the GPL. The federal judge found the GPL issue too uncertain to adjudicate in this litigation's early, summary phase.
Then there's the legal doctrine of “mutual mistake”. A contract sometimes can go unenforced when both parties inadvertently hold different, though reasonable, interpretations of the deal's predicate and terms. The classic case involves a similar cross-border mishap.
The rashness of this saga is underscored by its multicountry context. Transnational transactions merit extra thinking and terms, just like multinational applications often require more modular screen messaging, two-byte code (for Asian character sets), accommodating different operating system iterations and other shrewd coding.
Doing deals with foreign companies requires extra consideration. For example, many offshore companies prefer (or insist on) the use of arbitration to resolve disputes, both as part of a strong cultural tradition and to avoid the rumored American tendency toward premature, extended and expensive litigation. (Here, the litigants filed 73 different court pleadings in the initial nine months of the case, with no end in sight.)
World travelers arrange translators, confirm supply lines and determine local communication protocols before setting out. In international contracts, many companies take similar extra steps. They pre-agree on minimum collaborative product planning, contractually commit to visit each other's headquarters and meet at major global tradeshows and include other contractual “glue code” to help refine the relationship. Common sense says to develop a map when venturing into unfamiliar territory. Here, the parties got lost and found themselves in court, with the resulting marketing disasters, big litigation bills and an uncertain product road map.
Some in the OSS community have attacked Progress and NuSphere, citing the accurate but fragmentary story that the MySQL code got modified and then marketed via a proprietary license, not the GPL or some other OSS license. True, NuSphere modified its model to use GPL, and in NuSphere's view thus fixed a mere short-term oversight. But that's not the full story. The pleadings suggest another perspective: criticize Progress instead for letting some product manager do a poorly documented contract, presumably without coordinating with counsel and other colleagues. Sentence this individual to attend a licensing workshop. Maybe commute the sentence due to time-to-market competitive pressures. And then bet good money that next time both companies will use traditional, coherent, complete software contracts, after learning from spending big bucks on litigators and losing time, managerial energy and market goodwill.
The Progress-NuSphere-MySQL fight ultimately may prove to be just another chapter in the long book of companies who practiced “ready, fire” without adequate “aim”.
