Author Van Lindberg is both software engineer and practicing attorney. His new book, Intellectual Property and Open Source tackles the slippery subject of intellectual property in a way that we can all understand. When Van's book made its debut at OSCON 2008, we managed to snare a few minutes with him to find out why intellectual property law is so important to developers—any developers—and to hear his tips for developers starting out in the world of open source. Watch the video or read the transcript of the interview below.
What is your background? What made you able to write this book?
I've always been interested in computers. I first started running Linux in 1994, with a very early version of Linux, and since then I've been involved in one way or another with computers, programming, or open source. I was a software developer/engineer for five years and then I went to law school.
It seemed to me that I'd always been interested in open source and here it was becoming more and more important, but people didn't really understand how it worked. You saw businesses talking about it and lawyers talking about it but developers were left out—they didn't understand it and no one was talking to them about how intellectual property worked with open source.
Who is the audience for your new book? Is it developers or lawyers?
It's for developers, for anyone who makes a living developing things. It's written from the perspective of someone who has an idea and needs to understand how these things interact with their work—someone who wants to start up a project or start participating in a project. What do you need to do? How do you discuss it with your employer? Do you need to worry about patents, copyrights, licenses? How do you open source it? Those sorts of nuts and bolts issues are what I write about.
What exactly is intellectual property?
Intellectual property—even though we have one name for it—includes a lot of different things that are sort of stuck together. It's patents. It's also copyrights, which are particularly important for most software. It also includes trademarks, like the name of your project can sometimes be trademarked. And, there are trade secrets which you may sometimes get involved with through your employer. Even open source companies can have trade secrets.
There are also some aspects of contract law—agreements that you make. The most important of those are software licenses that you release your software under. And then there's even a little bit with when your project grows up and you want to create a foundation around it. How do you do that? In all these ways, the law shapes what you can do with your project and how you interact with it, and so it takes you through the lifecycle of a project and gives an overview of those areas. Patents are a way of protecting not just a particular piece of code but the ideas behind that code, any way that you happen to do it.
With software, it gets difficult because there are so many different ways to do it that you're not protecting something like a particular machine or a particular gear or a particular chemical structure, you're protecting what is really very close to an algorithm, so you can get very broad protection. That's why software patents are such a big deal in the open source community and why they're really not very popular. In Europe, for example, software patents aren't really allowed.
Software is unique in the fact that it has an oral tradition. A lot of the time when people learn how to write software, they learn it from their peers. They didn't necessarily learn it from books or written reports; a lot of the most fundamental parts of software were passed down from person to person, sort of in the sense that Eric Raymond's brief, the Jargon File, captures some of that oral history. It's finally being put down in the Jargon File result of the Internet. Now all of that oral history is valuable, and it existed before, so those things shouldn't be eligible to be patented. But, because it was oral history and not written down, it was invisible. A lot of people will say, I was doing this back in the eighties, but it's very difficult to prove that.
In theory, every patent that comes through is absolutely novel. Nothing like it has existed. The problem is that sometimes the examiners aren't always as familiar with the technology as they should be and there are different ways that you can phrase things or add on things so that sometimes patents that shouldn't be out there are granted, and these can cause a lot of trouble for the software, hardware, and all sorts of industries.
Can you give us some examples?
For patents--this wasn't' really an open source case--but the one that most people will remember was one called Rim versus NPT. Rim is the company behind the Blackberry, and they were almost forced to shut down their entire network because of a patent over the way that they sent and retrieved email from this little handheld computer. It ended up they had to pay something along the lines of $645 million to settle that.
Now, what's really amazing is that subsequent to that, they entered into what is called a "re-examination." That's where you take a patent and go back to the Patent Office and try and convince them that the patent was granted wrongly, that it was in error. And so far, NPT hasn't made it through re-examination. They haven't been able to convince the Patent Office that all their claims—the ones that Rim paid $645 million dollars for—are valid.
Then there was SCO versus Novell, which was about Linux, and who really held the copyright in both Linux and in the old AT&T System V UNIX code. SCO claimed that they owned it, and they decided that part of the reason that Linux had become so successful was because people must have copied parts of this Unix code into Linux. So they created a licensing program called SCOsource, which essentially said, "If you pay us money we won't sue you." Naturally, this wasn't very popular.
Exactly. So Novell said, "Wait a minute, you can't do that, we own the copyrights to Unix. You don't have anything to sell!" And so they started suing back and forth. It happened actually that just about a week ago, the final judgment in that came down. Now, instead of Novell owing SCO millions of dollars, it actually turns out that SCO owes Novell two and a half million dollars for selling things that they didn't really own. They can still appeal, but it's not looking real bright.
Another one that a lot of people will remember is the Grokster case. Grokster is, of course, the peer-to-peer file sharing application. The law, up to that point, said that you don't have any control over what your users are doing and if you are not directly infringing on anyone's copyright yourself, then you're safe, if you have other actual real uses for what you're doing.
Well, this went up to the Supreme Court, and the Supreme Court came out with a new doctrine that said that if you are inducing others to commit copyright infringement, then it amounts to the same thing. And when they looked at Grokster's website and saw that it told users that they could download all these movies and all these songs, and they were clearly profiting from the copyright infringement that was going on, in spite of the legitimate uses of this peer-to-peer software, the Supreme Court slapped them down.
So what sort of pointers or tips would you recommend to a developer that is starting out on an open source project? What sort of things should they start thinking about very soon in the open source process?
Well, the very, very first thing is that if you are employed, talk to your employer before you commit any code. A lot of times, that's the first thing that will get people in trouble. When you sign an employment agreement, most developers also sign an agreement that says, "anything that I create, I need to give to the company."
Is that usually enforceable?
In a lot of ways and in a lot of states, it is. And so, it really presents a crimp. If someone has started writing code and either open sourcing it or contributing it to an open source project, then—according to the company—they've taken the company's rightful code and given it out to everyone.
I can see where that's a problem when you're taking code from the place you work and start an idea based on something you've developed working at that company, but what if that software project didn't involve any aspect of your job. Say, for example, that you work at an airline but while you're working there you figure out a great way to do unit testing and you begin working on it. Then, you leave that job to develop your brilliant unit-testing framework. Even though you built on the experience gained at that job, your project had nothing whatsoever to do with your work there. Is that a problem?
That's also a problem. Of course, it depends on the particulars of what you signed. So that's why you need to check those things out early. And if you can get their permission before you commit any code, then you're in a much stronger position, because you haven't done anything—there's no intellectual property that they can have any claim on, and they're much more likely to say, "Sure, you can pursue your unit testing framework." Even if it's not connected with your work, though, if you've got one of these agreements that assigns pretty much anything technical that you create to your employer, then you could be in trouble.
Don't most startups start like that? Someone leaves one company because they have a better idea of how to do something, so they break out on their own?
Yes, and if it's a successful company, lawsuits follow.
So that's one tip. Do you have any others that they should consider?
Yes, another thing is to be aware of copyright and how it interacts with your license. When you're starting to work with code, you're starting to work with copyright law as well as with code. You need to make sure that you're covered. For example, there are a few easy steps to make sure that when someone sends you a patch, that you're okay to use it. You think it would be obvious that if someone sends you a patch, it's okay to use. But, unless you jump through the right hoops, it's actually not. Be aware of that.
Another thing to think about if starting a new project, is the name. A lot of times, when open source projects want to grow up—when they want to form a foundation and protect themselves, or do various other things—one of their biggest assets is actually their name. Think about Linux. For a long time, it wasn't a trademark. And one person said, "Wow, look at all these people using the term 'Linux.' I'll register the term 'Linux' and I'll start charging them money!" Now, he wasn't successful, and there was a court case that forced him to assign the Linux trademark to Linux Torvalds.
There are rules about domain names and trading on other people's trademarks. Another peer-to-peer application, AIMster, was shut down because it was too similar to AOL's trademark, AIM, their instant messager. And then, the Pigeon instant messenger used to be called GAIM. Its also was forced to change its name because of trademark law.
So, what about the trademark on GIFs?
That's actually not a trademark. It was a patent on the specific LZW compression method that was used in GIFs. That patent is gone now. It's expired, so it's no longer an issue.
So how long do patents last?
About twenty years. That's a long time in technology, but they do expire. A lot of the problems come with copyrights, which have terms of 95 to 150 years, even 170 years, depending on how long a person lives. Those can last a very long time, and that's what's causing much of the trouble.
A lot of what I talk about in my book isn't just the nuts and bolts of how it all works—yes, I write about that—but I think that the principles of intellectual property and open source that are the most valuable. The first chapter starts off with economics: why in the world do we have intellectual property? And then you see how various types of intellectual property are really designed to address some of the economic issues that drove the creation of intellectual property law.
And similarly, with open source, I talk about it in the aspect of game theory, in that what you're doing is establishing a framework for cooperation and it uses the law to make that stable in game theoretic terms. And so, keeping those principles and the broader context of why these things work—that's the most important thing to keep in mind.