Ars Book Review: “Intellectual Property and Open Source”

A programmer’s point of view

You'd have to do a lot of man-on-the-street interviews before you'd find someone who could explain the difference between a patent and a trademark. And even the relatively savvy participants in the Ars forums have been known to mangle copyright's fair use doctrine, misunderstand key provisions of the GPL, or foolishly assume that the law must track their own notions of common sense. HangZhou Night Net

Yet the complex and esoteric legal regimes collectively known as "intellectual property"—copyrights, patents, trademarks, and trade secrets—have never been more important in the lives of software developers. Failure to understand the implications of key legal documents can prevent programmers from doing their jobs and enjoying the fruits of their labor. And because the free software community has learned to leverage the power of copyright law to protect end-users' freedom, understanding copyright law is especially important to developers of free software.

There are plenty of books that make policy arguments about how copyright or patent law ought to be changed. But there are few books that help the reader understand the current state of the law. Too often, a programmer who wants to understand the "rules of the road" with regard to copyrights, patents, trademarks, and trade secrets has to either wade through hundreds of pages of dense legalese, or pay a lawyer hundreds of dollars an hour to explain it to him.

Into this void steps Van Lindberg, a former software engineer and now a lawyer who specializes in the legal issues surrounding the free software community. Lindberg starts with the basics, explaining how copyrights, patents, trademarks, and trade secrets work. He then dives into the details that are most likely to be of interest to software developers: employment agreements, software licenses, copyleft, reverse engineering, and formalizing a project by creating a non-profit organization. No book could replace the advice of competent legal counsel, but reading Intellectual Property and Open Source from cover to cover will give the average free software developer a clear understanding of the legal terrain she will have to navigate as she creates, improves, or uses free software.

Nuts and bolts

Although it's officially focused on open source developers, there's plenty here that will be of interest to anyone who writes software for a living. There's an extensive discussion of proprietary information agreements, invention declarations, patent assignment, and other annoying paperwork you have to deal with when you're writing software for an employer. The basic concepts are common sense—read what you sign and talk to your employer early and often—but understanding the details will help you avoid costly mistakes. Lindberg describes several cases in which employees left companies in order to commercialize an idea, only to face massive lawsuits from the former employers, claiming they were the rightful owner of the employee's technology. Getting the paperwork right when you start a job will help to ensure you don't get tangled up in litigation when you leave it.

There's an extensive discussion of various free and open source software licenses. There are dozens of licenses out there, but Lindberg narrows it down to six—the GPL and LGPL, the BSD license, the Apache License 2.0, the Mozilla Public License, and the Open Software License Version 3.0—that are legally sound, widely supported, and serve a variety of projects with different needs and priorities. And perhaps the most important point Lindberg emphasizes about licenses is this: don't write your own. As the confusion over the Artistic License (which was written by Perl creator and non-lawyer, Larry Wall) demonstrates, the uncertainty generated by a poorly-written license can create years of unnecessary headaches for free software projects. Don't do it.

A particularly confusing topic is legal status of derivative works when free software written by different people is combined: If you link your software to a GPLed library, do you have to release your own source code under the GPL? The answer is: it depends. For example, static linking is more likely to create obligations under the GPL than dynamic linking. However, the answer won't be clear until the issue ends up in court. In any event, Lindberg clearly and concisely explains the arguments on both sides so you'll have a clear idea of the legal risks you'll face in any given situation.

Conservative approach

Pushing the technological envelope often requires pushing the legal envelope as well. Indeed, it's only a slight exaggeration to say that every significant breakthrough in digital media technology has been greeted with a lawsuit. The VCR, the MP3 player, peer-to-peer file sharing, web search engines, book search engines, digital video recorders, and video-sharing websites have all faced lawsuits by incumbent copyright holders seeking to prevent their appearance on the market. If you think you've got a groundbreaking new media technology, but you haven't been sued by Hollywood or the RIAA, your technology probably isn't so revolutionary after all.

Had developers consistently followed Lindberg's advice over the last decade, many of the technologies we now take for granted would never have been created. Lindberg advises readers that "the easiest way to reason about copyright is assume that any use of a copyrightable work is legally reserved to the copyright owner" (emphasis in original). This is certainly the easiest way to reason about copyright, and it may also be the safest way. But a lot of progress over the last three decades has come because people have not followed this advice.

To be fair to Lindberg, his book isn't intended to be a handbook for pushing the boundaries of copyright law. As Lindberg tells Ars in our exclusive interview, he wanted to provide a baseline of understanding about what the law allows. If you just want to be sure you won't get sued, this is the book for you. But there are many software developers—especially in the free software community—who want to do more than just avoid lawsuits and collect paychecks. They want to introduce cool new technology, revolutionize industries, and change the world. Doing that often means disrupting the business models of technological incumbents. And when those incumbents can't compete on the merits, they're inclined to bring in the lawyers.

The book pays scant attention to the hot-button issues—fair use, the DMCA, the first sale doctrine, and software patents—that have sparked a thousand flamewars in the Ars forums. The section on fair use is barely a page long, and it ignores the recent fair use decisions that have been most important to the technology industry. There is no mention of the Supreme Court's famous 1984 Sony decision that confirmed that time-shifting with a VCR was fair use. Nor does it mention the 1998 Diamond decision, which found that the fair use doctrine allowed space-shifting with an MP3 player. Nor does it mention recent decisions allowing the use of image thumbnails in search engines on fair use grounds.

This is not a book for legal scholars, so of course there's no reason to expect these cases to be covered in depth. But a brief discussion of these cases—with appropriate caveats—would have at least alerted entrepreneurs to the existence of these decisions so that they could decide for themselves whether to take the risk of building a business around a controversial fair use claim. Because these topics are omitted entirely, the reader could be left with the erroneous impression that the law is settled in these areas and she is better off not developing a technology that could anger Hollywood.

Intellectual Property and Open Source will be a valuable addition to the bookshelf of any developer—open source or otherwise—who contributes to large-scale software projects. It offers a solid foundation for understanding the major legal regimes that govern the software industry, and it clearly marks a variety of legal traps that might otherwise ensnare software developers. Developers should not take it as the final word on what the law allows, but it's an excellent starting point for understanding how to write code without winding up in court.

Comment are closed