How a Poor Contract Sunk an Open-Source Deal
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?
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- The Tiny Internet Project, Part I
- Bitcoin on Amazon! Sort of...
- Machine Learning with Python
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Android Browser Security--What You Haven't Been Told
- Epiq Solutions' Sidekiq M.2
- Returning Values from Bash Functions
- Securing the Programmer
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide