Kernel developers' position on GPLv3

Posted Sep 22, 2006 20:34 UTC (Fri) by ajross (guest, #4563)
In reply to: Kernel developers' position on GPLv3 by gregkh
Parent article: Kernel developers' position on GPLv3

I think, though, that a lot of the resistance you are seeing here is because this sort of logic ("we don't think software licenses should restrict freedom") sounds very much like what we all heard 8-10 years ago from the BSD crowd about the GPLv2. A BSD-style license, as we all remember, is "more free" than the GPL because it doesn't have the awful "viral" clause.

This analysis failed not only from semantic ambiguity (confusing the "freedom of action" of a single user with what I guess would be called the "freedom of opportunity" of the user base as a whole) but because it was actually wrong in a practical sense. The freedoms of the more permissive licenses led ultimately to a bunch of firewalled work behind closed doors to which the community lacked access (c.f. BSDI, or the vendor-enhanced X servers of the mid-90's, or all the fancy features of early IP networking hardware). The GPLv2 kept all this stuff on "our" side of the firewall, to all of our benefit. The end result is that Linux is a much more successful platform in the world of shipping, revenue-producing products; which is exactly the opposite result from what the "BSD freedom" argument predicted.

So I guess the real question (and I swear I'm not trolling here!) is this: how sure are you that this isn't just a reactionary response? Are you absolutely sure the "freedoms" you're espousing here are really the ones that are important to retain, or is it just that you like what you have, distrust the FSF, and basically fear change?

I don't have a really clear answer myself, but I'll be honest: the "freedom" to prevent people from running modified software on hardware I designed to run GPL software I got from someone else doesn't really sound like "freedom" to my ears. Like most of you, I read RMS's pronouncements and admonitions and roll my eyes more often than not. But I read the GPLv3 and like what I see.

to post comments

An excellent point

Posted Sep 22, 2006 22:09 UTC (Fri) by emk (subscriber, #1128) [Link] (1 responses)

I agree that this new feature of GPLv3 is keeping with the spirit of the GPL license (as opposed to the BSD license). Whether it can be implemented cleanly, I don't know, but I think the FSF's basic desire is philosophically reasonable and a boon to users.

An excellent point

Posted Sep 23, 2006 2:38 UTC (Sat) by coriordan (guest, #7544) [Link]

Eben Moglen explalined this well in India. The new DRM clause just says that you can't use technology to add restrictions that the licence doesn't allow.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 22:09 UTC (Fri) by sepreece (guest, #19270) [Link] (18 responses)

I don't think anyone would disagree that the "must release source code" requirement is central to the success of Linux and other FOSS software. I think almost everyone agrees that it an essential element of fairness. It's also utterly essential to the success that FOSS has seen.

I believe the "viral" nature of GPL would probably get a less unanimous response. It seems like essential fairness that "if you use a modified version of my code, you must give back your changes", but the argument for copyleft is less clearly essential to fairness. I would not, personally, claim that fairness required that if you use my code in your product, you need to also release your own code that just uses my code. If the use is just around exposed APIs, I tend to think it's just use and shouldn't require release. I tend to think that copyleft has also been less critical to the success of FOSS - that there probably are some projects that started because they had to, in order to use GPLed code, but I think the successful FOSS projects exist and flourished because somebody wanted a particular kind of software "thing" and felt that FOSS development was a good way to get a group working together to grow it. That doesn't require copyleft.

The anti-Tivoization argument is even less broadly accepted (as the kernel developers show here). I believe it extends the notion of the first freedom unacceptably and without any roots in essential fairness. Nor is it essential to the future success of FOSS. In fact, I continue to believe that the anti-Tivoization/anti-DRM clauses will work against future success of FOSS by fragmenting the community and by driving some work, some developers, and a significant amount of investment, to a separate community around GPLv2 or another free license.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 22:22 UTC (Fri) by emk (subscriber, #1128) [Link] (3 responses)

Well, there was a recent interview with a founding NetBSD developer that the BSD license had caused much derivative work to disappear behind propriety walls. Similarly, much of the work on X11 from the early 80s to the mid-90s never made it back into the public code base.

So I think the pro-GPL arguments are worth listening to.

Kernel developers' position on GPLv3

Posted Sep 23, 2006 1:28 UTC (Sat) by sepreece (guest, #19270) [Link] (2 responses)

Nobody is arguing against the GPL! The question is whether the changes in the proposed next version of the GPL improve the license or not.

Kernel developers' position on GPLv3

Posted Sep 25, 2006 9:46 UTC (Mon) by anandsr21 (guest, #28562) [Link] (1 responses)

But this is a GPL argument. The only difference is whether you are allowed to use technical measures to defeat the provisions of GPL. Tivoisation is merely circumventing the GPL using DRM.

I am not sure if you know what the intent behind GPL is. I would like to remind you of the story of the Printer, and ask you to think about the Tivo again. It should be clear in a moment.

Kernel developers' position on GPLv3

Posted Sep 25, 2006 14:42 UTC (Mon) by sepreece (guest, #19270) [Link]

The kernel developers [and some of us others] seem to disagree with your contention that Tivoization violates the GPLv2. I know SOME people claim that it does, and that SOME others claim that it violates the spirit but not the letter, but there are quite a few of us who say that there is nothing in GPLv2 that requires that you be able to install on the same device.

I do know the story of the printer firmware and RMS's belief that devices should be upgradeable, I just disagree with them.

I think that there is enough opposition to this broadening that it will fragment the community and reduce its influence (and its ability to compete with, for instance, Microsoft) if GPLv3 continues in the directions taken in the current draft.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 22:27 UTC (Fri) by ajross (guest, #4563) [Link] (13 responses)

The anti-Tivoization argument is even less broadly accepted (as the kernel developers show here). I believe it extends the notion of the first freedom unacceptably and without any roots in essential fairness.

This is the part that I just don't see. Stated as simply as possible, the philosophy behind the GPL says: "You can use this, as long as you share it." This is, to me (and maybe you see the license in a different moral light) a really, painfully obvious candidate for any definition of "essential fairness". I give it to you, so you need to be willing to give it to others. Sounds fair to me, no?

But the DRM use case breaks down here. A DRM-encumbered device clearly is not "sharing" the code in any meaningful way. None at all. But it is, at least technically, within the scope of the license as written. So the FSF has amended the license to prevent this particular loophole. What I just can't understand is how opposition to this change is being explained as support of "freedom" or "fairness". This doesn't seem like "freedom" or "fairness" to me at all. If I had to pick a word for it, it would be: "cheating".

I see a lot more validity in the practical arguments that the additions to the GPLv3 are too large, or too complicated, or too risky. But people (important people, even) are arguing here that those changes are unfair and unfree, and I'm at a total loss to understand their logic.

Kernel developers' position on GPLv3

Posted Sep 23, 2006 0:25 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link] (6 responses)

"A DRM-encumbered device clearly is not "sharing" the code in any meaningful way. None at all."

From the point of view of the software developers the code is shared as normal. The device manufacturer takes the GPL code, modifies it, makes the modifications available to everybody and then incorporates it in the device.

It is only from the end users point of view that the company appears to be breaching the philosophy of the GPL since although the user has the source code and can use it in various ways (i.e. build their own device etc.etc.) they cannot reload it into the Tivo (or other hardware) and get it to run.

The GPL3 I believe therefore introduces the concepts of limits on the use of the software which were not present before. In doing this does it not become incompatible with version 2 thereby causing the fragmentation and great difficulties for distributions that the authors of this paper mention?

Personally I would be very happy if the GPL v3 was finalised and adopted by 98% of current GPL 2 projects. But if that is not going to happen and the new license causes the difficulties that the authors mention then it is not worth the cost.

In the circumstances I do think that a GPL3 which contained some clarifications and wording adjustments for the sake of internationalising the license would be worthwhile. BUT only if it was fully compatible with GPL 2 and therefore (a) it wouldn't matter if a particular project didn't move to GPL3 and (2) there would be no reason for any project not to move to GPL 2.

What part of the draft is that?

Posted Sep 23, 2006 2:44 UTC (Sat) by coriordan (guest, #7544) [Link] (5 responses)

The goal of the GPL is to ensure that when someone gets the software, they are free to help themselves and to cooperate with others. When someone gets a Tivo, they might want to remove the spyware or add a "copy" button. Unfortunately, to the user of a Tivo, the source is viewable, but cannot be modified to make the computer (the Tivo) do what they want.

More importantly, could you say what part of the draft introduces use limits?

All it says is that Tivo is free to modify the software to suit their needs, and I'm free to modify the software to suit my needs after I get it from them.

What part of the draft is that?

Posted Sep 23, 2006 8:45 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link] (4 responses)

"More importantly, could you say what part of the draft introduces use limits?"

Quite simply the use limits are "you may not use this software in a device which will not allow modified software to be run".

It's similar to other use limits that are sometimes discussed, and rejected, such as "you may not use this software in a nuclear warhead".

GPLv3 doesn't say that

Posted Sep 23, 2006 12:24 UTC (Sat) by coriordan (guest, #7544) [Link] (3 responses)

Hmm, as I thought. You are complaining about something you think is in GPLv3, but which is not in GPLv3. Maybe people have these misconceptions because the media has oversimplified the issue.

GPLv3 allows people to implement DRM. I can configure my kernel to only run binaries signed by me, and then sign all the binaries on my system, and then I will be well protected against viruses. This is allowed by GPLv3 (and v2).

What GPLv3 forbids is that _you_ distribute the software in a way that _you_ have the ability to modify the software but _I_ don't. When you distribute (not use) the software, you are obliged to do so in a way that passes on the freedom for the recipient to adapt the software to do what they want.

So there is no use restriction. I think RMS explained this well in his February talk at FOSDEM, and recently in Bangalore, he explained it and Eben Moglen explained it.

It's important that people read the draft and then attach comments to the actual text (by going to gplv3.fsf.org) instead of debating things that don't exist.

GPLv3 doesn't say that

Posted Sep 23, 2006 12:55 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link] (2 responses)

I said:"you may not use this software in a device which will not allow modified software to be run".

You said:"there is no use restriction."

Stallman said:"The basic change is that if someone, say the manufacturer of the Tivo, provides you a binary, then he must, as part of the requirement to provide the source code, give you whatever it takes to authorise your version so it will run."

Therefore the use restriction is that the manufacturer cannot use the GPL code in a device for which they are not willing to give you the signing key.

I support this position in principle, however if the practical effects are as suggested by the kernel developers in their letter, I do not believe that the risk to the GPL system is warranted.

GPLv3 doesn't say that

Posted Sep 23, 2006 13:18 UTC (Sat) by coriordan (guest, #7544) [Link]

The condition/requirement/restriction is on distribution, not use. Any recipient of the software, including a device manufacturer, can use (as in, run, execute) the software without restriction. When they distribute (give a copy to someone else), they have requirements.

v2 said that requirements were to make the source code available, and to make the recipient aware of the licence. v3 adds to this list that there is also a requirement to make sure that if there are technical measures which might prohibit modification, then the recipient must have what is necessary to avoid being restricted by that.

This is why I say there is no use requirements. If you define "use" in a really broad way that includes distribution, then there are some relevent restrictions in v3, but this is also true of v2.

GPLv3 doesn't say that

Posted Sep 27, 2006 13:52 UTC (Wed) by bignose (subscriber, #40) [Link]

> the use restriction is that the manufacturer cannot use the GPL code in a
> device for which they are not willing to give you the signing key.

They can *use* the software in that device, unconditionally. They may also (under the terms of the current GPLv3 draft) *redistribute* that software to you, with the condition that they grant you all the freedoms to the software they received.

Once you receive that software under the terms of the GPLv3, you too are free to use the software in that device unconditionally, just as the party you received it from was free to do so.

No-one's use of the software is restricted by any conditions in the (current draft of the) GPLv3.

Kernel developers' position on GPLv3

Posted Sep 23, 2006 1:42 UTC (Sat) by sepreece (guest, #19270) [Link] (5 responses)

"This is the part that I just don't see. Stated as simply as possible, the philosophy behind the GPL says: "You can use this, as long as you share it." This is, to me (and maybe you see the license in a different moral light) a really, painfully obvious candidate for any definition of "essential fairness". I give it to you, so you need to be willing to give it to others. Sounds fair to me, no?"

Device manufacturers (well, many of them) are perfectly happy to share their work with you. But, in some cases they feel they cannot let you modify the actual device. You can still use the technology they developed, even to build a competing device. Many of think that is the essential fairness. The question of whether the device is modifiable should be a market issue, not a license issue.

Note that your argument about an encumbered device "not sharing" apparently doesn't convince the FSF, either, since they say it's perfectly OK to build a non-modifiable (ROM-based) device with free software, and it's hard to see how that would be "sharing" other than by source-code sharing.

Kernel developers' position on GPLv3

Posted Sep 23, 2006 14:45 UTC (Sat) by Kluge (subscriber, #2881) [Link] (4 responses)

I think the FSF's position is that the creator of the device shouldn't have any rights regarding the software that they don't also give to the users. In the case of a ROM, neither the manufacturer nor the user can modify the software, so it's still fair. But if, as in the case of Tivo, the software can be modified (and is, to upgrade the DRM) by the manufacturer, then it should also be modifiable by the user.

Sounds fair to me.

Kernel developers' position on GPLv3

Posted Sep 23, 2006 18:46 UTC (Sat) by sepreece (guest, #19270) [Link] (3 responses)

This argument about "can't reserve any rights that you don't pass on" seems to be to be contrived - that is, they have constructed an argument for their position that is not rooted in the four freedoms they claim to be protecting.

Kernel developers' position on GPLv3

Posted Sep 25, 2006 9:54 UTC (Mon) by anandsr21 (guest, #28562) [Link] (2 responses)

Which one of the freedom do you claim it violates?

To me it seems that it is inline with the general philosophy that distributors have obligations. The authors any way have all the freedoms, unless they use GPL and become distributors ;-).

Kernel developers' position on GPLv3

Posted Sep 25, 2006 14:47 UTC (Mon) by sepreece (guest, #19270) [Link] (1 responses)

I did not say it "violates" any of the four freedoms, just that it didn't derive from any of them.

That is, in logic, saying "A does not imply B" is not at all the same as saying "B implies not A".

It derives from freedom #1

Posted Sep 26, 2006 2:23 UTC (Tue) by coriordan (guest, #7544) [Link]

The need for the DRM-related words in the licence is derived from freedom #1: "The freedom to study how the program works, and adapt it to your needs".

If I get the software as part of a hardware+software system, but after modifying the software the hardware transforms into a brick, then I have not been given freedom #1 in a meaningful sense. It's like pulling the trigger and out pops a flag saying "BANG".

In the case of the Tivo, I might want to remove the spyware and add a "copy to my computer" button. Making these modifications and then running my new version of the software on anything but my Tivo will not fulfil my needs.

In the 1990s, to ensure that freedom #1 survived the distribution chain, the GPL had to require people to published the source of any published binaries. In 2006, the GPL also has to require people to give the recipient any codes or passwords that the distributor has made necessary to run modified versions of the software.