Intellectual Property and Open Source

a practical guide to protecting code

The Open Source movement makes software available free for people to use or even to pass on to others. This flies in the face of normal commercial practice, where people jealously guard their intellectual property rights. Traditional laws support these rights – so when new open source projects come into being, often as a result of work done collectively, it can be difficult to disentangle issues of ownership and control. This is equally true for the written word as well as for digital code.

Van Lindberg’s new book is an amazingly thorough guide to the whole business. He explains the legal niceties without resorting to too much jargon, and supplies practical support materials in the form of sample licences and agreements. The first part of the book has eight chapters giving an introduction to intellectual property law, then the second part is six chapters offering an intellectual property handbook for developers, particularly those working in the field of open sources.

He warns that it’s a book of general principles, not specific advice, for the very good reason that cases of copyright, patents, and intellectual property rights are very case specific. Nevertheless, he does discuss lots of instructive individual cases, and I imagine that anybody with a need to know in this complex field of legislation will find what he has to say both instructive and chastening.

He explains the law on copyright, patents, and inventions by comparing it to computer programming, which it turns out to resemble remarkably closely. One new ruling (or code) is bolted on to that which already exists, and the whole statute grows by a process of accretion.

As a layman, it’s interesting to learn that you cannot patent an idea – no matter how original an invention it might be. You can only patent the proof that it can actually be realised and turned into something useful. And even the term ‘useful’ is coded – as his example of a patent dust cover for dogs illustrates. It can be used – even though the idea itself is quite barmy.

On Open Sources he explains that software is free as in ‘free speech’, not ‘free beer’ – but this distinction will mean little to everyday users who are happy to download a program that works well without having to pay for it.

The picture becomes clearer when he explains the success of various Open Source projects – FireFox, Linux, Apache – many of which have formed the basis for successful business ventures. The software itself is free to use and distribute, but companies have legitimately made money from offering services in support of its use.

He’s very good at explaining the complexities of rights developed whilst you are in somebody else’s employment. In brief, you’ve very little chance of succeeding, and he even includes some tragic cases of people who have lost lawsuits on works patented before and after they have been in somebody else’s employ. If there’s a barely-hidden message here, it’s ‘stay away from legal contests’.

As a rule, employees should assume that any intellectual output they produce whilst employed will be considered proprietary information and subject to the company’s proprietary information agreement (PIA). It doesn’t matter if the invention is in a completely different area of technology, or completely unconnected with your work; it still may be covered.

Even if you wish to make your work available free to the public, there are a number of different licenses to choose from, offering a sliding scale of ownership and control – such as public domain, open source, and reciprocal. The general advice he gives is not to attempt writing your own.

One thing is for certain. It’s potentially a very complex area both technically and legally. The law works on a basis of precedence, and you can bet that if a legal tangle emerges, it will be judged on similar occurrences in the past, even though your technology might be brand new.

All sorts of additional complications arise because of the special nature of software development. Does the author of a ‘patch] (a small-scale solution to a problem) have copyright over it when it is added to a big project? Can you combine two open source programs and claim copyright over the result? What about reverse engineering?

I would have welcomed a glossary and a webliography, but it’s to O’Reilly’s credit that they publish books like this – because although it might have a fairly limited readership, it raises lots of important issues and simultaneously makes available the information for dealing with them.

Buy the book at Amazon UK