Thursday, July 26, 2012

Software patents - a reasoned perspective?


Most software developers understand and embrace the idea of copyright. They like the idea that when they write something in code, that it is their property. Whether paid for by their boss or owned themselves.

Next they love the fact that if they give that code away for the common good, for example to an open source project, then they have done something of significance. But again, their work can not be abused because they have handed the copyright to the open project and who ever uses that code must contribute to the code and give the project recognition... why?

Because of copyright.

Copyright is protection law. It stops people from just taking other peoples work and using it for their own gain.

Some people don't care. They are happy to give away their code. Fine. But in the business world, businessmen do care. Making software costs money. Frequently it involves investors who want a return on their investment.

Companies want to own code thats important to them. Some code they strategically like to share but very few of the worlds big successes are based on giving away their work.

Now to patents.

Many people think of software patents as being simple and irellevant nonesense claiming ownership of ideas that are so obvious no one should get a patent for them... right?

Simple like a mouse trap... that simple right? Or a light globe... they've been around for over a century.. a vacuum and an element, simple right? Most things we use today have been patented in the past and the person who invented them got a chance to make money out of the idea, but eventually the patent protection expires and the idea becomes free for everyone to use...

If the value of a patent was its complexity, none of the major patents of our time would have been granted including Light globes. Patents are granted on their NOVELTY ie the newness and orginality of the idea at the time it was invented... NOT ten or TWENTY years after the fact when how it works is common knowledge.

I have experienced this first hand. When I first showed the Uniloc Try and Buy system to the General Manager of Word Perfect in Australia, he thought I was faking it... he just couldn't believe that the software could uniquely identify each computer as different.. he just couldn't get his head around it... but today the idea is used pretty much throughout the industry.

The fact is that patents protect methods of doing something or systems that do something... As more problems are solved in software rather than by physical machines it's totally appropriate that the method is protected independent of whether the solution is done in software or mechanically..

The pace at which software is developed is vastly increased over mechanical methods and the reuse of code/ sharing of code makes the area more complicated to navigate than a traditional manufacturing situation.. but to hamstring a great new way of doing something, because it happens to run on a computer is incredibly short sighted.

One last word.

Many people on twitter over the last few days have waxed on poetic about an inventors responsibility to build what they invent and patent. Speaking for myself, I like to get the thing working to prove it to myself and to everyone else involved in the project, but to say that I MUST TAKE THE THING TO MARKET is unreasonable. If a designer for Ford comes up with a great new body shape for a car, his job is only to do the clay model... not produce the car.

In fact most designers are terrible at engineering. Their strengths are in the wrong place.

Similarly, I am an inventor. Not an entreprenuer. Not a startup company CEO... an inventor. I invent things... then pass them on to others.

To do this I conceive of a new idea, I file a provisional patent if it's good enough, then I do a prototype for it and then go public with the invention to see if people like it or not... if they dont then it's back to the drawing board. If they do I try to work out how it should be commercialized and find the best person I can to pass the project on to.