A look at the good and bad of four proposed methods for fighting software patents.

1. Prior art
2. Patent pools
3. Our licences
4. Lobbying

1. Prior art

The plan: build up a catalogue of ideas that exist in free software projects so that when a free software developer is threatened with patent infringement, we can point out that the patent is invalid because we thought of the idea before the patent was filed.

Effectiveness: Low, potentially negative. If the database is publicly viewable, people applying for software patents could use it as a guideline for drafting valid patents. They could see what they have to avoid, and write their patent application so that it doesn't overlap our prior art. If the database is not publicly viewable, the negative effect will be avoided, but the potential gain is low. Most patents are for ideas that we can't prove we already thought of.

Richard Stallman recently explained this in an article about OSDL's implementation of this idea. There was also a good article on CNet about Stallman's essay.

2. Patent pools

The plan: Encourage holders of software patents to make an agreement not to sue free software users.

Effectiveness: Low. Three reasons:

1. The contributors may be mostly friendly companies - in which case the pool will contain patents that would not have been used against us anyway.
2. The contributors may have already cross-licensed those patents with the other large patent holders - in which case, the contents of the pool will not be available for us to use in counter-litigation.
3. "Patent trolls" - parasitic companies who write no software and make their money from buying patents and charging license fees from people who are writing software - will be wholly unaffected.

3. Our licences

The plan: Add terms to our licences saying that if you bring patent litigation suit against someone for using the program, you lose the right to distribute the program in future. Many software licences developed from the late-90s onward have attempted this. GPLv3 attempts this too, to some extent.

Effectiveness: A bit good. This action cannot solve the problem - it can only protect people from patent litigation in the case where the patent holder is also a distributor of the software whose licence contains such a clause. So this is a good idea, but it's not enough on its own.

4. Lobbying

The plan: Try to influence legislation, inter-governmental treaties, global agreements, and patent office policy so that software patents are neither approved by patent offices or upheld by courts.

Effectiveness: Good, but hard work. This action can potentially solve the problem, and it has proved practical. See FSFE's software patents page, FSFE's WIPO page, and my August summary of software patents in the EU. No other action has the potential to completely save free software users and developers from patent litigation.

Oct 3rd: http://DRM.info was launched today. The aim is to make an information portal where people can see real world uses of DRM, how it affects a variety of sectors, and who is together in rejecting it.

Here's the press release. If you want to raise awareness of DRM, probably the easiest thing you can do is to link to this site and point people to it. DRM.info is a collaborative effort. FSFE also has its own DRM page.

There seems to be almost unanimous dislike of DRM in the free software community, but people are less unified on how to tackle it. One suggestion is that we can defeat DRM by not buying DRM'd hardware. This is often called "vote with your feet", but it is not enough. Relying on it alone would be certain failure.

People who put forward this idea usually mention "free market", but they ignore that people can participate, not just purchase things, in the free market. Here are four hurdles to tackling DRM by "vote with your feet" tactics:

1. Not many people are aware of DRM, and not many people see the value of their freedom. DRM.info is an effort to address this.
2. Purchasing decisions are not very granular. They lump together varied aspects such as price, style, compatibility, recyclability, and respect for freedom to control the software. This makes it hard to send a signal to manufacturers since a drop in sales could be attributed to one of many factors.
3. The options offered to purchasers - what you can "vote" for - are set my a someone with a special interest. If the hardware manufacturers have an interest in locking down users with DRM, they can stack the options to make it inconvenient for users to choose DRM-free hardware.
4. Those with an interest in locking down technology users can leverage other markets, such as the entertainment market. Monopolies or cartels can be set up so that the public's technology purchases also decide what entertainment they have access to.

To effectively defeat DRM, we must not only reject DRM'r hardware that locks us out, but we should also participate in the drafting of related legislation (FSFE does this), participate in policy forming, participate in international treaties (FSFE does this too), and use our licences to say that our software cannot be a stepping stone for using DRM against people (GPLv3 does this).

Some people have expressed a worry that if we are unfriendly to Tivo, as GPLv3 is, they will stop contributing to our projects. This may be true, but we never relied on their contributions, and their practice of preventing tinkering is losing us contributors too. Fewer tinkerers equals fewer contributors.

The British Library seem to understand the problems of DRM. (It's unfortunate that they used the term "Intellectual Property". That term works against them by encouraging oversimplified thinking.)

Georg Greve also has a blog entry on DRM.info.