May 2007

I’m a big fan of Google’s Summer of Code program — it’s brought a lot of new developers to the Subversion project, and this also seems to be true for many other open source projects.

Summer of Code encourages college students to participate in open source projects over the summer, by funding both the student (for the time spent coding and learning open source processes) and the project (for time spent mentoring). The students earn enough for it to be their main summer job, but they also often stay involved in their projects after the summer is over, which is a sure sign that the program is working. In some cases, a Summer of Code project has led directly to a full-time job offer for a graduating student, too.

This year, Google decided to send every student a signed copy of my book, Producing Open Source Software. Now, the team that runs Summer of Code is the same team I worked in when I was at Google: the Open Source Program Office. But I’m sure they chose the book on its merits, and that there’s no favoritism going on here (so stop muttering under your breath like that, please. No, really, I can still hear you… there, that’s better, thanks.)

Thus it came to pass that a couple of days this spring, I drove down to the Google offices in Mountain View, visited with my old teammates for a while, then went to a cubicle and signed books. Nearly a thousand of them — it took a lot longer than I expected, and my wrist hurt, but on the other hand it was interesting to have a way to physically feel how big the Summer of Code program is. Next time I ask a computer database to iterate over a thousand entries, I’ll do so with some sympathy.

If you received a book, here’s your evidence that the signature is real:

Signing copies of “Producing Open Source Software” at Google.

(Notice the pad of paper under the elbow of the signing hand. I’ll bet real authors travel with a special cushion, but that, uh, hasn’t been necessary so far in my case.)

About halfway through the second session, I took a break. The books stacked neatly on the floor in front of the cubicle are done, the ones on the desk are still unsigned:

More copies of “Producing Open Source Software” than I have ever seen before.

Someone asked me if I signed every book exactly the same way. The answer is yes, except for one: there’s an Easter Egg book with a special message. If you got it, you’ll know it.

No doubt this was just an accidental slip by a photo caption editor on autopilot, but still it’s disheartening to see the New York Times broadcast Administration talking points so unthinkingly.

This photograph on page A9 of yesterday’s New York Times shows a lone demonstrator (apparently one who supports the Administration’s policies) standing across from a group of anti-war demonstrators on the opposite street corner:

Photo and caption from top left of page A9, Monday, 28 May 2007 New York Times

The caption reads:

“Jeff Broderick, foreground, standing alone last week in support of United States troops as demonstrators for peace occupy an opposite corner.”

So if he supports the troops, I guess that must mean the people on the other side of the street uh… don’t support the troops? Right.

Please. NYT, you can do better :-).

To be fair, one could also say — by a bit more of a stretch — that the second half of the caption buys into the anti-Iraq-war message machine, when it claims that the demonstrators on the opposite corner are “for peace”. After all, a supporter of the invasion might argue that the invasion and occupation are the route to peace, and that opposing the war now will not lead to peace. I don’t agree with that reasoning, but in any case the caption needn’t have gotten into the debate at all. It could have said:

“Jeff Broderick, foreground, standing alone last week in support of administration policy in Iraq, as demonstrators against occupy the opposite corner.”

That would have been both more precise and less controversial.

Microsoft recently claimed that open source code (in particular the Linux kernel) violates 235 of Microsoft’s patents. It’s not clear they actually intend to sue anyone for infringement, it may instead be some kind of bizarre publicity ploy. But there’s a great quote from Microsoft’s licensing chief, Horacio Gutierrez:

This is not a case of some accidental, unknowing infringement… There is an overwhelming number of patents being infringed.”

Get the implication? There are so many patents being infringed here, those open source developers couldn’t possibly have done it by accident! It’s just too many!

Which is the opposite of the truth. It’s far more likely that, if there are any infringements, they’re all accidental. Independent reinvention is the norm in software, especially given that the Patent Office frequently grants software patents for techniques which are either obvious or for which there is prior art available. (The Patent Office doesn’t do this intentionally, it’s just that it’s hard for a patent examiner to be skilled enough in all the varieties of programming to know what’s obvious in a given subfield, and also hard to find the right examples of prior art when there’s such an ocean of code out there to wade through.)

Assuming Gutierrez meant his statement sincerely, it reveals a lack of knowledge hard to believe in a high executive at a software company. Can he really be ignorant of the most basic realities of software development? I mean, it’s not like programmers sit around reading patents all day; in fact most programmers go out of their way to avoid looking at patents. Thus, infringements are almost always accidental. At the very least, a tally of 235 (alleged) violations would in no way imply that a single one of those violations were deliberate.

In fact, there may be far fewer violations than that, possibly even zero. For one thing, Microsoft has so far refused to name the specific patents or the infringing code, so the whole charge is FUD for now. For another, even if they do name a specific patent, and it matches (“reads on”, in patent jargon) the program code in question, the patent may still be re-examined in response to a challenge, or invalidated in court.

Anyway, my point isn’t about the degree of danger to free software (though fortunately that appears to be small). It’s about the fact that a Microsoft executive would assert, apparently with a straight face, that some of the infringements must be intentional simply because 235 patents are alleged to be violated. That is laughable.

(By the way, I found Gutierrez’s quote here, but you can probably find it many other places too, just do search://microsoft linux patent gutierrez/.)

I’ve written elsewhere about how software patents harm software development. This article is about how there’s very little corresponding benefit to justify that harm.

Ostensibly, our patent system is supposed to stimulate innovation and progress, by granting those who come up with a genuinely new and useful invention a temporary monopoly on that invention, as long as the inventor describes it by publishing a description in the government’s public registry of patents. (Already we’re on shaky ground, because this isn’t actually how the modern patent system came to be, but let’s leave aside the history for a moment — interesting and unexpected as it may be — and concentrate just on the present-day realities of software patents.)

The first sign that there’s something wrong with software patents is that (as any patent attorney working in software can tell you) they are overwhelmingly collected as a defense against incoming patent infringment suits. Most companies don’t intend to collect royalties on their software patents, they just keep the patents around in case some other company decides to bring a patent infringement suit, at which point the target of the suit goes digging in their patent portfolio and comes out with some patents that the plaintiff is probably violating — at which point the two sides sit down, work out a cross-licensing deal whereby each gets the rights to the others’ patents, and neither has to worry about it again. It’s a classic arms race situation: in a world where everyone is armed to the teeth, everyone must be armed to the teeth. Except, of course, that small players can’t afford the overhead of filing patents and keeping patent attorneys on staff, and are therefore vulnerable to infringement suits that they cannot defend against, regardless of the suits’ merits.

Another sign the system is broken is that filing software patents is almost always a byproduct of normal software development work, rather than the intended goal of research projects. In other words, programmers are solving problems in new and useful ways just in the normal course of their work. Typically, their employers instruct them to say if they’ve done anything that might be patentable, so the company can file for the patent. (I’ve received such instructions myself, as have most programmers I know.) So the innovation precedes the intent to patent, and would have happened anyway without the patent, since it was needed to do whatever the programmer was trying to do in the first place.

“Ah”, some would say, “but that’s missing the point. The patent still does society some good, because it forces the programmers to publicly describe their solution, so we can all benefit from it. Without the requirement to publish, the secret trick would remain hidden in their private source code, where others cannot learn from it.”

That argument would make sense if programmers ever used the patent office as a research aid, but in fact, they don’t. I’ve never heard of a programmer turning to filed patents to get help solving a technical problem. (I once made this assertion in the company of another programmer, who said he had heard of someone doing this, but when pressed, he thought about it more and realized the person was actually just examining patents for competitive analysis: he was trying to get news on what his competition was up to, not looking for information on solving technical problems.)

Even if filed patents did contain interesting technical information, which for the most part they don’t, they’d still be a pretty cumbersome way to find out that information, because patents are written in a special language designed for making claims that are defendable in court, not for communicating technical details clearly. Companies naturally want their claims to be as broad as possible, while still being defensible. But these goals are orthogonal to, and often opposed to, the simplification and reduction that are the heart of technical clarity. Learning a programming technique by reading a patent would be like learning to cook by reading municipal health inspection regulations: boring, painful, and in all likelihood unsuccessful.

But as I said, programmers rarely read software patents to learn from them anyway. The vast majority of the time, when they’re reading software patents, they’re doing it to determine whether they or someone else might be infringing. Don’t take my word for it — go ask a programmer about their actual experiences with software patents. You’ll find they’re either filing patents on work they were doing anyway, or spending time analyzing patents (solely to determine infringement, not to learn something new in their art), time they would almost certainly rather spend doing just about anything else.

Are you ready for the final irony?

Most programmers are instructed to consciously avoid looking at patents at all. This is because when you knowingly infringe on a patent, you are liable for triple damages as compared to accidental infringement. I don’t know what legislators came up with that doctrine, but what on earth were they thinking? We now have the paradox of a system whose supposed purpose is to spread knowledge, yet which those capable of using take pains to avoid, for fear of increased legal liability.

To summarize:

  • Software patents are mainly used as a defense against other software patents — a zero-sum arms race.
  • Filing software patents is generally a byproduct of work the programmers would do anyway, that is, the acquisition of the patent is not a motivating factor in the development of the new technique, it is merely a result.
  • Programmers do not use the patent office as a research tool, even though that was supposed to be part of the point.
  • Patents are written in a special style which is antagonistic to communicating software techniques clearly anyway.
  • Due to the triple-damages rule, programmers must consciously avoid looking at other software patents whenever possible.

I’m mostly leaving aside the issue of patent duration here. While it’s true that the length of time a software patent lasts is ridiculous (20 years from the earliest claimed filing date, in the U.S., for all patents, not just software), the term length is not in itself a philosophical objection. Although the harm of software patents would be greatly reduced if the term length were only, say, 3 years instead of 20, that would still do nothing to address the other concerns. No matter what the term length, we just don’t need software patents. If the purpose of patents is to stimulate innovation (a debatable goal in the first place), they are having the opposite effect in software: programmers are forced to avoid using the best tool for the job, for fear of infringing on a patent, and are forced to avoid building on each others’ work, for fear of triple damages. And even granting that innovation were a goal worth sacrificing freedom for, there would be no need to artificially stimulate innovation in software, because tremendous innovation already happens in the natural course of things.