5 ms·
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 th
by coffeeaddicted 15y ago
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.
- mbreese 15y agoOne 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.
- Sindisil 15y agoYup. The quasi-official policy at some places I've worked is that engineers are not to browse the patent database, for exactly that reason. Ironic, given one of the original primary reasons for the patent system.
- coffeeaddicted 15y agoI'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.
- chris_j 15y agoI'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.
- tungwaiyip 15y agoI'm guilty too. I have some patents granted and I don't even know what it is about base on the description written by lawyers.
- quanticle 15y agoYou 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.
- nitrogen 15y agoThis is presently true, but shouldn't it be possible to define a legalese that can be parsed as English as well?
- MBlume 15y agoYes, but the fact that it's impossible is considered a feature, not a bug, by those who use it -- it keeps the bastards employed.
- westicle 15y agoThat's one way to look at it. 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.
- nitrogen 15y agoThe 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.
- noonespecial 15y agoAnd you get fined triple if you're looking for mines.