Software patents and defensive portfolios

A criticizes the way patents are being granted, beginning with a contrast between the rule and the practice. Patents are supposed to protect nonobvious inventions. Yet the author gives an example that seems obvious to them: translating between an Internet address and a telephone number. We don't need to become experts on that technology to follow the argument. Its role is to illustrate what the author regards as an excessively permissive patent system.

The next paragraph explains the ideal. If companies cannot agree on a license, a sufficiently narrow patent should leave room for a competing invention that does the same job without violating the protected invention. That's inventing around a patent. The complaint is that patents have become so broad that this route is practically blocked. A is not arguing that no invention should ever receive protection; the stated ideal still includes patents.

Then comes the defensive arms race. A large company acquires hundreds or thousands of patents so that it can threaten a countersuit if another company sues it. Imagine two companies each holding a collection of claims against the other. Starting a lawsuit now carries a risk of being sued back. The stockpile is useful as a deterrent, even if the company would rather avoid the fight.

That also explains the danger of staying out. A company without a portfolio lacks the same threat to use in response. The author criticizes the system that creates this pressure while still treating a defensive portfolio as sensible within that system. Those positions can coexist.

Software creates an additional problem because a product combines many components. Patents on those pieces can make infringement difficult to avoid. Think of a developer assembling a product from many ordinary-looking features: recognizing every potentially relevant patent could itself become prohibitively expensive. The obstacle is not just unwillingness to pay license fees. Even a willing company may be unable to identify and license everything its product touches.

A's main point: Overly broad and questionable patents burden technology companies, especially software developers, and pressure them to amass defensive patent portfolios.

B shows us a company living with that problem. It opposes software patents because it believes they impede innovation and conflict with open-source/free software. But announcing that position does not make other companies' patent portfolios disappear. The world still permits patents, and large holders can use questionable claims and expensive litigation against other developers.

So the company is adopting the very defensive strategy A described. Its own portfolio gives it a response to others' claims. The reluctance matters: the company has not decided that software patents are good. It distinguishes the system it would prefer from the precautions it considers necessary now.

B's main point: Although the company opposes software patents, it is reluctantly building a patent portfolio to defend itself and support the open-source community under the existing system.

Together, we have a general problem and a participant's practical response. B does not solve the underlying problem or contradict A by using patents. Its policy illustrates why someone can oppose a system while still protecting themselves against the risks it creates.