Review: Intellectual Property and Open Source

The book starts off with a Lessig-like comparison between code intended for computers and legal code. The legal code base is not as clean as one might like:

Mr. Lindberg is clearly trying to write for programmers, so code-based analogies abound. Patents are like regular expressions - quite powerful in the technologies they can match, but you never really know what they will catch until you try them. Patent documents are structured like ELF program headers, and the patent system as a whole is a sort of memorization scheme (we get a Python Fibonacci number generator as an example here). Contracts are like a distributed version control system - they let anybody create their own, localized law. And so on.

Roughly the first half of the core part of the book is dedicated to explaining how the four main branches of intellectual property (patents, copyright, trademarks, and trade secrets) work. The chapter on the patent system notes some of the problems with software patents (in particular, the industry's use of oral tradition and the late recognition of software patents makes most prior art invisible to investigators), but, to a great extent, it seems to be written for people who want to obtain patents, rather than those who feel the need to defend themselves against software patents. It might have been nice to get a treatment of the often-quoted idea that software developers are better off not knowing about patents because that way they cannot be accused of willful infringement, but that topic was not touched. There is also no talk of the Open Invention Network or any other efforts to protect the community as a whole.

The copyright chapter is a reasonably thorough treatment of the subject which notes how the scope of copyright has expanded over the years. The current situation is compared to an "allow by default" security policy where anything which can be said to have an expressive aspect gets copyright protection by default. Derivative works are discussed at length, leading to this interesting observation:

Just a few pages earlier, it is stated that joint ownership means that each author has full rights over the entire work and can do just about anything with it - like license it to others. A finding that the kernel was a joint work could lead to some unpleasant consequences; one hopes that Mr. Lindberg is not really saying that could happen.

The book mentions the abstraction-filtration-comparison test used by some courts to determine if one body of code is derived from another, but says nothing about how that test works. It would have been nice to learn a bit more, since that is an important part of how copyright cases are resolved in the US. Also nice would have been some discussion of the value of registration of copyrights.

The chapter finishes with this discouraging note:

The discussion of trademarks (compared to desktop shortcut icons) is pretty much as one would expect. The chapter is more concerned with obtaining and defending trademarks than balancing trademarks against the ideals of free software. There is not much to say about trade secrets, though the chapter does touch on what happens if unreleased code is incorporated into a free application. The author concludes that the open development process makes this kind of contamination less likely than with proprietary projects.

Next we move into a chapter on contracts and licenses which talks mostly about how contracts are formed and enforced. The book takes a strong position that all licenses are contracts; they are just a special form of contract which grants permission to use some sort of intellectual property. The other point of view (that licenses are distinct from contracts) is touched upon, but dismissed this way:

Later on, the author refers to the GPL in particular as a "Schrödinger's license" with a currently undetermined nature; it might be "just a license" after all. Clearly there is some confusion on this point. It is worth noting that the book predates the appeals court decision in the JMRI case, which makes the "it's a license" interpretation far more likely.

There is a chapter on the "economic and legal foundations of open source," talking about how the community works and, in particular, how free licenses work. There is little here which would be new to most LWN readers, but it might be good to hand to the corporate legal office. Speaking of that office, the next chapter talks about how to contribute to a project without getting into trouble with your employer. There is talk about proprietary information agreements, some important cases (including the Medsphere case, which you editor wishes had been more prominent on his radar), works for hire, and so on. The key advice from the author is to disclose your work and your ideas to your employer as soon as possible - preferably before beginning employment. This is a chapter that many free software developers should read.

Chapter 10 is about choosing a license for a free software project. The importance of the topic is stressed - as is the importance of not trying to write one's own license. The author recommends that most projects should limit themselves to considering the 2-clause BSD license, the Apache license (v2), the Mozilla Public License, the GPL or LGPL (versions 2 or 3, though GPLv3 is said to be "a better and surer foundation for future development"), or the Open Software License (v3).

Chapter 11 is about the issues involved in accepting patches from others. The author strongly recommends using some sort of signed contributor agreement or even copyright assignments. Getting assignments, he says, allows for "unified legal control," ease of relicensing, and the ability to do commercial licensing. It's probably good advice for a strongly corporate-controlled project, but may not fit with more community-oriented projects. Unfortunately, the book perpetuates this particular fiction:

And, to make it worse:

There are a few problems here. No single entity owns the entire Linux kernel, but that code has been quite vigorously defended against some strong legal challenges. (It is interesting, actually, that the author managed to write this entire book without mentioning SCO once.) Kernel developers have also been able to enforce the kernel's copyright numerous times. Meanwhile, a quick look at the BusyBox code is sufficient to turn up copyright assertions from far more than two developers. Unified ownership of a code base may be the right thing for some projects, but the reasons cited here are clearly not applicable.

That complaint notwithstanding, this chapter does contain useful information that should be kept in mind when accepting patches from others.

Chapter 12 is about the GPL in particular. There is a lot of talk about just what is a derived work under the GPL - does it apply to kernel modules, for example? Unfortunately, the answer is "we just don't know." So, while the chapter is a reasonable summary of how the GPL works, once again there will be little there for most LWN readers.

Chapter 13 gets into reverse engineering, providing a quick overview of how it can be done without getting into trouble. According to the book, reverse engineering is generally allowed in the US, even to the point of disassembling proprietary code to learn its secrets. There are a lot of pitfalls, though, and the DMCA changes the game significantly. This chapter is a good starting point, but anybody wanting to do reverse engineering in the US will probably want to learn rather more than what is on offer here.

The final chapter talks about the creation of a non-profit corporation to own and/or manage a code base. It's mostly about what's required to create a corporation and keep it in good standing. This information may be useful to some, but it seems a little out of place here. After that, there are 80 pages of license lists and the full texts of a number of free software licenses. Perhaps it's useful reference material, but it's all easily available online; it's not clear that dedicating nearly 25% of the book to this material was necessary.

The subtitle of this book is "a practical guide to protecting code," which makes one omission especially striking: there is not a word on how a project should deal with license violations. There is, by now, a fair amount of collective wisdom on how such problems should be approached, but it has not been collected here. There's also little talk on protecting projects against software patent problems, no talk of patent pools, and no talk of related issues like the Microsoft/Novell deal. Software patents have cast a big shadow over free software in the US, but the issue is not really touched upon in this book.

It is also worth noting that the book is very heavily based on US law, and the author never attempts to look beyond the border. Certainly it would never have been possible to cover intellectual property law worldwide, but this narrow focus is still a little puzzling. Much intellectual property law in the US is based on international agreements, so an understanding of those agreements would help with the larger picture. A mention of Berne Convention would not have been out of place, for example. The other problem is that free software tends to have little respect for borders; there are few projects which are limited to a single country. Even if a project is based in the US, the existence of contributors elsewhere in the world is almost certain. Free software is a global phenomenon; it is not sufficient to think about US law alone.

Despite these complaints, your editor has to say that this is a valuable book. It covers many of the basics of the law in a much clearer way than has been done before. Anybody who manages or contributes to a free software project (in the US, at least) should be familiar with the concepts discussed here. And certainly all of the people peppering the net with IANAL posts would be better informed after reading Intellectual Property and Open Source. This book should bring some light to a complex but crucially important part of the legal code which governs our actions, and that is a good thing.