标签: open source

In this  ACM Queue article, Poul-Henning Kamp recently proposed a new set of laws to protect users from harm caused by software. Mr. Kamp first quotes an excerpt from a Ken Thompson's Turing Award lecture: "You can't trust code that you did not totally create yourself." This quote may have been appropriate in 1983 when Mr. Thompson delivered the lecture, but is patently absurd today. We do trust a lot of code. Whether it's the code in your microwave or that which injects fuel into your car's engine, we confidently expect software to work. It generally does. The article proposes a law written in three clauses. Let's take them apart one at a time. Clause 0 . Consult criminal code to see if any intentionally caused damage is already covered. This clause is supposed to cover malfeasance such as that demonstrated by Stuxnet, but what does "intentional" mean? ( I hate to sound like a lawyer or a particular ex-president, but it will be lawyers arguing the cases ). Suppose a doctor for years ignored important advances in medicine. Generally he gets away with this, but then a patient suffers harm or dies. I have no doubt a court would find him guilty of malpractice, and would consider his actions intentional. Ignoring advances in his field is an intentional action, mirroring the old dictum "failing to make a decision is itself a decision." One could make a pretty persuasive argument that, for instance, since the use of a sloppy development process is always intentional (because we decide what and how we'll do things), the inevitable results (bugs) are in effect intentional. Further, there's a wealth of literature that demonstrates how poor processes translate into defects, so the developers, or their bosses, are in a position analogous to the doctor who didn't avail himself of the latest techniques. In fact, there are papers in the literature which have called certain development strategies "professional malpractice." This is not to say that the only standard is perfection. The best of doctors lose patients. It means any team whose processes aren't high quality could be liable. And, honestly, that could ultimately be a good thing! As Mr. Kamp humourously writes: "...any pundits and lobbyists they could afford would spew their dire predictions that "this law will mean the end of computing as we all know it!" To which my considered answer would be: "Yes, please! That was exactly the idea."" Then there's the second clause: Clause 1 . If you deliver software with complete and buildable source code and a licence that allows disabling any functionality or code by the licensee, then your liability is limited to a refund. This homage to open source is naïve. The vast majority of our users don't know the difference between a zero and a one. They simply haven't the skills to understand the source, let alone modify it to disable some functionality. Even for those of us who can, we have neither the time nor the toolchains. We're surrounded by software, millions and millions of lines of the stuff. The trust that Ken Thompson eschewed is the only way we can practically cope with this web of technology. If Novartis supplied me with a mass spectrometer and the chemical formulation for my blood pressure medicine I still would not have the skill to test it for purity. In this supremely-complex world we rely on the expertise of others. The fact that the medicine's chemical structure is printed on the instructions that accompanies the pills does not absolve the manufacturer of liability for a bad batch. Suppose the regenerative brakes in your hybrid car fail due to a software error, but it did come with a disc containing the source code. Does the auto maker get a pass? Five people dead, perhaps, and the only liability is the price of the vehicle? In my next column, I'll deal with the third clause.  

Maybe it was a slow news day then. I was installing a tool chain and actually read the end user license agreement (EULA), always a bad idea unless one has a strong appetite for the absurd. At 4646 words, some seven pages, riddled with attorney-speak, it sure appears designed to induce narcolepsy.   The vendor is a great company with a marvelous product, and has provided fantastic support. And I'm a big believer in the legitimacy of copyrights. But these so-called EULAs have become outrageous.   First, the EULA is titled an "agreement." While it meets the definition of that word, it feels much more like coercion. There's no provision to modify the language in even the slightest form to fit the technical or legal needs of the customer. The "agreement" spells out all of the vendor's rights and none of the user's.   Secondly, the sheer length of said "agreement" insures few will read it before clicking the "accept" button. Of course we have a responsibility to read and understand contracts. But confronted with a blizzard of fine print every day, it's awfully hard to do so.   Then there's the provision that we, mere engineers, agree to bind the entire corporation to the terms of the EULA. Huh? That's probably not legal, certainly not likely, and is sure to get one fired if the PHB finds out we're making such commitments.   The "agreement" stays in effect for an "indefinite" period in time. That word means either forever, or for a neither precise nor exact time period. That sounds like somewhere between a microsecond and eternity, so means nothing.   One is further required to keep records of the use of the software. Do you?   Finally and perhaps most importantly, the only warranty given is that the media will be defect-free. I downloaded the stuff, so even that weak guarantee is pretty lame. Would you buy an appliance whose only guarantee is that the box it is shipped in will be intact?   To quote a pithy section from the U.S. National Research Council's " Software for Dependable Systems " Sufficient Evidence? " : "No software should be considered dependable if it is supplied with a disclaimer that withhold the manufacturer's commitment to provide a warranty or other remedies for software that fails to meet its dependability claims."   Yes, I know that many see EULAs as more motivation for the use of open source software. But proprietary tools have an important place in this business.   What's your take on EULAs?