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…
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.
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.
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.
I’ve now read Judge Alsup’s ruling in the Oracle vs. Google lawsuit addressing the copyrightability of the Java APIs as a matter of law. This is a bigger win for the good guys than appears at first glance; Alsup has subtly but definitely driven a stake through the heart of API copyrights. The interesting part is how he did it.
To the surprise of nobody who was actually familiar with the underlying law and precedent, the judge in the Oracle-vs.-Google mega-lawsuit ruled today that Oracle’s claim of copyright protection on the Java APIs is contrary to law.
This means Oracle’s claims against Google are toast. Their best case is now that they’ll get $300K in statutory damages for two technical copyright violations, almost noise compared to what Oracle spent in legal fees. The patent claims went just as thoroughly nowhere as I predicted back when the lawsuit was launched.
It’s all over the net today. As I repeatedly predicted, the patent claims in the Oracle-vs.-Java lawsuit over Android have completely fizzled. Oracle’s only shred of hope at this point is that Judge Alsup will rule that APIs can be copyrighted, and given the extent of cluefulness Alsup has displayed (he mentioned in court having done some programming himself) this seems rather unlikely.
My regular readers will know that (a) I’ve recently been pounding bugs out of GPSD with Coverity, and (b) I hate doing stupid clicky-dances on websites when I think I ought to be able to shove them a programmatically-generated job card that tells them what to do.
So, here’s a side-effect of my recent work with Coverity: coverity-submit. Set up a config file once, and afterwards just run coverity-submit in your project directory and stand back. Supports multiple projects. Because, manularity is evil.
Here’s the HTML documentation.
I’ve been pounding on GPSD with the Coverity static analyzer’s self-build procedure for several days. It is my great pleasure to report that we have just reached zero defect reports in 72.8KLOC. Coverity says this code is clean. And because I think this should be an example unto others, I shall explain how I think others can do likewise.
The GPS with my magic modification that makes it into a 1ms-accurate time source over USB arrived here last week. And…wow. It works. Not only is it delivering 1PPS where I can see it, it’s the best GPS I’ve ever handled on a couple other axes as well, including superb indoor performance. Despite the fact that it’s been sitting on my desk five feet from a window blocked by large trees, it acquired sat lock in seconds and (judging by the steadily blinking LED) doesn’t appear to have lost it even transiently at any time since.
I got emailed summaries from a Coverity scan of the repo head version of GPSD today.
In a recent Google+ comment, H. Peter Anvin grumped about GPSD using “braindead heuristics” to determine which USB devices it should sniff as possible GPses when it gets a hotplug notification saying that one has connected. I was going to reply in a comment there, but the explanation ran too long for that.
Short version: yes, GPSD will very occasionally sniff at a device that is none of its business. We’re stuck in a bad place because of deficiencies in the USB standard, But it doesn’t happen often, and all the alternative behaviors I’ve been able to imagine would be worse in very obvious ways. Detailed explanation follows.
As promised, the Penguicon 2012 Friends of Armed & Dangerous party location: room 370. Begins 9PM tonight.
Hacking on the C code of giflib after an absence of nearly two decades has been an interesting experience, a little like doing an archeological dig. And not one that could readily be had elsewhere; nowhere other than under Unix is code that old still genuinely useful under any but carefully sandboxed conditions. Our reward for getting enough things about API design right the first time, one might rightly say. But what’s most interesting is what has changed, and giflib provides almost ideal conditions for noticing the changes in practice that have become second nature to me while that code has stood still.
Reminder: The Armed & Dangerous party at Penguicon 2012 is now barely more than 72 hours away. Begins 9:00PM Friday night, room number to be announced on this blog and probably tweeted too.
All readers of this blog will be welcome. See the real faces behind the Gravatar icons! Pursue discussion threads in person! Refrain from actual physical violence! Wheeee….
In 1994 I handed off the maintainership of giflib, the open-source library used by pretty much everything in the universe that displays images for the single most widely used icon and image format on the World Wide Web, because patent issues made it unwise for the project to be run by someone in the U.S. Now, eighteen years later, Toshio Kuratomi (the hacker who took it over then) has asked me to resume the lead. I have accepted his request.
One of my commenters brought up John Robb, a former SpecOps pilot who has made a name for himself as a counter-terror theorist by writing about “open-source warfare”. Mutual acquaintances confirm what Robb’s own writings suggest, which is that his notions of open-source warfare are heavily influenced by what I have called the bazaar model of software development.
When I learned this in 2004 I attempted to begin a conversation with John Robb by email. The remainder of this post is my email to him – to which, for whatever reason, he never replied. I have edited the one link reference into a live link.