- Related Stories
New open-source license targets DRM, HollywoodJanuary 18, 2006
Stallman unbending on software patentsJanuary 17, 2006
Public debate on GPL 3 draft beginsJanuary 16, 2006
IBM taps open source to improve patent qualityJanuary 9, 2006
Sprucing up open source's GPL foundationDecember 23, 2004
Lights, camera, legislationAugust 7, 2002
(continued from previous page)
What exactly is wrong with software patents?
Moglen: Patents, unlike copyright, are said to control ideas rather than expressions. The soul of the free software movement is the re-implementation of neat stuff we thought up, no matter how we learned it or where we came by it; and in the world of copyright, there's nothing wrong with that. You can re-implement or redescribe or re-express anything you want however you please. When you write a newspaper story or a Web site story tomorrow, the question isn't: Are you reporting news somebody else owns? The question is: Did you write your own story?
Imagine a world in which news was owned in such a way that once one guy reported it nobody else could report it for 20 years because the first guy to report it owned it. That's the problem that the patent law proposes to software.You said the social environment for free software is better. What changes were made in the license because of the relative success of the free software movement and free software?
Moglen: The globalization of the movement--the immense geographical cultural spread of free software--means the license has to work in more places, more completely, more strongly for more people who do more diverse things. We have rewritten many provisions of the license to remove U.S.-centric vocabulary or legal concepts, to neutralize the language of the GPL so it can be used more effectively in more countries with less legal uncertainty.
Second, there are also more programs under more licenses which, while free, are incompatible with GPL. To enable broader technical collaboration, we have added the enhanced compatibility provisions of the license to allow more people to share more code across more projects than ever before. The ability to share Eclipse License code and Apache License Code...means that GPL now reaches far more broadly across the world of programs and projects than it ever did before. We are doing what we wish everybody would do with the problem of license proliferation: We're expanding our compatibility in the hope that people can use fewer licenses to do the same amount of work, and we think that too is a response to success.
Under the new license draft, may GPL software be included under
software governed by the Apache Software License?
Moglen: No, the GPL is still a copyleft license, and the Apache Software License and the Eclipse License are still permissive licenses. They permit code under those licenses to be used in proprietary ways, and it is therefore not possible to open up a two-way street.
One of the questions with the GPL is about how tightly you may link GPL code with non-GPL code, for example, when you compile a GPL program and it uses other code in a software library. Have you done anything to define how tightly GPL code may be linked with non-GPL code? Under what circumstances is that permitted and not permitted?
Moglen: We have made one clarification, as we see it, of what we believe was always the rule. We reasserted that code dynamically linked to GPL code--which the GPL code is intended to require, not merely optionally incorporate--is part of the source code of the work under the GPL and must be released.
One specific area where the linking question arises is in the Linux kernel, where proprietary video drivers loaded are loaded as modules. Another one might be the use of a network driver that relies on proprietary firmware that is loaded from an operating system. (Such firmware, sometimes called "blobs," are strings of hexadecimal digits loaded from the operating system kernel into the hardware device to enable it to run.)
Moglen: In all good faith, I can't tell you. If the kernel were pure GPL in its license terms, the answer...would be: You couldn't link proprietary video drivers into it whether dynamically or statically, and you couldn't link drivers which were proprietary in their license terms.
Now the blobs--the object code somewhere in the kernel--raise other complicated issues because in the context of the kernel, they are data. They are just bits being moved around. It is on some other machine--a phone, a USB device--that they are code. And in that other context, they are not mixed with GPL software; they're just a program running on another chip in another computer.
I would distinguish the blobs from the proprietary drivers in the kernel. If the kernel's terms were unambiguously GPL, which they are apparently not, (proprietary drivers) would be forbidden. The blobs--though they are ethically objectionable to the Free Software Foundation, which believes that users ought to know what's running--are different because they are separate works when executed running in separate computers. From the point of view of the GPL work called the Linux kernel, they're just data.