Which means that someone like me can't possibly do it. Suppose the fee were one millionth of a Euro per copy. The total amount of money involved, I might have in my pocket now, but I can't possibly fulfil that license 'cause I can't count the copies. If it's free software that means that any of you can make more copies. If I put restrictions on you, if I force you to tell me, it wouldn't be free software anymore.

Now, it is possible for a patent holder to offer a license for a lump sum, but when they do, it's usually for a large amount like $100,000. Often they want a lump sum and a fee per copy. We just won't be able to do that.

So, this is the alternative to getting a patent license. Sometimes possible, usually fairly easy if you're IBM or Microsoft or Nokia, not very easy for smaller organisations without paying. The third possibility is to challenge the validity of the patent. Now in order to do so, you need to have an argument to make, which means you need to present evidence that the idea was already known before a certain date. That means, in effect, that the dice were rolled sometime years ago and if you can find proof that they came out in your favour, you have an argument to go to court with, if you can afford the cost of this.

A few years ago Qualcomm was a defendant in a software idea patent lawsuit, and lost, and had to pay $13million of which $8million went to pay for lawyers on both sides. So it's expensive, somewhat, it can turn out that if you're not rich then a probably invalid software idea patent is a very dangerous weapon to be attacked with.

I should make it clear that not all software idea patents are absurdly trivial. I've mentioned a couple of those, but I don't think LZW is trivial. It's an algorithm that wasn't obvious. But, nonetheless, patenting it has done harm. And public key encryption was a brilliant idea, but patenting it has done great harm. And abbreviations in a word processor, I wouldn't say that's brilliant, but I don't think it's trivial either. Patenting it has done nothing but harm.

So these three options are possible, and each one is possible or not in any given case based on different causes, which means, sometimes, none of them is possible, and that means your project is dead. But, in fact, people don't really usually try to look up the patents before they do something. The reason is the penalties are worse if you knew about the patent; so it's better not to know <laughter>. What people actually do is they close their eyes and they go. It's like crossing a mine field. At each step probably nothing happens <laughter>, but you've got a lot of steps to take if you're developing a substantial modern program.

But, there is an intelligent question we can find if we excavate under that silly question, and that is: "are there relevant differences between fields that have implications for proper patent policy in these various fields?". And there is one. Namely, how big and complicated is each product? How do patents relate to products? And that's different from one field to another.

We have in our minds, a myth, a mythical picture of the patent system, which is that when you design something, there will be one and only one patent on that design, and you, the designer, will get it, if it's a new design. Well, that may have been how it worked for mechanical devices in the 1800s. It's not that way now. But different fields are further or, for [that] matter, closer to that. The field that's closest to that is pharmaceuticals. A few years ago it really worked exactly that way. That the patent, the patents in pharmaceuticals would cover the entire chemical formula of a drug. So if you developed a new drug, there'd be no patent on it, and you the developer would be the only one with a patent covering that drug. I'm told that this is not true anymore. Nowadays, if you develop a new drug, there may be an existing patent covering it. So it's moved away from this mythical picture, but it's not, it's still closer than any other field. And then there are the various other fields of physical engineering. The other extreme is software.

In software we make things that are very big and complicated. They have lots of different features and lots of different methods going on inside. Which means that in one program, we're combining lots of different ideas that might be patented already by various different patent holders at the same time.

Now, why is this. This is no accident. It's not just a historical outcome. There's a fundamental reason for this. The reason is, that in software were making designs out of combinations by putting together idealised mathematical components. In all the other fields, people have to deal with the perversity of matter, 'cause they're making physical things. And the matter does what it does, and if it isn't what you expected, tough luck. So they have to deal with lots of problems, which we in software don't ever face.

For instance, if I put an if-statement inside of a while-loop, I don't have to worry about whether the voltage drop through the while-loop will be so much that the if-statement won't get enough voltage and it won't work <laughter>. I don't have to worry that as the while-loop goes around, the if-statement will shake and eventually come loose <laughter>. Or I don't have to worry that it will go around even faster and this if-statement will generate radio frequencies and induce wrong values elsewhere in the program <laughter>. I don't have to worry that corrosive fluids will get between the if-statement and the while-statement and eat away at the contact between them and eventually there'll be so much voltage drop that the if-statement won't work anymore. I don't have to worry that the if-statement will burn out. I don't have to worry about how I'm going to sink the heat dissipated by the operation of this if-statement. I don't have to worry how, about how, if the if-statement does crack or burn out or corrode or whatever, about how I'm going to remove it or put in a replacement if-statement. In fact, I don't have to worry about how, each time I build a copy of the program, about how I'm going to put the if-statement beside the while statement in that copy. When you design a physical product, often, really, the job is designing the factory that's going to make it. But we don't have that issue in software. If I want to make a copy of a program, I type "cp", or maybe I type "dd", you know, there's some copy command and it'll copy any program exactly the same.

There's so many problems that we just don't have to deal with, 'cause our components aren't physical things, they're mathematical ideals and they have definitions, not just models. So they do exactly what they're supposed to do.

So, what does this mean? I presume that the intelligent spectrum of people in the software field is the same as the intelligent spectrum mechanical or electrical or chemical engineers. But their fields are harder. Our field is easier. So what do we do? We push to the limit. People push all their skills to the limit. If you make your job big enough, eventually it gets hard. And that's what we've done. We develop programs that are very very big, bigger than other things people can design when you measure in terms of how many components there are.

A program with a million different parts in its design, would be a program with two or three hundred thousand lines of code, I guess. 'Cause each line has several components typically put together. And this is something that a few people can do in a few years. This is normal. This is not among the biggest programs. A physical design with a million different parts, and I mean, not repeating subunits, many of them, but a million different parts in its design, counting repetitions only once, that is a mega-project. That's at the limit of human ability.

So what does this mean? In software we can combine more different ideas in one program than people can do in any other field. And that means that the patent system causes us more gridlock, more of the land mine effect, than in any other field. And the result is that software patents obstruct the main work of software development.

The main work of software progress is not getting ideas. If people are working on programs, they're going to have ideas. And they'll just immediately implement these ideas. You know, you have what you think, I could make this feature in my word-processor, so you do it. You don't have to do any research, you just have to write code. And so, having people working on software produces ideas for what you can do in software. But we also have universities where lots of people are actually getting paid, often with government funding, to come up with ideas.

To have a, to have an artificial system intended to promote people having more ideas by obstructing software development is self defeating. It's going to result in fewer ideas, not more. Software patents are an obstacle, even to progress in software. Now this might seem unthinkable. The advocates of software idea patents ask you to take for granted, no matter what harm or trouble or nuisance these patents may cause, they must be promoting progress and surely that justifies whatever, whatever trouble they impose on you. But this is not so. You can look at the economic modelling to show it's not so.

In www.researchoninnovation.org/patents.pdf, I warn you, it's rather mathematical, but it shows how, in a field with incremental innovation, a patent system can retard progress. The assumption that they want us to take for granted is false. And clearly incremental innovation is normal in the software field.

The same site has another paper showing that, in fact, in the US, empirically speaking, after software idea patents were allowed, there was a decrease of investment in software R&D, because the money was transfered into patenting instead.

But there's an even more important reason to reject software idea patents. Because patents in other fields are industrial regulations on a few specialised businesses. You know, patents on automobile engine design, how many companies do those restrict. You need to have a lot of money to set up an automobile company. But software idea patents restrict everybody with a computer. That's a large fraction of the citizens in a modern wealthy country. And when, so, you can't judge these by the same criteria. To talk about an industrial regulation is an economic issue. When you are restricting what people, what the citizens can do with their own computers that's not just an economic issue. That's an issue of people's rights.

Among those users, in addition to the citizens, you also find businesses. A large fraction of businesses use computers these days. And software idea patents will tie up all those businesses in a new form of bureaucracy, which is just going to make trouble for them.