Developers who 'knowingly' ship buggy software may be held liable for damages.
That might be good for users but a sloppy set of guidelines could hurt open source
Here's an odd couple: Microsoft and the Linux Foundation. These two organizations, normally on opposite sides of almost any issue, agree that a new set of guidelines making software vendors liable for knowingly shipping buggy software is badly off base. They claim that the guidelines are likely to lead to a flood of expensive lawsuits against both large commercial vendors and small-scale open source developers. What's more, it could impose expensive obligations to scour support forums and the like for notice of problems, a procedure that would be overly burdensome for small developers, say critics.
Yes, this is a warning that developers should follow the issue closely. But there's another side to the story: Don't software buyers, both consumers and enterprise, deserve to get what they've paid for: software that solves the problem it was written to address?
"There is a sense that disclosing defects is bad for marketing," says Fred von Lohmann, a senior attorney with the Electronic Frontier Foundation. Indeed, big software vendors have been arm-wrestling with buyers and consumer advocates over the issue of responsibility for buggy code since the 1990s, he says.
A centerpiece for the sometimes heated argument is the ubiquitous user license agreement. If you are one of the relatively few software buyers who has actually read one, you know that vendors typically disclaim responsibility for the quality of their software. And as the law is generally applied today, that means an aggrieved buyer can't sue. Would we allow, say, an auto manufacturer, the same luxury to disclaim responsibility?
Software developers may be held to the same standard as manufacturers under the new guidelines. A key passage, Section 3.05 (b), if you want to look it up, says that user agreements contain an implied warranty that purchased software "contains no material hidden defects of which the transferor the seller was aware at the time of the transfer." What's more, no matter what language the vendor places in the user agreement, the warranty still stands.
The guidelines are just that: guidelines. Written by the respected American Law Institute, an organization of law professors and a small number of judges, the guidelines are designed to help judges apply the law in intellectual property disputes. They are not binding, but because the ALI is highly regarded in the legal community, attorneys on both sides of the argument believe that they are likely to be influential.
Critics of the guidelines maintain that the wording in 3.05 (b) is problematic. What's "material"? What does "knowingly" mean? And what do they mean by "hidden"?
"One concern is that the language ALI adopted may invite class action lawsuits," says Mark Weinstein, an attorney specializing in intellectual property matters with the firm of White & Case. Weinstein, a former software developer, says that because drivers have to interact with such a wide variety of software and hardware, it could be difficult, if not impossible, for the developer or the vendor who ships it to be able to address all potential problems. (White & Case has represented Microsoft in Europe, but Weinstein was not involved in those cases.)
Cem Kaner, a professor of software engineering at Florida Institute of Technology and a leading proponent of the guidelines, said in an e-mail interview that "every company discovers some bugs in the field that they didn't know about when they released the product."
However, Kaner adds: "Now think about the bugs you have reported. At what point, after realizing the bug existed in the software, did the publisher of this software reveal that bug to the public, in a way that prospective customers could know about it? Of all the bugs your magazine has reported, how many did you learn about from the publishers and how many from customers or third parties?"
On the security front, firms such as Microsoft and Symantec certainly publicize security breaches and offer patches. Symantec, of course, is self-interested, publicizing security bugs to help promote its security software; the ubiquity of Microsoft's software and years of complaints by enterprise customers pushed the company to be more open than most about its security holes. But for other types of bugs, most companies are quiet about them outside of vague descriptions in "what's fixed" documentation when they ship an update. So, as someone who has covered the industry for some time, I'd have to agree with Kaner: We in the technology and business press generally hear about problems from customers, not vendors.
In a fumbled attempt to protect open source developers, who often work pro bono, the ALI guidelines exempt free software from the liability of bugs. As we all know, open source software may or may not be free, and free software may or may not be open source. What defines open source isn't the price or lack of a price, but the freedom of the community to modify it under the terms of the GPL or other relevant license. And that raises a number of serious complications for open source vendors, which is why the Linux Foundation joined Microsoft in an unsuccessful attempt to convince ALI to rethink the guidelines.
Is an open source vendor that doesn't charge for its software, but does derive revenue from support and services, covered by the guidelines? It's not at all clear, and the commentary from ALI doesn't address the point at all, according to a letter to ALI signed by attorneys for Microsoft and the Linux Foundation.
And given the almost infinite number of changes by any number of coders that open source software is subjected to, who is legally responsible for defects? Interestingly, even the Electronic Frontier Foundation, an enthusiastic backer of the new guidelines, is concerned about the treatment of open source in the guidelines, says EFF's von Lohmann.
The guidelines apply directly to only the software, but von Lohmann says that judges considering service agreements for, say, cellular data service might apply similar reasoning. And given the heat surrounding AT&T's subpar performance providing 3G service to iPhone users, that's a very interesting idea.
As to the bottom line in this debate, I must confess that I'm still not sure how to balance the conflicting interests touched on by the guidelines. I'm not in the least concerned about Microsoft and other large commercial vendors who have inflicted buggy software on users for decades. But should the independent software vendors, particularly those in the open source community, suffer for the sins of the big guys? The one thing that is clear, though, is that open source and small, independent commercial software vendors had better be on top of this issue.
A hostile business climate is stifling entrepreneurship in software development,
and the U.S. economy pays the price
The actions of Joe Stack, the disgruntled software developer who committed suicide by flying his airplane into the Internet Revenue Service building in Austin, Texas, last week, were callous, selfish, and inexcusable. While in no way condoning his actions, programmers may nonetheless hear a familiar ring in his frustration with a country that seems to actively discourage self-reliance and entrepreneurship, especially in the software industry.
Among the litany of complaints in his articulate (if rambling) suicide note, Stack gave special mention to Section 1706 of the 1986 Tax Reform Act, an obscure law that he claimed reduced him to "a criminal and noncitizen slave." Under the law, certain classes of workers, including anyone who engages as a "computer programmer, systems analyst, or other similarly skilled worker engaged in a similar line of work," are considered de facto employees for tax purposes, regardless of whether they claim to operate their own businesses as independent contractors. The IRS can impose significant tax penalties on companies who hire such workers as contractors rather than full employees, a fact that can make it extremely difficult for self-employed programmers to find work.
Section 1706 was originally sponsored by Sen. Daniel Patrick Moynihan of New York, who hoped that forcing highly paid software developers to become employees would limit their ability to take advantage of tax breaks for small businesses. Ironically, it was also Moynihan who, when a study determined the law was not bringing in the desired tax revenue, tried to have it repealed a year later. He failed, and it's still on the books today.
But Section 1706 isn't the only thing making life hard for independent software developers. Employees typically don't have to pay for their own health insurance, the way contractors do. Individual health plans generally offer worse coverage than group plans, and they can be incredibly selective about who they allow to join. Those who are accepted can expect their premiums to rise every year, often by double-digit percentages. Given these conditions, developers who have families to support or preexisting medical conditions are well advised to hang on to their salaried jobs for dear life, no pun intended, rather than run the gauntlet of the dysfunctional American health insurance industry.
And if the prospect of being bankrupted by medical bills wasn't frightening enough, add the increasingly hostile legal climate surrounding the software development profession. In response to all-too-common reports of software bugs and security breaches, some organizations have begun lobbying for contractual language that makes software developers accountable for any defects in their code. For example, the SANS Institute has proposed a detailed contract that would require developers to certify that they had received appropriate training, observed any and all security procedures deemed necessary, and that their code was free of defects to the best of their knowledge, among other clauses.
Fans of such contracts say structural engineers are routinely held accountable for the quality of building projects, and that software engineers should meet the same standard. But a software program with a security vulnerability isn't the same as a bridge that collapses because it was poorly designed. Modern software applications are incredibly complex systems, and they draw upon countless APIs and libraries whose quality may be beyond the control of any one developer. Under the terms of the SANS Institute's contract, nearly any bug could potentially be grounds for a lawsuit; while an employee of a large software vendor might be shielded from individual liability in such suits, an independent contractor would not.
And, as my colleague Bill Snyder recently wrote about in his InfoWorld blog, software developers now also face sloppily written new guidelines, whose intent is noble but execution is poor, on identifying software bugs.
Given these harsh realities, it's easy to see why software developers would give up on entrepreneurship. For many, the risks simply don't match the potential rewards. Better to keep their heads down, not rock the boat, and hope they can hang onto their jobs until retirement.
This situation must change. In a knowledge economy, programmers rank among our most valuable workers, yet the current legal and regulatory climate makes a career as an independent software developer virtually a dead-end prospect.
That's great news for big software vendors such as Microsoft and Google. They'll be ensured an endless supply of programmers desperate for the safe haven of a steady paycheck, predictable taxation, health benefits, and a shield from civil prosecution when their code turns up buggy. But where will the next Microsoft come from? A field that discourages self-reliance sends the message that the status quo is the highest goal.
Worse, these problems affect American programmers only. Coders overseas aren't subject to taxation by the IRS, so Section 1706 doesn't apply to them. If they're lucky (and many are), their health care system isn't the disaster we have in the United States. In effect, by placing such onerous demands on independent contractors, the United States creates a ready-made market for offshore outsourcing firms such as Infosys and Wipro. They can afford to do the work; American contractors can't.
The Obama administration has already spent billions on the president's economic stimulus project, which the Congressional Budget Office says has saved or created millions of jobs. But tort reform, combined with a more modest health care reform proposal and the repeal of Section 1706 of the 1986 Tax Reform Bill, would go a step further. It would enable citizens to create new jobs at the grassroots level, by allowing out-of-work software developers to return to the economy as independent contractors with their own small businesses.
The alternative is to stick with what we have now: an economy that would sooner send business overseas than encourage entrepreneurship at home. You don't need to be a programmer to see that's just not logical.