And not only you might accidentally break patents - you might not even be able to figure out if you break patents at all without paying a lawyer to translate the patent specifications. Maybe it's just because I'm no native english speaker, but I often don't get patent texts. Coding around patents is like walking blindfolded through a minefield.
I'm a native English speaker and I don't generally understand patent texts. In fact, I've filed quite a few patents and have always been amazed that I give something readable to a lawyer to write up and they turn it into something that I can't understand any more. The idea that a patent is the medium through which an author shares their invention with the world is rather perverse.
So I agree; coding around patents is difficult given that they tend to be so hard to read and understand.
I have seen quite a few people who have filed patents state that they don't understand their own patents and (as a general statement) I find this puzzling. A patent has 3 main sections (a) background and prior art (b) description of the invention and (c) the claims.
The claims in particular are indeed technical and difficult for a lay person to readily understand. But the background, the prior art and the description of the implementation are not. Background and prior art are a summary of the technical context and I have never had any difficulty reading or understanding this section. The description may be rather long winded as it has to detail how to implement the invention so that it may be implemented from the description by someone skilled in the art, but it isn't legalese and should certainly be understood by the inventor! The lawyer can't write this by him/herself.
I can certainly sympathize with those who can't follow the claims (although I have found it to be perfectly possible with determined effort), but I simply fail to understand how a lawyer turns it into something "I can't understand any more." Find alien and unfamiliar - yes. But incomprehensible?
You have to understand, though, that legalese isn't English. It may look like English, and even work like English in ways, but its not English. Saying that legalese and English ought to be equivalent because they share words and syntax is like saying C++ and Java ought to be equivalent because they share keywords and syntax.
For patents in particular, though, a big part of the justification is that they constitute a disclosure of the invention to other practitioners in the field. It's a quid pro quo: we grant you a limited term of protection, in return for you divulging the details.
As part of that arrangement, it seems like we ought to require that the disclosure be in English, not merely in a tongue that shares some English words and syntax.
English? Hah. I'm against the whole patent charade but if we're going to grant them, the inventors should be forced to disclose the entire goddamn source code, development infrastructure, and version control repository which proves that they've actually invented something and not just handwaved in the direction of an idea.
Alternatively, you could say that the point of "legalese" is to define and convey ideas more explicitly than they can be defined and conveyed in English. Try writing a contract in "Plain English" - it will necessarily be full of ambiguity and uncertainty, which defeats the purpose of having a written contract.
Similarly, although programmers don't write code in "Plain English" I don't think we should begrudge them the right to keep using obfuscatory programming languages - even if it keeps the bastards employed.
The argument for specific languages for programmers is stronger because programs are intended to be interpreted by machines. I would be perfectly happy with a legalese that is opaque to the layman if it could be fully parsed and implemented by a machine.
I also believe that, by defining one's terms clearly, it should be possible to write unambiguous plain English contracts. Additionally, an English-parsable legalese needn't necessarily lead to an unambiguous interpretation when parsed as English, so long as it is unambiguous when parsed as legalese, and most of the meaning is retained when parsed as English.
One could argue that you shouldn't code around patents in the first go round. Because if you demonstrate that you knew about the patent and then proceeded to infringe on it, you could be liable for 3X the amount.
If you don't know about the patent, then you're only liable for 1X the amount.
Moral of the story: don't read patents, you can only get into trouble. If you get sued after the fact, then you can change your code to work around it.
I'm not sure if that really lowers your overall risk. Finding out afterward that you accidentally broke some patent which you could have avoided easily isn't necessarily better even if you don't have to pay treble damages.
I great example of the trouble someone had to go to prove they were first is the ABC computer. It's an important case if you consider that without John Atanasoff the personal computer would never have existed. At the time IBM and some other corp I can't remember the name held some important patent on memory and other things that would prevent anyone from creating a personal computer without paying IBM. Those patents which had come from the creators of ENIAC were later found to have been heavely (well in reality stolen) from the ABC computer. After years of battles, IBM lost the patents and right after that the PC came to be.
For a worse horror story, just take a look at Farnsworth trouble with RCA about the TV patents.
You could still lose that fight, even if your work came first, if you never published it or filed a patent for it. First to invent only holds if you reduced it to practice (either by actually inventing the thing, or boiling it down so someone reasonably skilled in the art could then invent it) within that year. You lose rights to it after that if someone else wants to patent it. There's also first to conceive stipulations. The intellectual property class I took last semester would have been a lot easier if the U.S. just went first to file (like basically everywhere else).
The US is trying to make that transition. The bill passed the Senate, and Committee in the House, and goes to a full House vote in June 2011. But it will likely be difficult for the two bills to match and be agreed upon because of all the other crap in the bill which has good stuff and bad (much like the overwrought SBIR reauthorization bill that can never seem to pass and it just extended ad infinitum).
I like the "first to file" idea, but it puts the small inventor at a disadvantage. The main benefit is that it will hopefully lubricate university tech transfer offices. No more "oh I'll put in a disclosure and wait and see, I'm safe." it'll incentivize the inventors to file a provisional as soon as possible. But of you're building (or hacking) something in your garage you'd better get a patent attorney quick. And be patient, because response times on a first-to-file system will be horribly slow even compared to today's glacial system.