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.