RMS Previews GPL3 Terms

An anonymous reader writes "In a recent interview, ESR shocked a lot of people when he said, 'We don't need the GPL anymore.' Federico Biancuzzi contacted RMS, founder of the Free Software Movement and initial developer of the GNU system, 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."

Comments

Re:It also appers to mandate s/w features

[albalbo]

Nothing in the GPLv3 is remotely decided. People keep throwing ideas out there to see which fly, some may, most won't.

Re:It also appers to mandate s/w features

[Chris Burke]

Only one feature. The previous paragraph from TFA:

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.

So the "such a command" phrase in the paragraph you quoted does not mean "any command". It refers to a specific command to allow source download of a web-app. It doesn't say whether this command would have to still exist if you didn't use your modification as a web-app.

I'm not sure I like that kind of clause, but it is very different than what you said. You statement made me worry that RMS would do something as foolish as mandate an unchanging feature set and interface, but that isn't true.

Re:GPL3?

[Knuckles]

Talk about hiding in a cave ;) Version 2 was released in June 1991. Version 1 was released in February 1989.

Re:The freedom to confuse

[swillden]

Someone submitting code licensed under GPLv3 to a GPLv2 project would be just as unlikely as someone submitting GPL'd code to a BSDL project, or vice-versa.

I think the more likely "problem" scenario is where a developer on a GPLv2 project wishes to borrow code from a GPLv3 project. However, very few projects are GPLv2... most of them use RMS' recommended language and are therefore best described as GPLv2+, where the '+' means that the code can be released under any later GPL version.

Let me see if I can enumerate the possible scenarios and describe the effect of each.

• GPLv2+ borrows from GPLv3+. No problem, but the specific files imported/modified are under GPLv3+, and the project as a whole is distributed under GPLv3+.
• GPLv2+ borrows from GPLv3. No problem. The result is GPLv3. This might be a bad idea if the GPLv2+ project wishes to be distributable under GPLv4+.
• GPLv2 borrows from GPLv3 or GPLv3+. Can't do it. One side or the other must provide another license.
• GPLv3+ borrows from GPLv2+. No problem.
• GPLv3+ or GPLv3 borrows from GPLv2. Can't do it.
• GPLv3 borrows from GPLv2. Can't do it.
• GPLv3 borrows from GPLv2+. I don't think there's a problem here. The recommended RMS language would seem to allow a user to remove the upgradeability.

That looks bad, but in practice I doubt it will be. Very few projects are GPLv2, and probably even fewer will be GPLv3. The only major project I know of under GPLv2 is the Linux kernel, and it is sufficiently important that it's unlikely to be hampered by the inability to pull in GPLv3[+] code. If a feature is generally desirable in Linux, someone will invest the effort to re-implement it for Linux. In most cases that really has to be done anyway, for technical reasons.

I think that if GPLv3 adds enough value to be compelling, most projects will end up migrating to it. Those, like Linux, that can't will simply continue onward with GPLv2. They may wish they had the GPLv3, though, if the FSF can find some language that handles the patent issue well.