Freedom from Fear: Patents and programming

Written by Harald Alvestrand for the A2K meeting in New York, June 13-14 2005
His personal opinion.
Last updated: June 11, 2005

The patent system was invented to encourage invention and creativity, by making a bargain between the inventor and society: "you tell us what you invented, and we give you an exclusive right to grant licenses to practice it for a while". This was intended to let an inventor benefit from his invention, while allowing other people access to the information on how it was done - allowing others to apply this knowledge in other fields, thus stimulating invention.

The way the patent system is used today, the collected body of patents poses a significant business risk to anyone operating in any field of technology development; because of the economics of software production and distribution (very low physical investment needed for many inventions, zero or very low copying and distribution costs for "pure" software), this is felt to an extreme degree in the area of software programming.

Patents and products

When one makes a software product, the product will embody certain algorithms, procedures and functonality.

Under the current regime, these elements may or may not be covered by patents. They may also be covered by patent applications, which are not publicly available in the first period after their initial filing, and may be significantly modified by the time they result in the issue of a patent -often multiple years after filing.

The software implementor (whether he is a person, a small company or a large company) has no way of knowing for certain whether or not there are patents that are applicable to his product. Patent searches are not guaranteed to find everything, evaluating all the patents returned for a wide patent search is a significant undertaking, and even if the patent searcher determines that a patent is not applicable, the patent holder might not agree.

The usage of a patent against a product orginally seems to have been one of two possible actions:

• The patent holder could refuse rights to use a patent, thus keeping a monopoly
• The patent holder could license a patent, thereby getting monetary remuneration

In the current world of fast-moving innovation, unclear patents and large patent portofolios, there are, however, multiple other things that can happen between a patent holder and a product maker - depending on what the aims of a patent holder are, and what resources are available to the product maker.

Some instances:

• A patent holder wishes to delay competitors' entry into the market. He announces that he has a patent on relevant technology, and will license on reasonable terms - but will demand significant damages from anyone who ships products before having a license.
  This is likely to cause large companies to try to negotiate an agreement, and may cause small companies or freeware developers to give up on the market.
  This tactic is likely to succeed, largely irrespective of the merits of the patent; if someone tries to bring it to court, the desired outcome for the holder (delay) is likely to have been achieved long before the case can be brought to trial.
• A patent holder wishes to promote technology A over technology B. He announces that he is a nice guy, and will license all his patents free of charge for use in technology A; in an unrelated announcement, he announces that he is interested in negotiating terms on the patents he holds that he believes covers technology B.
• A patent holder wishes to gain access to a patent held by the product maker. He announces that he has a patent covering technology important to the product maker, and indicates that he is interested in entering into a "portofolio swap" where the companies exchange mutual rights to their patent portofolios.

The power that a patent holder achieves in these kinds of transactions is important enough in practice that most companies now spend resources on figuring out whether stuff they think of can concievably be considered a patentable invention - resources that are NOT spent on product development.

Patents and standards making

Standards are, in many ways, just an intermediate step in the cycle of product development.

They describe uniform methods, processes and formats that multiple product makers will implement. If a patent holder manages to find patents that apply to a stanardized technology, the patent holder can then exercise the leverage above over all the implementors - and where communications standards are concerned, there is not even a need to figure out whether or not they use the patented method; the product makers list their standards conformance in their sales literature.

(This can be a serious cash source for popular standards, even at low prices; it's rumoured that the prevalence of USB over Firewire was heavily influenced by Firewire's patent licensing fee of one dollar per port.)

This excessive leverage has led many organizations to make various rules for how participants must treat patents they hold on standards being developed - promising to license them on specific terms such as "royalty free" (W3C), contributing them to a "patent pool" (3GPP) or just disclosing the existence of the patent before standardization is complete (IETF).

This approach has a few limitations:

• Companies often refuse to disclose how a patent applies to specific technology; this makes it hard to know whether or not a change to the standard will render the patent irrelevant.
• Companies often refuse to disclose the text of a patent application; this makes it impossible to evaluate whether or not it is in fact relevant to the standard.
• Rules can be binding only on participants that choose to follow the process; there is no possible binding on people or companies that do not participate.
• Even if everyone is "playing in good faith", there is no way to guarantee that there isn't a relevant patent "somewhere out there", held by someone who will demand payments - in this way, the standards developer is much in the same situation as a product developer.

The scary prospect of finding a patent covering a standard in the hands of an unscrupulous organization has led to this scenario earning its own idiom - the "submarine patent" - conjuring up the image of an invisible, undetectable enemy that will suddenly surface when you least expect it - pointing weapons at you and demanding ransom.

The critical standards - TCP, IP, X.509 certificates, HTTP and so on - will survive despite the fear, and people will invest the necessary resources into investigating the patent claims and calling them bogus, or pressuring the owning companies into licensing them on acceptable terms.

It is the small stuff that falls by the wayside - when someone announces that a patent exists relevant to a standard that is of positive, but limited, value, many developers will just look at it, say "not worth it" and walk away.

This is not good for society.

Patents and the individual Free Software developer

Patents are an issue for all kinds of software makers - whether they make sold software, licensed software, embedded software and free software. But there are a couple of specific aspects that affect the classical free software developer (here used in the sense of an individual who programs outside of a regular organization - a large organization that occasionally gives away software is in a different situation).

• The Free software developer does not have an income stream from sales. Therefore, he cannot make a reasonable deal on "percentage of sale price" licenses.
• Many free software developers have very limited resources. This means that if faced with a threat of litigation where the illogic is not obvious enough to make a public "cause", they have no alternative but to give up.
• While organizations that are after money will likely not go after free software developers (who have none), organizations that feel free software as a competitive threat may very well use patents to either block free developers outright or require licensing terms that they know will be unacceptable.
• Free software developers rarely have their own patent portofolios that they can use in a "portofolio swap".
• Free software developers rarely know how many people use their products.
• Free software developers are mostly motivated by pleasure in doing - fear, uncertainty and doubt are very powerful disincentives for this type of developer.
• Free software developers who work alone are personally responsible for what they do.
• In some jurisdictions, knowing about a patent increases liability - so it may be reasonable for a developer not only to refuse to search for patents, but to actively avoid hearing about them.

All this adds up to a situation where free software people will, as long as they can, avoid thinking about patents - and if patents are asserted against a specific area of technology, they are much more likely to try to get their work done in nonpatented ways than to take out licenses.

The chilling effects of this fear, uncertainty and doubt should not be underestimated.

Fear mitigation strategies

As should be clear from the above, there is indeed reason to fear being caught in a situation where one is deemed to infringe patents. And it should also be clear that the fear is actually a greater cause of harm than the specific instance.

Strategies to lessen the fear include those listed below, ordered by the size of the organization that has to take them - from the individual to the world society.

• Individual: Publish early, publish often!
  An idea that is published can't be patented by someone else later. However, it doesn't prevent anyone from patenting minor variations on the same theme. Note that practicing an invention doesn't count as publication!
• Individual: Run away from minefields!
  Stop working on stuff where you know there are patents around. Irritating, but effective.
• Organization: Get more patents!
  Patents are ammunition in the patent cold war. But - they work mostly against people who are trying to deliver product too. A company that only holds patents isn't afraid of yours.
• Organization: Document your process!
  If you can prove that you were doing something before a patent was applied for, you can invalidate the patent. Of course, this is paperwork - which developers hate. But necessary for other reasons, too.
• Organization: Adopt a "no first strike" stance
  Some organizations have said "we will not sue anyone over patents we hold unless they sue us first", or variants thereof. This allows people with no intent of suing to use the patented technology without fear of being sued from this particular direction - however, details matter.
• Standards groups: Mandate disclosure!
  You can't find out what people who are not present hold. But presumably, the standardizers are the leading companies in your industry.... and if not, you'll find out :-(
  Licensing terms are critical to understanding the risk that a patent imposes on implementors. Traditionally, standards groups have been hesitant to demand them, for various reasons. This could change.
• Standards groups: Mandate licensing!
  This lessens the uncertainty of the users even more. But again, ineffective against the outsider.
• Industry groups: Patent pooling
  This is an idea that has come up at times, but has some trouble with competition rules - that organizations would put parts of their portofolio of patents "in trust", saying that these could be used freely for some purpose, but that anyone suing anyone over people practicing this purpose would immediately lose rights to all patents in the pool. Could be effective - but - the details matter.

The actions taken by individuals, organizations, companies or standards groups are limited in that they can make no decision that is binding on a nonparticipant. However, national governments and treaty organizations are not so limited. Among the actions they could take:

• Limit the scope of patentability.
  Fewer patents means fewer submarine patents, and clearer rules for what can be patented means knowing more easily whether patents may exist in an area. The most often heard call in this area is "no software patents". However, drawing boundaries is a very difficult proposition, as all who have worked with attempted definitions have learned!
• Reduce the number of patents
  One reason why we fear patents is the sheer number of them, which makes it extremely difficult to search them. Rules aiming at reducing the number (such as instituting a yearly maintenance fee for keeping a patent on the books) could lessen the fear.
• Harmonize patent rules
  Adding to the problem of patents is their inhomogenous nature across nations - something that is found unpatented and/or unpatentable in one country may well be patented in another.
• Mandate disclosure
  For stuff clearly in the public benefit, like open standards, one could imagine a "speak now or forever hold your peace" procedure - stating that after a certain procedure was concluded, nobody could demand royalty payments or that someone stop practicing a specific technology, unless the patent was previously disclosed.
• Limit the size of the economic risks
  In the current regime, people can, and will, demand any amount of remuneration for infringement of a patent - up to and including the entire market value of the infringing company. Capping the possible remuneration, and removing the ability to demand that the infringing activity stops until a settlement is reached, would change the risk profile from "unbounded risk" to "bounded risk" - which is much easier to live with.
• Mandate licensing
  One particular version of the risk limiting above would be to declare that under some conditions, some specific payment schedule is the maximum that can be demanded, and that payment of this schedule absolves the payer from all other obligation under the patent.

All of these methods have been suggested. Few or none of them have actually been enacted in any jurisdiction - and in order to be effective in the current globalized environment, it's possible that the only way to introduce them is to introduce them through a world-wide treaty such as the proposed A2K treaty.

But - if we do nothing, the situation will not improve.