Bryan Cantrill, kernel engineer extraordinaire and co-author of Dtrace, blogged his thoughts about reverse-engineering and patents in the context of Linus moving the Linux kernel souce code mgmt system from BitKeeper.
I (like many engineers, I suspect) view reverse engineering as a Natural Right. That is, I believe that we are endowed with certain unalienable Rights, and that among these are Life, Liberty and the pursuit of Understanding how the hell something works (or doesn’t, as is frequently the case). Perhaps perversely to some, it is my strong belief in the right to reverse engineer that leads me to my equally strong belief in the responsibility of government to establish a system of patents: if you use my product, you have the right to take it apart and understand its inner workings, but I have the right to protect my intellectual property by patenting the novel mechanism that represents a non-obvious advance in the state of the art. That is, it should be the protection afforded by patents — and not the obfuscation inherent in a running system — that prevents the rip-off artists. My belief reflects the fact that nearly all applications of reverse engineering do not in any way violate anyone’s intellectual property — and the act itself and alone can never violate intellectual property.
Quite right. Unfortunately, software patents today are ridiculous – there’s an article every week or two on Slashdot about some extremely obvious idea being granted a patent. I think we’ve already reached the point where any piece of decent software inevitably violates some or the other software patent. Software patents have now become a tool for companies to muscle their way into, or keep their stranglehold on, existing markets, using the principle of Mutually Assured Litigation. You use a patented idea of mine that doesn’t make a difference to me, that’s fine – but if it’s any threat at all to my market position, I’ll sure as hell sue you. So we’re now walking through a legal minefield wherever we go. In addition, there isn’t too much use knowing how a particular piece of software (Bitkeeper in this case) works unless you can do anything with it. If, for instance, Tridge did find out how Bitkeeper worked, he wouldn’t have been able to do much with it. It’d only tell him how not to design a new source code management system, since the existing process’ been patented. So although in principle, reverse-engineering ought to be allowed for patented software, from a practical point of view, it really doesn’t mean too much.
BMC does, however, consider that point of view:
I believe strongly in reverse engineering in particular, but it plays an especially critical role in the development of software: in my experience, when developing a layer in the stack of software abstraction, you always need to understand at least one layer below you and you often need to understand at least one layer above you — and reverse engineering is often the primary means to achieve this understanding. More generally, software is usually reverse engineered to work around oversights or blunders, or to simply understand a software system sufficiently well to interoperate with it.
So reverse-engineering for the sake of developing software elsewhere in the software stack, or for the purpose of interoperability, ought to be allowed. It also enables better quality software (in terms of bugs being found, or better interfaces being suggested). Therefore, using the simple principle of “many eyeballs make bug-finding easier” (or equivalent) by Eric S. Raymond, software ought not to be closed-source in any case.
So we’re at a stage where software patents are important (even a necessary evil, perhaps) to preserve competitiveness and encourage participation (indeed, there are many startups whose entire existence depends upon a patent or two!). But we need to draw a line when patents are granted. All too often, one crucial aspect of a patent – novelty and non-obviousness – is simply overlooked. And availability of source (which, actually, obviates the need for reverse engineering) is a necessary (but not sufficient! ;-) precondition for high-quality software.