Property and Open Source
Free software inevitably runs into the body of law known collectively as
"intellectual property." Many developers do their best to avoid the legal
side of things whenever possible; others seem to like nothing better than
extended debates on the topic. Regardless of one's own feelings in
the matter, the fact remains that the legal system exists, it affects our
lives, and that we can only be better off if we understand it. To
that end, O'Reilly has published
by Van Lindberg.
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
It gets worse: every line of the legal code was written by
committee, and almost every line of it has been patched by a
later piece of legislation or modified by a court. Indeed, IP law
is rooted in a more than 200-year-old codebase. Is it any wonder
it's a mess?
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
The copyright complexity of open source software systems is in
large part due to the rules surrounding derivative works. A large
project like the Linux kernel has hundreds or thousands of
authors... As a result, nobody really owns the Linux
kernel; the best description of its status is that it is owned
jointly by its developers.
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:
Under a legal realist analysis, any use of copyrighted material
that was objectionable or questionable would be struck down as
infringing. Non-objectionable use of copyrighted material would be
allowed only if the political and economic interests in support of
the use were more powerful than the political and economic
interests against the use. Unfortunately, this is, in my opinion,
the best guide to the outcome of any future copyright case.
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:
The "pure license" interpretation favored by Eben Moglen makes the
enforcement of the GPL much easier, there is no need to consider
offers, or acceptances, or the other particulars of contract law
discussed in this chapter. Unfortunately, it is impossible to say
for certain if a particular agreement will be considered a license,
a contract, or considered both a contract and a license. It is a
tricky and case-specific question focused on whether the agreement
includes a "restriction on the scope" of permissible action or
whether it is simply a "covenant" to act in a certain 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
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
In order to represent a code base against legal challenges, a
single entity must have copyright ownership of all the code in that
And, to make it worse:
A good example of this is the BusyBox project... When people found
out that BusyBox was being distributed in proprietary products
without adherence to the license restrictions, the Software Freedom
Law Center (SFLC) was able to file suit on behalf of the project
because there were only two people that owned all the copyrighted
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
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.
to post comments)