I have a workbench in my garage where I keep some of my woodworking tools. While I am not a great carpenter—actually, I’m a pretty terrible carpenter—I still enjoy building things and working with the wood.
Although I have had my workbench set up for several years, I am always a little bit tentative when I first use a new power tool. I have learned to respect the fact that tools can be useful, but they can also be difficult or dangerous if not used correctly. To adopt a phrase used with some other tools, it can be too easy to shoot yourself in the foot.
This book is about a tool that we use called intellectual property—IP for short. We use IP to allocate value and create incentives in society. Just like many other powerful tools, IP can be very useful, but it can also be difficult to work with. You can (easily!) shoot yourself in the foot with intellectual property if you don’t understand how and why this tool works.
Unfortunately, there are few topics quite as misunderstood as intellectual property. Take a detour through the comments section of almost any recent Slashdot discussion. Many contributors begin their comments with, “IANAL, but...” (“I am not a lawyer, but...”) and then attempt to describe a legal principle, often incorrectly.
Part of my job each day is to work as a translator—translating from “lawyer” to “engineer” and back. For lawyers, I describe the interactions between computers, networks, and code. For engineers, I describe how to work with the legal system. My goal for this book is to raise the level of understanding and discussion about intellectual property and software. If we understand the function and rationales behind IP law, we can work with IP more easily, discuss it more fluently, and work together to improve it where necessary.
This book is meant to be a developer’s documentation for the legal system. As with any other tool, the workings and results of the legal system can seem inscrutable until the assumptions and processes underlying the code are laid bare. This book will unravel the United States’ intellectual property system by showing how it is composed of a number of interlocking, interoperating parts—patents, copyrights, trademarks, trade secrets, and some contracts, all of which act according to their own internal logic and demands. As much as possible, the minutiae of case names, Latin terms, and general legalese will be laid aside as implementation details; instead, the focus will be on the concepts and rules driving the overall system.
This book is designed to help anyone who interacts with other people through creative expression, particularly code. For example, those in commercial contexts will find it useful to learn how their day-to-day jobs brush up against IP law. Entrepreneurs will be particularly interested in who “owns” the code and the concepts behind their companies. Open source developers will find it a useful handbook to one of the more esoteric but important parts of their software project.
This book is not meant to be legal advice about what you should do in any specific situation. One difficulty with writing about intellectual property (or any legal topic) is that it is essentially impossible to be absolutely comprehensive. Legal disputes are generally fact-intensive, and superficially similar cases can lead to very different outcomes. Moving up to a higher level of abstraction allows individually distinguishable cases to coalesce into recognizable and useful principles. Generally following these principles should help to guide your understanding and keep you out of trouble. If specific legal issues do arise, however, it is best to consult a lawyer about your own situation.
This book can be approached as a story or as a reference manual, depending on how you want to use it. I would suggest reading it as a story first; later sections will build upon earlier explanations. After you have read this book in its entirety, individual chapters will be much more useful as you look for guidance on particular IP issues.
Different parts of the IP laws developed as responses to particular societal and economic problems; understanding those problems will help you understand the methods that IP law uses to accomplish its ends. IP laws have also been developed in response to (or in order to enable) certain business models. Understanding the business models will also help explain the use and expansion of IP law in society.
Thus, I will start by showing how economics, politics, psychology, and other disciplines all made their mark on IP law. I will show how each branch of IP law was designed to deal with different issues in slightly different ways.
After looking at each type of IP in isolation, I will then examine how they work together in real life. To do this I will bring in the concepts of contracts and licensing, and we will take a detour into open source/free software licensing as an embodiment of IP principles.
I will then present a series of situations showing the interaction of IP law with an idea as the idea moves from conception to realization and is communicated to others. These situations will be presented roughly in the chronological order in which they would occur in the development of the idea.
This book is also designed to work as a desk reference for those generally interested in intellectual property issues. The individual chapters on patents, copyrights, trademarks, and trade secrets should be useful to those who come into close contact with those constructs for the first time or after an extended absence. While I don’t pretend to tell you all you would need to know as a lawyer, I hope that those sections will also be of use when you need to work with lawyers to develop or manage IP issues.
The sections on open source (http://opensource.org) licensing are also intended to be of use to those becoming familiar with open source licenses or needing to pick a license. I will also spend some time dealing with the particular difficulties that can arise when using the GNU GPL.
Each chapter in the latter half of this book is written to work as a standalone response to a particular typical situation, even though those chapters will assume the base level of knowledge about IP law given in the first half of the book. Chapters in the latter half of the book will also have, as appropriate, sample forms, procedures, or language that can be used to address the legal situation presented. Once again, however, you cannot assume that any particular form, procedure, or language will be applicable and effective for your particular situation. If you have any questions at all, it is best to consult a licensed lawyer in your local jurisdiction.
There are many developers who bristle at the very use of the term “intellectual property.” The Free Software Foundation (FSF) places it among “Phrases that are Worth Avoiding” (http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty) and Richard M. Stallman writes frequently against its use on the grounds that it covers many concepts (copyrights, patents, trademarks, and so on) that have very distinct legal policies and histories (see http://www.gnu.org/philosophy/not-ipr.html).
Whether or not developers agree with the current legal system, however, those who build software are on the front lines of creating and using intellectual property. We are already in the workshop, using the legal tools provided by our society. We need to understand how they work, if only to avoid having our rights cut off.
As discussed further in Chapter 8, I am aware of the important philosophical differences implied in the use of the term “free software” as opposed to “open source.” Where applicable, I will use the correct term to describe how they are both socially and legally different. Nevertheless, because open source software is a strict superset of free software, I will generally use the more inclusive term when discussing legal elements common to both.
This book is divided into two parts. The first part, comprising Chapter 1–Chapter 8, is an introduction to intellectual property law. The second part, comprising Chapter 9–Chapter 14, is more of an intellectual property handbook for developers, particularly those working in the open source space. It is also applicable to those working commercially, but more often than not your experience with intellectual property will be constrained by your employer’s IP policies. The quick outline is as follows:
Chapter 1 introduces the four basic types of intellectual property—patents, copyrights, trademarks, and trade secrets, as well as the philosophical and economic foundations of intellectual property in general.
Chapter 2 and Chapter 3 dive into the law by examining the world of patents. The nuts and bolts of patent documents are explained in Chapter 2, and the process of writing and prosecuting (obtaining) a patent is examined in Chapter 3. This chapter also examines patent-specific issues such as priority, prior art, obviousness, and the difficulties inherent in software patents.
Chapter 4 transitions to the subject of copyrights. After laying out the history, protections, and limitations of copyright, this chapter will show how those protections both restrict and enable code sharing and licensing. Particular attention will be given to the definition and problem of fair use and the separation of functional and creative works.
Chapter 5 looks at trademarks and their role in society. The essential requirements for a trademark are discussed, as well as the process for obtaining, registering, and defending a mark. This chapter also discusses the permissible uses of a mark and the evolving area of trademark dilution.
Chapter 6 analyzes trade secrets as a mechanism for protecting knowledge and describes the ways in which trade secrets are relevant to today’s enterprises. This chapter also takes some time to talk about what can and cannot be considered a trade secret in a software company, particularly in an open source software company.
Chapter 7 brings together the different types of IP and shows how they can all interact within a single software project or product. I also examine the role of contracts and licenses in IP—what the IP law taketh away, a license giveth (at least sometimes). Contracts are discussed as the mechanism by which private agreements are given the force of law.
Chapter 8 turns to open source and places it in context. This chapter reexamines some of the social and economic issues associated with intellectual property, and then looks at how the mechanism of open source licensing provides a different way of addressing those concerns.
Chapter 9 starts with your idea. Who owns it? The answer to that question might be you or it might be your employer. This chapter discusses IP assignment agreements, covenants to not compete, and some of the other papers that you signed but didn’t read when you started working at your job. You will also learn about works for hire and how to determine who owns what.
Chapter 10 assumes that you will be releasing code under a source available, open source, or free software license. How do you apply a license to your code? The different kinds of licenses will be compared, and the specter of license compatibility will be raised. This chapter will also discusses dual (or multiple) licensing and the business models associated with different types of licenses.
Chapter 11 discusses what happens when you get your first patch. Who owns the patch? Do you have the right to use it? This chapter examines your right to accept and use patches and proposes several different alternatives depending on the level of formality in your project structure.
Chapter 12 is a dive into the specifics of working with GPL’d code. Building on the licensing discussions in Chapter 10, this chapter will talk about the special issues raised by the GPL. This chapter provides answers to some of the most common questions about the GPL, particularly with regard to linking.
Chapter 13 is an applied guide to reverse engineering. This chapter takes a look at some case studies in reverse engineering, and then provides a procedure for pursuing reverse engineering projects (mostly) safely. Along the way we will discuss the process of test-driven development as an effective method for managing reverse engineering.
Chapter 14 concludes with the process of formalizing your project by establishing a non-profit foundation to guide it. As you will see through the book, the “growing up” of a project is in part about the process of adopting legal formalities. As your project starts to acquire contributors and users, you and your users will want to establish the formalities that will keep your project viable for the long term. This chapter discusses the when, why, and how of incorporating a non-profit entity to hold and manage the intellectual property for your project.
A few appendixes are included with this book:
Public domain declaration
Simplified BSD License
Apache License, version 2.0
Mozilla Public License, version 1.1
GNU Lesser General Public License, version 2.1
GNU Lesser General Public License, version 3
GNU General Public License, version 2
GNU General Public License, version 3
Open Software License
When you see a Safari® Books Online icon on the cover of your favorite technology book, that means the book is available online through the O’Reilly Network Safari Bookshelf.
Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safaribooksonline.com.
I want to acknowledge the substantial help I have received on this book. First and foremost, I need to thank my wife Susie and my children for giving me many months of Saturdays and evenings to write. I also want to thank the many others who were also supportive of this project.
This book is considerably better because of the help of many good people at O’Reilly. My editor, Andy Oram, provided extensive feedback and assistance throughout the process; Isabel Kunkle was a model of patience as I worked (too slowly) to get my drafts into production; Amy Thomson provided valuable help copyediting and clarifying the text; and Mike Hendrickson was willing to take a chance on a slightly different kind of book.
I also want to thank the people who helped out as technical reviewers on the text. Matt Asay, James Grimmelmann, Leslie Hawthorn, Glyph Lefkowitz, Lawrence Lessig, Stephana Patton, Richard Salgado, Julie Steele, and Luis Villa all gave valuable feedback on earlier drafts. Nevertheless, all errors in this text are mine alone.
Finally, a disclaimer: I work for a law firm and I represent clients. The views presented here are mine alone and should not be imputed to my firm, any clients of the firm, friends, enemies, or anyone else. This book is not legal advice, is not complete, and in most cases omits technicalities and simplifies complex situations. No person should act, or fail to act, on any legal matter based on the contents of this book. In short, it is a work of fiction, any resemblance to characters living or dead is purely coincidental, etc.
I hope you enjoy it.