In a recent interview, ESR shocked a lot of people when he said, "We don't need the GPL anymore." Federico Biancuzzi recently contacted RMS, founder of the Free Software Movement and initial developer of the GNU system (the G in "GLAMP"), to talk about the past, the present, and the future of the GNU GPL. Among other things, they discussed the new clauses of the upcoming GPL version 3.
In a recent interview I did with Eric Raymond, he stated, "We don't need the GPL anymore." I'm sure that you don't agree, right?
The GNU GPL is designed to achieve the goals of the Free Software Movement; specifically, to ensure that every user of a program gets the essential freedoms--to run it, to study and change the source code, to redistribute copies, and to publish modified versions. The GPL does that job very well; most other free software licenses don't try.
In fact, some non-GPL-covered free programs have widely used nonfree versions. For instance, consider Apache, whose license is free software but not the GNU GPL. We often hear that some 70 percent of web servers use Apache; what we don't hear is that a large fraction of those servers are using a nonfree modified version of Apache, as permitted by the Apache license.
If what you value is the popularity of your code, and such a thing happened to your program, you might consider it a good outcome. In the Free Software Movement, our goal is to bring freedom to computer users, and such an outcome for us would be a substantial setback. The GPL does good service in preventing this.
ESR addresses the issue in terms of different goals and values--those of "open source," which do not include defending software users' freedom to share and change software. Perhaps he thinks the GNU GPL is not needed to achieve those goals.
Is free software a better system of production?
Free software isn't a system of production. It means software that respects the freedom of the user--regardless of how it was developed.
There are four essential freedoms that define free software:
If a program gives its users these freedoms, it is free software. If it does not, then for the sake of my freedom I will avoid using it.
These criteria are a matter of the program's license; they have nothing to do with how the code was written, or by whom, or by how many people. A program can be free software if it was written by a collaborative group, and it can be free software if it was written by a single person.
There are some who say that a collaborative development model, taking advantage of these freedoms, tends to make software that is technically better. They may be right, and it would be nice if freedom brings such a practical bonus. However, the freedom itself is more important than the bonus, so the Free Software Movement focuses on the freedom.
Did the GPL contribute to the popularity of GNU/Linux, or maybe it was just a "social signal"?
I know that the GPL contributed directly to the capabilities of GNU/Linux. I can cite two examples from memory, but I am sure there are many more.
The GCC support for C++ was implemented by MCC. If not for the GPL, they would have made it nonfree software. The GPL did not allow that, so they made it free. C++ support is rather important, I think.
Large contributions have been made to Linux, the kernel, by companies that don't normally develop free software. If they had made nonfree versions instead, that would have been a great setback.
But that's not the main point. The GPL does something even more important: it guarantees that all users receive the freedom to share and change the software. That's the purpose of the GNU system, what it intends to deliver--the freedom to cooperate, for each and every user.
Do you think that GNU/Linux is so famous (more than BSD, for example) because it comes under a license that defends users' freedom?
I don't know--but the question doesn't seem important. Our goal should be to spread freedom and then defend it. That is more important than making our software popular, which would just be catering to our egos.
A lot of free software projects choose to use the following phrase in every of their program files:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
But this means:
How can this undefined condition be a good thing?
This achieves two goals. First, that we can release future GPL versions and they will apply to the existing software. Second, that in releasing future GPL versions, we cannot impose any new restrictions on the existing software.
GPL version 3 will need to contain specific requirements that GPL version 2 does not have. Nothing large--the overall idea will be the same--but there will be some. I designed the words you've quoted to make it possible to distribute the existing code under GPL version 3, without imposing even the smallest new requirement on existing code, because people will still be able to use it under GPL version 2.
Will you keep this phrase with the GPL v3 too?
Yes, certainly. We cannot assume that GPL v3 will be perfect, that no further change will ever be needed.
What type of compatibility and interaction will GPL 3 have with previous version of the license?
Even small changes from version 2 of the GPL will result in an incompatible license. Two slightly different licenses, each saying that modified versions of a program must be distributed under the same license, are inevitably incompatible. That's why we suggest that programs permit use of future versions of the GPL. It is the only way they can migrate.
Linux (the kernel!) comes under GPL version 2. Quoting Linus's note:
Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
What would you do if Linus chose to keep the kernel under GPL v2.0? Would you promote a fork led by someone else under GPL v3?
Only the developers of Linux can decide what to do about licensing of Linux. I hope they'll decide to convert back to "GPL version 2 or later" and subsequently upgrade to GPL version 3, but it's up to them. There's nothing in the matter for me to do.
Maybe you could talk about the common question that people have: a project under GPL that receives a patch under GPL 3. What happens?
If the project's current code permits use under "GPL version 2 or later," they can integrate that patch. However, the files where they have merged in the patch will have to say "GPL version 3 or later."
They also have the option of not using that patch, or asking the contributor to give permission for its use under "GPL version 2 or later."
If I take a patch under GPL 3 and merge it with a project under "GPL 2 or later," should I write that the new license for the whole project is GPL 3?
The merged program as a whole can only be used under GPL 3. However, the files you did not change could still carry the license of "GPL 2 or later." You could change them or not, as you wish.
And then include GPL 3 in the file named COPYING?
Yes, you should include a copy of GPL 3. If some files remained under "GPL 2 or later," then you should also include a copy of GPL 2.
Will GPL 3 include any specific clause for dual-licensed software?
The term dual licensing refers to various different kinds of policies. All they have in common is that the same developer releases the same code under multiple licenses, giving the user a choice of which license to use.
There is no need for the GPL, or any free software license, to contain a specific clause for this. If you want to release your program under two licenses in parallel, you can always do that, and the licenses in question need not be specially designed to make that possible.
Some companies, such as Google, use code covered by GPL to offer their services through the Web. Do you plan to extend GPL 3 copyleft to request code publication in this case too, considering this behavior like a product distribution?
Running a program in a public server is not distribution; it is public use. We're looking at an approach where programs used in this way will have to include a command for the user to download the source for the version that is running.
But this will not apply to all GPL-covered programs, only to programs that already contain such a command. Thus, this change would have no effect on existing software, but developers could activate it in the future.
This is only a tentative plan, because we have not finished studying the matter to be sure it will work.
How would it work?
If you release a program that implements such a command, GPL 3 will require others to keep the command working in their modified versions of the program.
Do you plan to define explicit punishments in the GPL 3 for people or companies that don't respect its clauses?
GPL version 2 already does this: it states that violating the license conditions terminates the license. We're considering changing the details a little, but not more than that.
I think this is an interesting topic. Sometimes we hear that a company violates the license conditions, but I think there is still a lot of confusion about what should happen next. Could you please explain what type of consequence it brings, and what "terminates the license" means concretely?
Legally, termination of the license means that that person or company no longer has legal permission to redistribute or modify the software in question. If it continues to do so without permission, it is copyright infringement, the copyright holders of the program can sue.
Copyright infringement is not necessarily wrong, but distributing software without respecting the freedom of the users is necessarily wrong. If we ever need to sue to enforce the GPL, the ethical justification won't be "you disobeyed us" but rather "you are trampling other people's freedom, and we are here to defend it."
If the author of GPL says "copyright infringement is not necessarily wrong," some people could take code covered by GPL and claim that violating GPL terms is "not necessarily wrong."
I've addressed that point in the statement that inspired your question.
The GPL gets its legal force from copyright law, but that is not a source of moral authority, so none can come from there. Why then is it wrong to violate the GPL? Because that tramples other people's freedom or puts it at risk.
The official version of the GPL is the English version, and it is the only valid version. This means that translations are not legally valid. Is this going to change?
Authorizing a translation of the GPL is very risky, because a mistake could be disastrous worldwide. Most of the world's major languages are known by neither me nor Eben Moglen. We would have to rely on translators who are lawyers but not necessarily free software supporters, and we could not check their work. Thus, mistakes would be rather likely.
We're thinking about the idea of authorizing translations that are valid for one country only. That could reduce the risk to the point where we could consider it.
How do you plan to write a license compatible both with U.S. laws and international laws?
The GNU GPL is based on copyright law. Due to a rather ill-conceived treaty, the Berne Convention, and an extremely nasty treaty officially called TRIPS but which I prefer to call TRIPES--"trade-restricting impediments to production, education, and science"--copyright law is basically the same in most countries around the world. It is not hard to design a copyright-based license that works based on copyright as specified by these treaties. Then it will work nearly everywhere. Individual countries can have peculiarities, and when we find out about them, we will try to take them into account--mainly by avoiding them, so that we continue to have one text for all countries.
Does this means that the GPL 3 will not cover intellectual property licensing and patent issues because it is a "copyright based" license?
People should never use the term intellectual property, because it lumps together various disparate laws and misleadingly suggests they are similar enough to discuss as a coherent whole. Anyone who speaks about "intellectual property" is generally either trying to confuse you or is confused himself. For more explanation, see this page.
Patent law is one of those disparate laws that makes your question resemble the amusing sign that once graced a store in Cambridge: We Serve Food and Greek Subs. (However, "food" is a much more coherent category than "intellectual property." All foods have enough in common that talking about "food" in general sometimes does make sense.)
Moreover, copyright law--although its rules and effects are nothing like those of patent law--is also one of those disparate laws. Thus, the question resembles, "Does this mean you won't serve any food, because you've only got those Greek subs?"
I'll avoid the term intellectual property in my response, to avoid contributing to confusion. But I think GPL 3 will probably give very simple permission for using the contributors' patents, if any--just to make it explicit. That's all it will do in regard to patent law. All the conditions will still be based on copyright law.
It may also contain a clause that retaliates against patent lawsuits, if we can find a way to draw one up that seems effective enough to be worth including. But this clause will be based on copyright law. Such patent-retaliation clauses in other free software licenses are generally based on copyright law; they are conditions for using the copyrighted program.
What do you mean by "just to make it explicit"?
Releasing a program and giving permission for people to copy it implicitly promises not to sue them for doing so, on any basis. So those who distribute a program under any free software license are giving an implicit license, if one is needed. However, we're thinking of adding an explicit statement of this, just to reassure anyone who has doubts.
You said also that GPL 3 "will probably give very simple permission for using the contributors' patents." Does this mean every patent of the contributor, or only those that cover features already in the software?
The implicit license, we believe, only covers techniques used in the code as the distributor distributes it. We're not sure exactly what GPL 3 will say about this, but it won't be greatly different.
I thought about this, and came to the conclusion that as soon as a company releases a piece of code under GPL 3 that uses one of its patents, everyone will be able to use that patent freely, provided that he respect GPL 3 terms.
Not quite. It means that everyone will be able to use the same patented technique that the released code uses, by using that code under the GPL terms.
Do you expect that this could sound "dangerous" to business companies, and that will become an obstacle to transition from GPL 2 to GPL 3?
GPL version 2 implicitly does the same thing, and this has not prevented it from being successful, nor prevented companies as large as IBM from contributing code to programs released under GPL version 2. There is no reason to presume that replacing the implicit permission with an explicit statement of the same thing would change their response.
But the deeper response to that question is to point out its questionable assumption: an exaggerated idea of the role that companies will play in the adoption of GPL version 3. The GNU GPL became the most popular free software license because thousands of individuals used it for their programs. Only a few companies played a role in this, by choosing the GPL for their programs. Companies will play a role in the adoption of GPL 3, but not the principal role.
When discussing software patents, let's not forget that each software patent attacks the freedom of all programmers and all computer users. Each software patent points at a different area of software practice, so the programmers and users who are likely to actually be in the crosshairs varies from patent to patent. But this variation of details doesn't alter the overall nature of a software patent: it's a threat against your freedom. See Foundation for a Free Information Infrastructure for more explanation of this.
Is the patent system broken (and needs fixing) or useless (and needs termination)?
"Useless" is an understatement--in the software field, the patent system is harmful and unjust.
Some big companies have announced that they will share their patents to cover Linux (the kernel!) and some other free software projects. Because Linux people didn't refuse this move, now they have an entanglement with those patents. Doing so, they sent a message to the people that is clearly not "we are against patents."
That is a peculiar way to look at the situation. I don't see how we have any more "entanglement" with these patents now than we did before those announcements.
These companies said they would not use certain patents to attack some free software projects. IBM said it wouldn't use a specific set of 500 patents to attack any of us. Nokia said it would not attack Linux the kernel--but said nothing about the thousands of other programs in a typical GNU/Linux system.
We should not criticize those companies for the decision not to attack some of us with some of their weapons. In that, they are doing the right thing. What we should criticize is the implicit remaining threat to attack the rest of us, or attack us with the rest of their weapons. If a company commits not to attack free software with patents, that company will not be a threat to our community.
However, even if some companies do that, others will not. Where software patents exist, no software developer, no computer user is safe from them. So the important issue is to reject software patents in Europe (and elsewhere)--so that these companies, and others, won't have a way to attack people there.
The vote in the European Parliament rejected one attempt to impose software patents on the European Union, but it did not settle the issue. We have driven off the software patent forces, but not defeated them. They will surely attack again in another way.
I didn't hear anyone saying, "Thanks, but we don't want your patents because we are against this system and we don't want to support it or be part of it." Don't you think they should have?
That would have been a foolish and irrational response.
The danger of software patents doesn't come from companies promising not to use certain patents against certain free software packages. Those cases are the exception--the usual case is that the software patent holder has made no promise not to sue the particular developer or user in question. That's what makes software patents dangerous to society.
Getting those promises won't abolish software patents, but rejecting those promises when offered won't do it either. The fact is, nobody has a plausible plan for how to abolish software patents in the U.S., against the power of the megacorporations that dominate the U.S. government. If we keep educating the public, and occasionally boycotting companies that actually sue, maybe someday a situation will arise where we find a way to abolish software patents. But I don't plan to hold my breath waiting for that, and in the meantime, if some companies promise not to sue some free software projects, that is a relief.
Palladium could be a big freedom threat. Do you plan to add any specific clause to GPL 3?
Palladium was Microsoft's name for one particular scheme for Treacherous Computing. There are several such schemes, different in their details, but what they all have in common is that they are designed to make it impossible for you to program your computer to do certain jobs. They are based using on encryption and signatures with keys that are not under your control, so that no program you write will be able to use the same keys.
Microsoft, Intel, and other Treacherous Computing proponents cite various possible applications of losing control over your computer, but this is a distraction, as their principal motive is to make Digital Restrictions Management impossible to break with software. DeCSS is censored in the U.S. and Europe, but at least it exists. Imagine if writing DeCSS were mathematically impossible--that is the world of Treacherous Computing.
DRM is an injustice in itself, but Treacherous Computing also attacks free software as a side effect. Since no one can write free software to access the DRM files, that becomes a job that only proprietary software can do--an artificially imposed problem that can never be solved.
We would consider modifying the GPL to block Treacherous Computing, but it is not clear that any such change could help. Microsoft, Intel and the rest have no need or wish to employ GPL-covered software in direct support of Treacherous Computing; forbidding them to use it that way won't protect us from their plan.
Intel already has Treacherous Computing hardware in the pipeline. Resistance probably has to be aimed at that preventing the success of that hardware.
Is there any plan to contact other vendors (AMD, for example) to persuade them into following a different path?
I think AMD was pressured; I don't know how or by whom, into agreeing to support Treacherous Computing in the first place. And Apple appears to have switched to the x86 architecture specifically so it could support Treacherous Computing. So this road looks difficult--I think one would need to be able to point to a large and organized group of supporters, in order to overcome the pressure from the other side. The free software community is large, but it is not organized toward doing this.
What type of clauses do you plan to add to fight "Treacherous Computing"?
Nothing we put in free software licenses can block the implementation of Treacherous Computing inside a computer, just as nothing we put in free software licenses can prevent the existence of software patents. The only thing our licenses can affect is whether those threats can pervert the nature of our software. Thus, we are thinking about a clause requiring distribution, with the software, of any signature keys necessary to sign the binary so that it can run and fully utilize the machine's facilities. This would prevent the perversion of a supposedly "free" program, which nominally you are allowed to change, except that modified versions are prevented from functioning.
The strategic decision of whether such a requirement is a good idea is very difficult.
Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.