FSF statement on GPL "loopholes" (Score 1)

As the Free Software Foundation's General Counsel, I want to respond officially on FSF's behalf to some of the questions raised by Peter Wayner through timothy's post on July 1. Although Mr Wayner has reported on the questions for some time, and like other members of the community I have been very grateful to him for his excellent and informative work, I do not think that his questions represent "loopholes" in the GPL. I regret not having had the opportunity to talk to Mr Wayner in connection with his forthcoming book.

The general proposition on which Wayner's comments rest is that there is ambiguity concerning the meaning of "distribution" under the GPL. The first thing to be said is that the GPL is a copyright license, and when it refers to distribution it is using a term of art. "Distribution" under the GPL is distribution as copyright law understands it. Many people use the GPL to distribute software in many different places, but in what follows, for the sake of simplicity, I'm going to assume that the program being distributed is a copyrighted work of the Free Software Foundation, such as emacs or gcc. I'm also going to assume that the applicable copyright law is US copyright law. What I'm going to say is more general, but this will do for illustration.

To begin with, some of the problems Wayner associates with ambiguity about distribution are not about distribution at all. These problem are about whether code is part of a single GPL'd work when it is meant to communicate with, or operate in sequence or in parallel with, GPL'd code.

These questions are not being raised for the first time, and the Foundation has a single consistent position. Code which is statically or dynamically linked to GPL'd code constitutes a single derivative work of the GPL'd code, and must be distributed under the terms of the GPL. Code that is not linked to GPL'd code, but is distributed as part of a "mere aggregation" of works is not subject to the GPL, as section 2 makes clear. So when Wayner says that

it's easy now for people to write scripts that link seemingly disparate programs -- thousands of them, even -- and then execute them in concert. I know one company that uses Adobe Photoshop to process images created by a proprietary, in-house tool. Is the software linked together? The process is entirely automated and works with no human intervention once initiated.

he is describing an aggregation of works. If one or more of them are GPL'd, they must be redistributed in keeping with the GPL. Other works that are part of the same aggregation are not covered. The same is true with respect to processes running simultaneously, whether on a single multiprocessor cluster or in multiple machines communicating across a network. In order for code to be covered by the GPL it must be part of a work derived from GPL'd code. If it is aggregated with GPL'd code, or communicates across defined interfaces with GPL'd code, it is not part of the same work.

Wayner presents a lengthy example concerning a weather database the purport of which isn't clear to me. The point seems to be that data produced by a GPL'd program might also be employed, through ordinary open network protocols, by non-GPL'd code. This situation also presents no ambiguity under the GPL. The GPL, again, is a copyright license, and it ony applies to copyrightable works which authors or assignees chose to license under its terms. Data compilations are not in general copyrighted works, and data produced as a result of the execution of GPL'd code is not in general subject to or controlled by the license on the code that produces it. There is nothing to prevent someone from writing and distributing non-GPL'd code that makes use of data produced, whether in real time or in stored form, by GPL'd programs. And there is nothing that prevents people from passing data between GPL'd programs and non-GPL'd programs, or from selling combinations of programs or services that mix GPL'd and non-GPL'd code.

Some of the questions Wayner raises are, however, about distribution. They are not more difficult than the non-distribution questions, but the legal background should again be slightly clarified.

Emacs, for example, is a copyrighted program, and unless you have a license from the FSF to engage in "distribution" of emacs, you can't do it at all. Under 17 U.S.C sect. 1001, the definitional provision of US copyright law,

''Distribute'' means to sell, lease, or assign a product to consumers in the United States, or to sell, lease, or assign a product in the United States for ultimate transfer to consumers in the United States.

So that's it. Anything that constitutes selling, leasing, or assigning a program within the United States or for ultimate sale, lease or assignment to an end user in the United States is distribution. As you would expect, there are loads of cases explaining what that implies in particular factual settings, and as you would also expect, those cases by and large take an expansive view of the copyright owner's right to control distribution, so doubt is resolved in favor of inclusion.

Against that background, let me take up the specific questions Mr Wayner raised.

But imagine that MegaSoft decides that it really needs an internal editing system for filling out proprietary MegaSoft paperwork. The programmers love Emacs so they take GNU Emacs and add a few tweaks for providing the user with forms. Some of it is written in Emacs LISP and some of it requires a few neat extensions to the basic Emacs module. Everyone loves the software and they start shipping it to all of the PCs in the corporations. [He evidently means "corporation."]

Is this a distribution? Some might argue that it isn't. A corporation is just a legal fiction for a single person. It's not much different than Bob the hacker writing the code for his own use. Bob doesn't need to share the source code until Bob starts giving it to Alice, the other hacker. By this argument, MegaSoft doesn't need to share the source unless MegaSoft ships the software to another company or non-employee. Even if there are 100,000 employees in MegaSoft, there hasn't been a distribution.

Not quite. MegaSoft is not yet distributing its modified emacs to consumers. Its internal modifications are covered by the GPL, however, because it is copying as well as modifying the software, activities which are only permitted if you have a license, and the terms of the license specify what MegaSoft must do. If it keeps these modified copies on its own computers, it has no further responsibilities under its license. If it allows employees to remove the copies to their own computers, it is then engaged in distribution, and it must provide source and allow those employees to redistribute the modified software under the terms of the GPL.

The same principles explain the situation regarding acquisitions and divisions of the MegaSoft Corporation, as well as the question supposedly presented by the free software assets of the company in the event of insolvency or sale. All the code is covered by the GPL from the moment of its copying, modification, or distribution, and any distribution must occur under the GPL's terms.

Wayner also asks about the embedding situation, presenting the example of Tivo. Tivo distributes a quasi-embedded system in which a free software kernel is used to execute unfree software. This is an aggregation of components, and Tivo is responsible under the GPL for the compliant distribution of the free software components of that aggregation. It is not responsible for releasing any of its own code under the GPL. The test is not whether the user can "pry" them apart in the particular circumstances of an embedded system.

There are deeper problems on the horizon. Some companies are now "loaning" or "renting" software. In some cases, you don't even keep copies on your local machine. You just download it from the server and use it for a bit.

These situations present no problem. Under the statute, leasing a work is distribution, and such technical arrangements are plainly covered by the GPL. Anyone offering execution access to GPL'd code, or code based on GPL'd code, must do so in a compliant fashion, wherever the leased copy is delivered or executed.

In fact, we can take this one step further. What is the real difference between using the software on their server and downloading it? Is there much difference between using the Hotmail web-based email system or running Eudora on your desktop? There isn't much difference to the user, even though there are big legal differences. In one case, Hotmail still owns the software and it's all proprietary. In the other, Eudora sold you a copy. Well, maybe they sold you a license. Well, who really knows?

Maybe we can clear up this confusion most easily if we step away from software for a moment. Let's use a copyrighted movie instead. From the point of view of what constitutes "distribution," is there a difference between broadcasting a pay-per-view movie over a cable system, so customers only get to watch the movie, or selling them the movie on videocasette? No. Both are distributions, and in both cases the entity making the distribution must have a license and comply with its terms.

The most important thing to note about all these situations is that the "loopholes" Wayner is wondering about don't have anything to do with the drafting of the GPL itself. The GPL simply uses the concept of distribution defined in the general copyright statute. If there is a "loophole" it is a matter of general copyright law and the GPL is neither more nor less affected than any other copyright license. Wayner has kind things to say about Richard Stallman's drafting, and as the lawyer who has assisted the FSF for a decade in the use and enforcement of the GPL, I entirely agree with him about the document's elegance and utility. But he gives the GPL too much credit and assigns it too much blame when he supposes that the questions he is asking are questions about the GPL and not about copyright law in general. Fortunately for copyright law, it is not quite as fragile a system (in this respect) as Wayner seems to think.

I also feel I ought to comment, on FSF's behalf, on a statement made in the course of the discussion by Matthew Smith:

So GPL doesn't benefit everyone. Just like communism it benefits those who are visible and loud but not those who work hard. A BSD coder can extend their code and one day decide they want to turn their effort into a product and they can do it. The freeloaders don't have the right to complain because they still have the old version which is free. For a GPL programmer this isn't an option, once communal always communal is the name of the game here.

This proposition is not correct. The person who holds the copyright on a program can choose to license it under the GPL if she wants, but when she does so she can also license it, simultaneously or sequentially, on non-GPL terms. If she later wants, as Mr Smith suggests, to enhance it further as a non-GPL product, nothing whatever prevents her from doing so. She owns the copyright and is not somehow bound by the terms on which she licenses to others. The version released under the GPL is still free, of course, and can be modified and redistributed by anyone else. Those people, who do not own the copyright, cannot make their modifications proprietary. But that's because they have to obey the terms of the license that allows them to modify and redistribute in the first place.

I don't happen to agree with the way Mr Smith threw the word "communism" around. As I have mentioned in an essay on these subjects that a few people may have read, called Anarchism Triumphant: Free Software and the Death of Copyright , I think there are closer political analogues to what's going on here. But in any event it should be clear that people who choose to employ the GPL are not having their farms, their computers, or their programs forcibly collectivized.