Eric S. Raymond's Blog, page 60

The handwriting on the wall is Chinese

Comes the news that Nvidia just lost an order for 10 million graphics cards to AMD because it wouldn’t open the source for its driver. At a very conservative estimate, that’s north of $250 million in business Nvidia just threw to a major competitor because it couldn’t get its head out of its rectum. Somebody’s quarterlies are going to suck.

The really interesting aspect of this isn’t the amount of money Nvidia’s idiotic secrecy fetish just cost it, but why it happened – and why it’s likely to happen again, soon and repeatedly, to other hardware companies with equally idiotic secrecy fetishes.

Seems the Chinese are rolling their own Linux-based operating system for educational PCs. China is big – their pilot project is 10 million units. The Chinese offered Nvidia the graphics card business on all of these; Nvidia’s negotiators, being utter morons, tried to charge the Chinese for the cost of porting NVidia’s binary drive blob from x86 to the MIPS processor the school PCs will use.

The Chinese apparently didn’t even bother telling Nvidia to fuck off. They just ended the meeting and handed AMD the business. Feel the burn, Nvidia!

Now look at the bigger picture. China now has an economy roughly the size of the U.S.’s – by some measures larger. And a bigger population than the U.S.’s. And no patience for the bullshit companies like Nvidia spew defending their closed-source policies. This wasn’t the last such blow-off we’re going to see, but the first of many.

The message has been sent. Do you work for a hardware company with a closed-source driver policy? If so, tell your boss that policy is going to lock your company out of the biggest market in the world, starting now. And not just that one market, either; word of this will spread. With the Chinese to break trail, we’re going to see the same no-compromise stance from the rest of Pacific Rim and emerging markets all over the world.

Pass the popcorn. Heads will be rolling at Nvidia shortly – and if the company’s top management hasn’t got enough clue to fire the addled fuckwits who just cost it China and change its source-disclosure policy, short the stock because the company itself won’t have a long future.

And everything I’ve written about how economics makes the triumph of open source inevitable? This is what it looks like when those pressures are no longer from the future. This is what it looks like when they burst into the now.

Abusing Alan Turing

The centennial of Alan Turing’s birth brings us the news that Alan Turing probably did not commit suicide by eating a poisoned apple, was not depressed at the time of his death, and that the hormone treatments intended to suppress his homosexual urges had been discontinued a year before he died. I am not in the least surprised by any of this; in fact I have been half-expecting such inversions ever since I began noticing, twenty years or so ago, the increasing mythologization of Turing’s life.

This centennial seems a good time to consider how we re-invent – and sometimes abuse – the great figures of our past to suit the needs of the present. When biography turns into a packaged morality play, it is always wise to suspect that the actual facts and complexities of the subject’s life are being lost. When that morality play satisfies obvious propaganda needs for political or cultural factions in the present, we should be even more suspicious. And when certain recurring mythological themes – such as holy martyrdom – develop increasing prominence in interpretation of the subject’s life over time, it’s a red flag signalling that contact with the facts and the subject is probably being lost.

Over the last couple of decades I have watched this process take hold of and transform our cultural memory of what Turing’s life was about. I titled this essay “Abusing Alan Turing” because I think the process has twisted that narrative into a shape Turing himself would have found belittling and barely recognizable. I do not think the man who wrote “On Computable Numbers, with an Application to the Entscheidungsproblem” would have wanted to be remembered as a holy victim, with the defining event of his life being a suicide invented by future partisans. It is worth examining how we came to this pass.

I see several reasons for the mythologization of Alan Turing. The most benign one – of which Turing might have approved – is that computer science has been scrambling to achieve the kind of respectability and professional status long afforded to fields like medicine and the law. One of the characteristics of such professions is that they have hero-myths about great figures in their past who can be seen as foundational or exemplary. Doctors have Hippocrates; lawyers have Thomas More. Each profession seems to need to develop its own exemplars, and the young field of computer science has sought its own.

If this were all that was going on around Turing, though, it wouldn’t be necessary to distort his life. Turing’s intellectual work really did make him a worthy exemplar of the field by about any standard one could conceive. It is instructive to compare him with Ada Lovelace, whose reputation as “the first programmer” is undeserved, resting on a common but severe misrepresentation of the facts.

Ada Lovelace has been falsely mythologized as the first programmer because she was a woman. In a present struggling with issues of sexual equality, her femaleness has served propaganda purposes too obvious to need rehearsing. Turing’s homosexuality, too, has become a sort of marker or talking point in today’s culture wars. The difference is Ada Lovelace was a figure of little consequence in her own time who would probably enjoy her enhanced modern reputation if she could experience it. Turing, on the other hand, is increasingly diminished by the uses we now put him to.

It is not just that the common account of Turing’s death is probably false, it’s that even if it were true it would risk submerging the man’s staggering accomplishments in political correctness and tawdry cliche. Yes, yes, repression, anti-gay prejudice, I know all right-thinking people are supposed to be horrified by such things – but the man who (more than any other single person) cracked the Enigma code and unified computer programming with mathematical logic deserves to to be remembered for those things, not for the accident of his sexual preferences or a myth of final martyrdom later forcibly grafted onto his life.

But the queasiest thing about the myths of Turing-the-exemplar and Turing-the-victim is how they’ve become intertwined. It says no good thing about the year 2012 that Turing’s supposed marginalization by the society of his time has become in many popular accounts a perverse credential for his greatness. In fact he was not marginalized at all – he was a prominent Cambridge don and a hero of his country.who had been awarded the Order of the British Empire. Rather than confront Turing’s homosexuality, the British authorities from the arresting constable on up tried to look the other way and gave every easy out they could; Turing, through some combination of carelessness and self-destructiveness, took none of them.

More: behind much of today’s hagiography there seems to lurk a sort of perverse insistence that if Turing hadn’t been gay and a suicide he would be less apt for veneration, as a founder of computer science or anything else. In what is now made of Turing’s life we see an implicit claim that virtue can only be found in the outsider, the failure, the martyr, the victim of oppression. That is perhaps the most important reason (beyond respect for the man himself) to remember that Alan Turing was none of these things.

doclifter 2.8 is released

In response to a bug report that was relatively easily fixed, I’ve just shipped release 2.8 of doclifter, a program that takes troff-based document markups – including man page markup – and lifts them to DocBook XML.

In doclifter I’ve come as close as I probably ever will to building an AI :-). Automatically lifting the grotty presentation-level goo in man pages (and other troff macro sets) to structural markup is hard – actually, the DocBook user community thought high-quality translations without extensive manual intervention by a human were impossible until I did it. But it turns out that clever parsing and a whole lot of cliche analysis are good enough for about 97% of the real-world cases, and doclifter can throw useful warnings for the other 3%.

This is, by the way, a useful tool even if you’re not interested in DocBook, because DocBook is kind of like Earth orbit – it’s halfway to anywhere. In particular, man to DocBook via doclifter followed by

Docbook to HTML with the stock stylesheets produces better HTML than any of the half-dozen direct man-to-HTML converters out there. This is because none of them actually do much structural analysis – they’re mostly converting presentation-level cliches in troff to presentation-level cliches in HTML. They’re also deficient in handling troff special characters, which doclifter maps to XML Unicode literals.

If you run an open-source project, and your documentation masters are still in troff, please use doclifter to fix this (yes, you will be able to make man pages from the XML after lifting them). That’s why I wrote it – every project that switches to DocBook XML improves our ability to present good-looking and properly hyperlinked documentation over the Web.

The smartphone wars: Inauspicious exits and debuts

RIM’s death rattle became audible a few days ago when its manufacturing partner announced that it would no longer be manufacturing Blackberries. And Nokia is entering the final stages of one of the most spectacular implosions in the history of business, taking the Windows phone down with it.

So what’s Microsoft doing? Announcing a brand-spankin’-new Windows 8 phone line with no upgrade path for its Windows 7 customers. Riiiight. Then, stiff-arming its PC and smartphone business partners by telling them it’s going to do an Apple and ein-Volk-ein-Reich-ein-Führer its new tablet – it won’t be licensing “Windows RT”, and nobody else is going to get a piece of the hardware revenue. So let’s see – Microsoft is throwing away both its historic strengths – backward compatibility and a multi-vendor ecosystem that needs it to succeed – and replacing them with, what exactly?

You know, at this point Microsoft’s board ought to replace Steve Ballmer with an orangutan. Screaming a lot and flinging feces in all directions seem to be the job requirements; the orangutan would cover that for a few bunches of bananas a week, and its strategic decisions couldn’t possibly be worse.

My friends who do IT consulting for businesses are telling me that the compatibility break between desktop Windows 7 and 8 is a big enough disruptor that it may actually drive a lot of their customers to move to all Linux, all the time. Which makes sense; if you know all your old application software is going to break no matter what you do, why not bail out to where you’ll never be a victim again?

Nokia is about to lay off 10,000 people, and investors are no longer pricing the stock above the company’s breakup value. According to some hints that have been leaking out of the company, Nokia thinks it has a bright future as a patent troll. Meanwhile, Microsoft is hinting that it might buy Nokia outright, which would be doubling down on stupid. Nothing about Nokias’s strategy, product or brand-deterioration issues is going to be solved that way; “more Microsoft” is the problem, not the solution.

Contemplating these antics there comes a point at which you just want to clutch your head and mutter, in the immortal words of P.J. O’Rourke, “What the fuck? I mean, what the fucking fuck?” Nokia and RIM used to be sound, well-managed companies with earned and enviable reputations. Microsoft was always evil, but it used to be competent evil – not so much at software engineering, but at least its business strategy was ruthlessly effective. Now, what’s become of these three companies may add up to the biggest destruction of shareholder value in history.

UPDATE: Microsoft may not be planning to freeze out OEMs after all. I was relaying a press rumor based on some ambiguous statements from Redmond, but now a top executive at Acer claims Microsoft only plans to be in the tablet market for a short time. If true, this would make more strategic sense – but the real take-away here may be that Microsoft’s messaging is confused, and possibly the company’s planners don’t themselves know which way they intend to jump.

The Smartphone Wars: Oracle lawsuit’s final fizzle

OK, this is just weird. “Oracle agrees to ‘zero’ damages in Google lawsuit, eyes appeal” That vast lawsuit that, according to some idiots (including a few of my commenters), was going to destroy Android and sow the earth with salt in its wake? It’s done – but in a bizarre way that makes me question the sanity of Oracle’s lawyers at Boies Schiller.

My regulars will recall that I’ve been saying this lawsuit was doomed since day one, a bad joke. Nor was I just handwaving; happens I’m intimately familiar with the case law in this area, because I’ve been involved in a lawsuit with a similar fact pattern. I expected it to end with a whimper, but…Oracle stipulating to zero damages so they can get on with the appeal?

Ow. My head hurts. What are they thinking they can win on appeal once they’ve conceded that the value of Google’s putative infringement was zero? I suppose it’s possible that they’re trying for an appellate ruling that their APIs are indeed copyrightable so they can use it as a competitive weapon against someone else other than Google, but that’s an extremely unlikely outcome. Alsup’s finding is as near bulletproof as they get – well reasoned, well written, and a very conservative extension of the Altai ruling.

I can’t make any sense of what Oracle is doing. My wife the attorney can’t make any sense of it. And Judge Alsup apparently can’t either – when both parties agreed to an assessment of zero damages, he asked “Is there a catch I need to be aware of?”

I dunno, maybe Boies Schiller is huffing the same glue they were during the SCO lawsuit. It’s either that or they’ve got video of the appellate judge buggering a goat. You choose.

freecode-submit 2.4 is released

Yes, two software releases in a day is an unusually rapid tempo even from me. But freecode-submit is part of my release machinery for other projects, and when I shipped GIFLIB 5.0.0 I discovered it had gone all pear-shaped on me. Problem turned out to be an unannounced change in freecode’s JSON interface. I hate it when that happens…

Here it is: freecode-submit 2.4. Enjoy. This project was brought to you by Python and JSON, two technologies that make this kind of specialized client tool as little hassle to write to write as it’s ever going to be.

GIFLIB 5.0.0 is released

I’ve just shipped the 5.0.0 release of GIFLIB, a graphics service library that is deployed pretty much everywhere that throws pixels on a display. Older versions live in your browser, your game console, and your smartphone. I have written about what it was like to go back to this code after 18 years previously, in The Long Past of C; also in my 4.2.0 release announcement.

This version, as promised, fixes the portion of the API handling GIF extension blocks. I made one other change that is visible and not backward-compatible; the GIF file opener functions now take a final pointer-to-int where they’ll deposit an error code if they fail.

The reason for this change was to make the library fully thread-safe. The old API featured a shared static error cell analogous to Unix errno, but I actually got a bug report reminding me that is really not good design practice in the 21st century. Functions that operate on an existing (GifFileType *) set a new Error member when they fail, but the file-openers can’t do that – they return a null (GifFileType *) on failure, and changing that would have caused all kind of subtle problems for which client-application developers would rightly have cursed me.

Other new features include direct support for editing GIF89 graphics control blocks (yes, this is a feature we should have had in 1990), interlace handling in the DGifSlurp()/EGifSpew() high-level interface, and better handling of trailing extension blocks not attached to an image.

I also tossed out a lot more utility code. Basically, if a utility duplicated something that ImageMagick convert(1) or the Python Imaging Library can do, I threw it away. Those projects specialize in image composition and transforms and they do it very well; there’d be less than no point in trying to compete with them, especially since they’re using GIFLIB internally anyway.

Another important feature is that GIFLIB now has a really stringent regression-test suite (I spent a lot of the last couple of weeks on this). It’s also Coverity and cppcheck clean. So I’m expecting this code to be pretty stable. It would suit me fine if I didn’t have to think about it for another 18 years.

Beware the vampire app!

This is a heads-up for all smartphone owners out there. A few days ago I read Buggy Apps Killing Your Smartphone Battery. And I can now certify that the problem is real.

I’d been having what looked like serious battery issues on my HTC G2 for about the last 60 days. It was unclear whether the battery had lost its ability to hold a full charge or whether it was somehow draining at an abnormally high rate. But it was pretty bad – forcing me towards getting a new phone before I really wanted to.

Then I read this article. Short version: buggy apps can eat the battery, presumably through failing to terminate or sleep themselves properly when they should. OK, what the heck – I walked though my download list, deleting a bunch of apps I had downloaded and then decided weren’t interesting, but failed to delete.

To my delight, this cleared the problem up immediately. My phone once again readily takes a full charge and can run for a day or more on it. I haven’t been able to pin down which apps were the problem – I deleted about a dozen – but I can say this much: none of them was one I’m actually using. Hacker’s Keyboard is OK, the Angry Birds games and Coloroid and Spider are OK, the Fandango client is OK, Nexus Torch and OpenRecorder are OK, and (despite a hint in the article) none of the preinstalled Android stuff seems to have been implicated in the excess power drain.

So…if you think your battery is going south, don’t panic. Houseclean all those junk apps off your phone and see what happens. It worked for me.

Why I think RMS is a fanatic, and why that matters.

One of my commenters reports that he showed my essay on evaluating the harm from closed-source software to Richard Stallman, who became upset by it. It shouldn’t be news to RMS or anyone else that I think he’s a fanatic and this is a problem, but it seems that every few years I have to explain the problem again. I make the effort not because of personal animus but because fanaticism does not serve us well – we’ve made huge progress since 1998 by not repeating RMS’s mistakes, and I think it’s important that we continue not to replicate them.

When I was say that I judge RMS is a fanatic, I mean something very specific by that. I cite Santayana’s definition: “Fanaticism consists in redoubling your effort when you have forgotten your aim”. By his own account of his road-to-Damascus experience, RMS started out attempting to solve a problem; there was this broken printer driver that he couldn’t fix because he couldn’t get the source. RMS correctly identified source secrecy as a damaging practice leading to bad outcomes.

Unfortunately, RMS made an early decision to frame his advocacy as a moral crusade rather than a pragmatic argument about engineering practices and outcomes. While he made consequentialist arguments against closed source (and still does) his rhetoric and his thinking became dominated by terms like “evil”, to the point where he repeatedly alienated potential allies both with his absolutism and his demand that anyone cooperating with him share it.

I think this is precisely the sort of displacement Santayana had in mind – means overwhelming ends, rhetoric taking over and trapping the fanatic in a position where the harm he was originally reacting against is forgotten. Instead the language of revelation, virtue, sin, purity, corruption, and redemption dominates. RMS parodies this aspect of his own propaganda when he presents himself as “St. Ignucious”, but the parody does not banish the fact that he is in fact living the role of ascetic holy man bent on purging sin from the world.

There are some advantages to this strategy. It taps into old, powerful emotional responses in human beings – the same responses that give messianic religions their power. As a way of recruiting a small hard core of dedicated followers it’s tough to beat, and sometimes – if you’re, say, the Gautama Buddha or Jesus or Mahavira – you can make it scale up. But I described it as a trap for a reason – most such attempts do not scale, remaining tiny marginal cults.

By the late 1990s, after having observed RMS’s behavior for more than a decade, I had long since concluded that the Free Software Foundation’s moralistic rhetoric was serving us badly. The problem with it is the same problem with messianic religions in general; for people who are not flipped into true-believer mode by any given one, it will come off as at best creepy and insular, at worst nutty and potentially dangerous (and this remains true even for people attached to a different messianic religion).

I was not the first or only person to diagnose this problem, and note that it was severely damaging our ability to talk people outside the hacker community into giving up code secrecy. I was the first person to devise a solution, an entire discourse that could compete with the FSF’s – the rhetoric of “open source”, and determinedly pragmatic arguments for it centered in engineering and economics.

Fifteen years later I think it is clear from results that teaching the hacker community to stop alienating potential allies with terms like “evil” and the rhetoric of sin and redemption was very effective. Understanding that RMS is a fanatic matters, because it reminds us that we have achieved an unprecedented measure of mainstream success by not replicating his rhetoric and his mistakes, and that we need to continue not to replicate them.

It shouldn’t need saying, but this criticism is not personal. I still try to be a friend to RMS on the rare occasions that he permits it. He’s done amazingly good technical work, and is without doubt one of the heroes of our culture. He has the virtues of his vices; he’s a man of unshakable honesty and integrity. But for the sake of the future – indeed, for the sake of RMS’s own original objectives – I have to call him on his fanaticism. There is too much at stake for me to be diplomatically dishonest about this – it did immense damage to the cause of openness, and I had to spend a good many years remediating that damage.

Its is still theoretically possible that RMS and the FSF could clean up its act. A good first step would be to stop characterizing people who refuse to use the rhetoric of moral evil as unprincipled and traitorous. It would be better to drop the quasi-religious rhetoric entirely. But I don’t expect this to happen; too much history and personal investment locks RMS and the FSF into their position. Thus, I expect to have to keep pointing out periodically that it’s fanaticism and that such fanaticism does the open-source community more harm than good.

Evaluating the harm from closed source

Some people are obsessive about never using closed-source software under any circumstances. Some other people think that because I’m the person who wrote the foundational theory of open source I ought to be one of those obsessives myself, and become puzzled and hostile when I demur that I’m not a fanatic. Sometimes such people will continue by trying to trap me in nutty false dichotomies (like this guy) and become confused when I refuse to play.

A common failure mode in human reasoning is to become too attached to theory, to the point where we begin ignoring the reality it was intended to describe. The way this manifests in ethical and moral reasoning is that we tend to forget why we make rules – to avoid harmful consequences. Instead, we tend to become fixated on the rules and the language of the rules, and end up fulfilling Santayana’s definition of a fanatic: one who redoubles his efforts after he has forgotten his aim.

When asking the question “When is it wrong (or right) to use closed-source software?”, we should treat it the same way we treat every other ethical question. First, by being very clear about what harmful consequences we wish to avoid; second, by reasoning from the avoidance of harm to a rule that is minimal and restricts peoples’ choices as little as possible.

In the remainder of this essay I will develop a theory of the harm from closed source, then consider what ethical rules that theory implies.

Ethical rules about a problem area don’t arise in a vacuum. When trying to understand and improve them it is useful to start by examining widely shared intuitions about the problem. Let’s begin by examining common intuitions about this one.

No matter how doctrinaire or relaxed about this topic they are, most people agree that closed-source firmware for a microwave oven or an elevator is less troubling than a closed-source desktop operating system. Closed source games are less troubling than closed-source word processors. Any closed-source software used for communications among people raises particular worries that the authors might exploit their privileged relationship to it to snoop or censor.

There are actually some fairly obvious generative patterns behind these intuitions, but in order to discuss them with clarity we need to first consider the categories of harm from closed-source software.

The most fundamental harm we have learned to expect from closed source is that it will be poor engineering – less reliable than open source. I have made the argument that bugs thrive on secrecy at length elsewhere and won’t rehash it here. This harm varies in importance according to the complexity of the software – more complex software is more bug-prone, so the advantage of open source is greater and the harm from closed source more severe. It also varies according to how serious the expected consequences of bugs are; the worse they get, the more valuable open source is. I’ll call this “reliability harm”.

Another harm is that you lose options you would have if you were able to modify the software to suit your own needs, or have someone do that for you. This harm varies in importance according to the expected value of customization; greater in relatively general-purpose software with a large range of potential use cases for modified versions, less in extremely specialized software tightly coupled to a single task and a single deployment. I’ll call this “unhackability harm”.

Yet another harm is that closed-source software puts you in an asymmetrical power relationship with the people who are privileged to see inside it and modify it. They can use this asymmetry to restrict your choices, control your data, and extract rent from you. I’ll call this “agency harm”.

Closed source increases your transition costs to get out of using the software in various ways, making escape from the other harms more difficult. Closed-source word processors using proprietary formats that no other program can fully handle are the classic example of this, but there are many others. I’ll call this “lock-in harm”.

Finally, a particular software product is said to have “positive network externalities” when its value to any individual rises with the number of other people using it. Positive network externalities have consequences like those of lock-in harm; they raise the cost of transitioning out.

With these concepts in hand, let’s look at some real-world cases.

First, firmware for things like elevators and microwave ovens. Low reliability harm, because (a) it’s relatively easy to get right, and (b) the consequences of bugs are not severe – the most likely consequence is that the device just stops dead, rather than (say) hyper-irradiating you or throwing you through the building’s roof. Low unhackability harm – not clear what you’d do with this firmware if you could modify it. Low agency harm; it is highly unlikely that a toaster or an elevator will be used against you, and if it were it would be as part of a sufficiently larger assembly of surveillance and control technologies that simply being able to hack one firmware component wouldn’t help much. No lock-in harm, and no positive externalities.

Because it scores so low on all these scales of harm, highly specialized device firmware is the least difficult case for tolerating closed source. But as firmware develops more complexity, flexibility, and generality, the harms associated with it increase. So, for example, closed-source firmware in your basement router can mean serious pain – there have been actual cases of it hijacking DNS, injecting ads into your web browsing, and so on.

At the other end of the scale, desktop operating systems score moderate to high on reliability harm (depending on your application mix and the opportunity cost of OS failures). They score high on unhackability harm even if you’re not a programmer, because closed source means you get fixes and updates and new features not when you can invest in them them but only when the vendor thinks it’s time. They score very high on agency harm (consider how much crapware comes bundled with a typical Windows machine) and very high on lock-in harm (closed proprietary file formats, proprietary video streaming, and other such shackles). They have strong positive externalities, too.

Now let’s talk about phones. Closed-source smartphone operating systems like iOS have the same bundle of harms attached to them that desktop operating systems do, and for all the same reasons. The interesting thing to notice is that dumbphones – even when they have general-purpose processors inside them – are a different case. Dumbphone firmware is more like other kinds of specialized firmware – there’s less value in being able to modify it, and less exposure to agency harm. Dumbphone firmware differs from elevator firmware mainly in that (a) there’s some lock-in harm (dumbphones jail your contacts list) and (b) in being so much more complex that the reliability harm is actually something of an issue.

Games make another interesting intermediate case. Very low reliability harm – OK, it might be annoying if your client program craps out during a World of Warcraft battle, but it’s not like having your financial records scrambled or your novel manuscript trashed. Moderate unhackability harm; if you bought a game, it’s probably because you wanted to play that game rather than some hypothetical variant of it, but modifying it is at least imaginable and sometimes fun (thus, for example, secondary markets in map levels and skins). No agency harm unless they’re embedding ads. No lock-in harm, some positive externalities.

Word processors (and all the other kinds of productivity software they’ll stand in for here) raise the stakes nearly to the level of entire operating systems. Moderate to high reliability harm, again depending on your actual use case, High unhackability harm for the same reasons as OSes. Lower agency harm than an OS, if only because your word processor doesn’t normally have an excuse to report your activity or stream ads at you. Very high lock-in harm. If the overall harm from closed source is less here than for an OS, it’s mainly because productivity programs are a bit less disruptive to replace than an entire OS.

So far I haven’t made any normative claims. Here’s the only one I really need: we should oppose closed-source software, and refuse to use it, in direct proportion to the harms it inflicts.

That sounds simple and obvious, doesn’t it? And yet, there are people who I won’t name but whose initials are R and M and S, who persist in claiming that this position isn’t an ethical stance, is somehow fatally unprincipled. Which is what it looks like when you’ve redoubled your efforts after forgetting your aim.

Really, this squishy “unprincipled” norm describes the actual behavior even of people who talk like fanatics about closed source being evil. Who, even among the hardest core of the “free software” zealots, actually spends any effort trying to abolish closed-source elevator firmware? That doesn’t happen; desktop and smartphone OSes make better targets because they’re more important – and with that pragmatism, we’re right back to comparative evaluation of consequential harm, even if the zealot won’t acknowledge that to himself.

Now that we have this analysis, it leads to conclusions few people will find surprising. That’s a feature, actually; if there were major surprises it would suggest that we had wandered too far away from the intuitions or folk theory we’re trying to clarify. Conclusions: we need to be most opposed to closed-source desktop and smartphone operating systems, because those have the most severe harms and the highest positive-externality stickiness. We can relax about what’s running in elevators and microwave ovens. We need to push for open source in basement routers harder as they become more capable. And the occasional game of Angry Birds or Civilization or World of Warcraft is not in fact a terrible act of hypocrisy.

One interesting question remains. What is the proper ethical response to situations in which there is no open-source alternative?

Let’s take this right to an instructive extreme – heart pacemakers. Suppose you have cardiac arrhythmia; should you refuse a pacemaker because you can’t get one with open-source firmware?

That would be an insane decision. But it’s the exact kind of insanity that moralists become prone to when they treat normative rules as worship objects or laudable fixations, forgetting that these rules are really just devices for the avoidance of harm and pain.

The sane thing to do would be to notice that there are kinds of harm in the world more severe than the harm from closed source, remember that the goal of all your ethical rules is the reduction of harm, and act accordingly.