Sticks, Stones and the GPL

It’s nice to know someone is reading my column. According to some of your letters, it seems my recent column on the GPL [Phil Albert, “A Consumer’s Review of the General Public License, LinuxInsider, July 20, 2004] touched a nerve. To my critics who referred to me by names other than Phil, I can only respond with an equally mature “Same to you!” For those who prefer a more reasoned discussion, please allow me to devote this week’s column to answering some of your criticism.

For starters, this is an opinion column. It is based on my opinion as an intellectual property attorney with considerable experience. My column on the GPL 2.0 was a product review, not an attack on the GPL itself — and anyway, it was mostly favorable. I never said that companies should not use it, and I am not opposed to the concept of copyleft. The idea of copyleft was clever and very unique at the time Richard Stallman came up with it, and he deserves credit for that.

Point, Counterpoint

I started paying attention to GPL developments as a programmer in the late 1980s. Ironically, much of my early *nix programming experience was with an operating system known as SCO Xenix. Since then I’ve attended Free Software Foundation (FSF) seminars and studied the GPL extensively, and I’m not the first one to raise some of the issues I covered in my column.

Some readers criticized my comment that the GPL was written without lawyers. They argued that lawyers have been involved with the GPL for about a decade. But that only takes us back to 1994. The version of the GPL I reviewed is from 1991. If GPL 2.0 is so perfect, why is GPL 3.0 on the way?

It is true that when my clients pay me to provide legal advice, they prefer that I take their side in disputes. But no one is paying me to be an advocate here. I’m a LinuxInsider columnist and I express my opinions about the industry. If you don’t trust my opinion, I suggest you check out legal commentary from unbiased law professors, many of whom echo my comments about the GPL. That said, let me address some of the honest criticism of my review.

Definitions of Derivative Works

Pamela Jones, who runs the awesome Groklaw.net Web site, took issue with my statement that the GPL 2.0 provides two conflicting definitions of derivative works: the “before the colon” definition tying it to copyright law; and the “after the colon” definition defining it another way. She argued they are the same, and she provides three definitions for derivative works: the “following the colon one”; a U.S. copyright version; and the statutory version. I argue that none of these are identical to each other, which proves my point — don’t define something twice. Good programmers know it is bad practice to redefine constants.

Jones pointed out that some attorneys write articles that are thinly disguised sales pitches designed to bring in new clients. That was not my intention. When I said that the definition of “derivative work” was complex, it was because it is.

In the United States, the legal definition of a term often starts with a statutory definition. For “derivative work,” the controlling law is federal law and the relevant statutory definition is provided by 17 USC 101. However, since the United States is what is known as a common law jurisdiction, case law further defines the term for instances where the statutory definition was unclear. Obviously, I do not have enough space in my column to provide all of the case law to set out the legal definition of derivative work.

As a result, I believe the best definition of derivative works for a license is this: “a derivative work is a derivative work as defined by the applicable law” and nothing more. That leads to my next point.

Choice of Law

The legal definition of a term cannot always be as simple as a declarative statement, not because lawyers want to make more work, but because the real world is complicated. I recall a dispute involving an artist’s copyright. Someone bought a book containing a number of the artist’s prints, unbound the pages and sold the prints individually mounted on tiles.

The dispute was whether the tiles constituted derivative works. That is not exactly covered by the words of the statute. The court ruled that the mountings constituted derivative works. Don’t blame the lawyers. Definitions have different meanings in different contexts.

Licenses, contracts and other legal documents include a choice of law provision because documents can be construed differently in different places. While copyright law is federal law, state law can still be implicated in a copyright dispute. Furthermore, federal law is not identical across all federal circuits. And the GPL is used in other countries, so even U.S. federal copyright law is not always the last word.

Interpretation Matters?

Forgive me if I repeat myself. Eben Moglen’s interpretation of the GPL, regardless of how good a lawyer he is, means nothing for GPLed works not owned by the FSF, Moglen or his other clients.

No matter how good a legal document purports to be, interpretation is almost always necessary because of the limitations of language and the inability to predict all possible uses of a legal document. Don’t take my word for it. Even Richard Stallman and Linus Torvalds disagree on the exact interpretation of the GPL when it comes to derivative works and dynamically loaded kernel modules.

When a licensor grants a license using the exact text of the GPL, the intent of the licensor and the applicable law must be taken into account to determine the bounds of a GPL-based license.

Implied License

Critics of my position on implied license missed the point. Absent a license, one incurs liability by copying a copyrighted work. An “implied” license means that, given the circumstances, the court would deem a license of some sort to have existed where there was no explicit license. That is what would give a person the right to copy the work.

This is not just legal sophistry. In some cases, mere execution of a program legally constitutes copying, so one would need a license to run, copy, modify or redistribute a program without incurring copyright liability.

The GPL 2.0 explicitly states that running the program is outside the scope of the license, so the GPL does not explicitly grant a license to run the program. However, in stating that running the program is not restricted, there is an implied license to run the program to the extent that a license is needed.

Untested in Court Does Not Mean Steel-Plated

To the credit of the FSF and others, many potential disputes go away with a little education or pressure from a community of interests. However, that does not mean the GPL is a perfect license.

For something to be tested in court, there first needs to be some significant potential upside for the plaintiff if the case is won or some significant potential downside for the defendant if the case is lost — otherwise it settles quickly.

Second, there needs to be a significant mismatch between how the plaintiff thinks the case will turn out and how the defendant thinks the case will turn out, or a belief on the part of one of the parties that a court ruling will result in new case law favorable to that party’s position.

Those conditions are not present with most GPL disputes. Often, there is not enough interest in arguing. Interpretation of the GPL is an issue we can expect to see more often.

Keeping the Debate Out of the Mud

Here’s something you should know. I have written code that I have given away and some that I have copylefted, so I have no problem with the concept.

My point is simply that licenses should be clear, to both lawyers and nonlawyers, so that unnecessary disputes over license terms are avoided. I hope that clears the air, so we can avoid any muddiness in the future.