Understanding (and Avoiding) Software Patents?

An anonymous reader asks: "I'd like to write some Free backup software, but this area is mined with patents. I downloaded one and tried to understand it, but the 'claims' section (arguably the most important part) is made up of utterly incomprehensible patentese, and I can't afford to hire a patent attorney to help me understand it. Are there any free or cheap ways to learn enough about patents to understand them, so I can figure out exactly what is patented and therefore avoid it?" "How different does my software have to be in order to be non-infringing? The patent I tried to understand is Dantz's 5,150,473. Many, including Slashdot readers, have said what this patent covers, but from reading the patent itself, I would never have guessed. Also, there are lots of other patents to understand and avoid, so I'm looking for general information on how I can unravel it all into language I can understand."

Comments

Don't Read Patents

[fm6]

I downloaded one and tried to understand it, but the 'claims' section (arguably the most important part) is made up of utterly incomprehensible patentese, and I can't afford to hire a patent attorney to help me understand it.

At one place I worked, our lawyers urged developers not to read patents. Makes it harder for them to defend you.

If this project is a commerical one, and you can't afford to provide proper legal protection for your product, I'd recommend abandoning it -- there's no way you'll ever make a buck on it. On the other hand, if you're doing an open source project, I'd recommend that you just go ahead and do it, and not worry about legal issues. If your product's any good, then it will develop a following that will help you fight any patent infringement suits. Remember, the patent holder has to show that you're infringing, and that his patent is valid.