Kernel developers' position on GPLv3

Posted Sep 22, 2006 17:47 UTC (Fri) by gregkh (subscriber, #8)
In reply to: Kernel developers' position on GPLv3 by alexbk
Parent article: Kernel developers' position on GPLv3

No, our employers had _nothing_ to do with this, and we explicitly signed
this paper saying that we do not represent anyone other than ourselves.

to post comments

Kernel developers' position on GPLv3

Posted Sep 22, 2006 18:05 UTC (Fri) by atai (subscriber, #10977) [Link] (15 responses)

This article looks very like the "conclusion statement" from a lawyer in a trial arguing for a particular side. Pure kernel developers probably will not make statements in this manner.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 18:07 UTC (Fri) by gregkh (subscriber, #8) [Link] (11 responses)

Are you saying that we did not write this ourselves?

Have we done anything to make you doubt our ability to write something
like this ourselves?

I have an inbox here full of email proving that we did this, I don't
understand why you would think otherwise.

Why this route?

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

Have you submitted these comments through gplv3.fsf.org ? If not, why not?

(Keeping in mind that the issues reported there seem to be being listened to)

One important design feature of the gplv3.fsf.org comment portal is that it requires people to highlight what words and sentences their comments relate to. In public discussions, people can say "I/We don't like the patent bits", but at the portal, you have to say what words you disagree with. The downside is that commenters have to have actually read the draft, and they actually have to have a possibly-valid comment. It sounds like you have read the draft, so this isn't a problem in this case. The upside is that discussion starts from fact and details instead of general ideas.

One example is the length. For 15 years, people said "make it shorter", but when it is opened for revision, how many pointed out words that could be removed? Few or none.

Please, do submit your comments through gplv3.fsf.org, not just slashdot and lwn.net

Why this route?

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

Minor nit - one of the weak things about the GPLv3 comment portal (unless they've changed it recently) is that you have to comment on a text segment no longer than one sentence, which is often narrower than the arc of a particular thought within the license.

It's not well-designed for raising philosophical or holistic objections.

commenting

Posted Sep 24, 2006 1:53 UTC (Sun) by coriordan (guest, #7544) [Link]

To comment on a whole section, attach your comment to the section title.

Why this route?

Posted Sep 25, 2006 15:21 UTC (Mon) by mingo (subscriber, #31122) [Link] (7 responses)

Have you submitted these comments through gplv3.fsf.org ? If not, why not?

btw., this i see as another problem. The GPLv3 process is fundamentally undemocratic: the President of the FSF retains all rights to set the language of the GPLv3.

furthermore, Linus has stated that he has sent his comments to both Richard Stallman and to Eben Moglen directly, and that they were ignored, see this Groklaw comment of Linus:

Yes. I have emailed both rms and Eben directly. They know my position. They don't care. If they told you otherwise, they lied. Get over it.

Why this route?

Posted Sep 25, 2006 16:07 UTC (Mon) by alexbk (subscriber, #37839) [Link] (4 responses)

Wow, is that anonymous frustrated fella really Linus? Someone should really veryfy this. Posts like http://www.groklaw.net/comment.php?mode=display&sid=2... are borderline insults worthy of someone like ESR, and don't sound like Linus at all.

He's believed to be Linus

Posted Sep 25, 2006 20:24 UTC (Mon) by coriordan (guest, #7544) [Link]

PJ checked during a previous discussion (I guess she emailed him), and he was indeed Linus.

Why this route?

Posted Sep 25, 2006 23:24 UTC (Mon) by h2 (guest, #27965) [Link] (2 responses)

Exactly what I thought when I read that groklaw thread, but it became increasingly clear that the shrill, near hysterical, almost totally irrational voice I was reading was in fact Linus himself. If he was aiming to impress anyone with his arguments or clear reasoning he certainly failed in my case, and I used to respect him much more than I do now, after reading that thread. He showed a bit too much there if you ask me, and the fact that he had bad enough judgement to do that in the first place is also revealing.

I remember well a different Linus, who refused to take credit for the kernel, laughingly saying he just managed to get that credit by absorbing great work from others. That was a Linus I respected, this new Linus 2.0 is one I could happily never read another word from again.

The fact that the people he works with most closely agree with his position should not be surprising, and should not be considered grounds for discussion in the first place. What else would you expect? Of course the core guys more or less see eye to eye with Linus, otherwise they wouldn't be core guys. This has no more significance than polling a position at the democratic or republican or libertarian national political convention then using the results to show broad support for your position.

Why this route?

Posted Sep 26, 2006 1:19 UTC (Tue) by bronson (guest, #4806) [Link] (1 responses)

It shows broad support *among kernel developers* for Linus's position. And that certainly sounds significant to me.

depends on how seriously it was taken

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

Well, that depends on how seriously the voters took the poll.

Why this route?

Posted Sep 25, 2006 19:08 UTC (Mon) by alexbk (subscriber, #37839) [Link]

The core of his argument seems to be that the kernel development is based on "fair trade" principle
and not on "freedom for the users" one. But fair trade can be interpreted in many ways, and I don't
see why his interpretation - "I give you source code, you give me your changes" is more valid than "I
give you the right to use my source code with your hardware, you give me the same right".

Why RMS?

Posted Sep 25, 2006 21:38 UTC (Mon) by coriordan (guest, #7544) [Link]

You've raised two new issues there, but I guess the answer to my question is no, you haven't submitted your comments via the comment system. I think it would be useful if you did. Comments submitted there are reviewed by a committee of lawyers, a committee of large businesses, a committee of free software projects, and a committee of general developers who'd shown an interest. Between the four committees, there are about 130 people.

For the two separate issues you raised. Richard has acknowledged that the first needs work. He replied to questions on this in Italy in March ("... We're going to have to replace me somehow, sooner or later.") and in Barcelona in June ("...Most of our community does not appreciate freedom ... So, if we wanted to do a good job of protecting freedom with version 3 of the GNU GPL, we could not let the majority of our users decide what goes into that licence..."). A vote isn't the right thing to do (just like a vote is not the best way to land a plane or do surgery), but yes, we can't always have Richard making the decisions. We need to build a committee which can be trusted to update the GPL in the spirit of copyleft.

For your second issue, it's hard to know what Linus has been saying to Richard. It would be easier to know about Linus' comments if he submitted comments to the public gplv3.fsf.org portal, attached them to the actual licence text, and got them discussed by the committees. And the same goes equally for the other Linux developers and members of other free software projects.

People who are trying to improve GPLv3 can take some hints from the above letter, but it would be far more useful if that letter also had some comments on the text of draft 2.

For example, section 5.2 of the above letter recommends removing section 7b of GPLv3 draft 2 because of a certain list of problems. These problems are mostly known, but section 7b has the benefit of making GPLv3 compatible with more free software licences, such as the Apache licence. Licence incompatibility is a pointless bureaucratic impediment for free software developers, so removing incompatibility should be tried.

So, while highlighting the problems is useful, we should also look at each problem and decide how to minimise it and how much of a problem it is, so hopefully we can fix the problem, or fix it sufficiently, and keep the benefits. This discussion is easiest to have inside the consultation system, instead of via the community and mainstream news outlets.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 18:48 UTC (Fri) by jejb (subscriber, #6654) [Link]

I can clarify this, I suppose. I wrote the first draft of the document and maintained the subsequent updates and rewrites via feedback from the group. No lawyer anywhere had input into our process. Except in one case, which was to answer a specific legal concern raised by the group: Could releasing this document compromise the ability of people to enforce the current GPLv2 on kernel code. The answer was a qualified (as you would expect) no.

James

Kernel developers' position on GPLv3

Posted Sep 23, 2006 3:10 UTC (Sat) by jwboyer (guest, #23296) [Link] (1 responses)

The ability to use large words to form coherent sentences, which in turn form well written and carefully thought out ideals is not soley the talent of lawyers. On the contrary, since this _is_ such a well written and concise document, I would be much more suspicous if someone said a lawyer _did_ participate.

Questioning someone's integrity by stereo-typing kernel developers as hackers that only grok code is the mark of a simpleton.

(In layman's term, I just called you a moron)

Kernel developers' position on GPLv3

Posted Sep 23, 2006 7:53 UTC (Sat) by beoba (guest, #16942) [Link]

Yes, calling commenters morons is an excellent way to maintain a civil discussion of the issues at hand. Thank you for your valuable input.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 18:11 UTC (Fri) by cventers (guest, #31465) [Link]

Greg,

Thank you for participating in this. I'm still not sure where I stand on
GPLv3 personally - I find arguments on both sides of the fence
convincing.

I was really concerned, though, because it seemed like people really
didn't understand why Linus wasn't happy with the license, but it also
seemed like there wasn't much communication going on between Linux and
the FSF on this issue. This document does a great deal to help.

Bravo, keep up the good work.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 19:12 UTC (Fri) by alonso (guest, #2828) [Link] (30 responses)

Hi Greg, first of all thank you for your hard work!
I really don't understand your pro DRM position, why do you think that devices like tivo are good? Do you really think that having the source code of the kernel without the ability to run it on a device will boost or is usefull for linux?
The freedom argument is pointless, why GPLv2 is better than BSD? Because GPLv2 limit freedom of developer, they have to release modification of the code.
A big thank you to every Open Source developer.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 19:56 UTC (Fri) by gregkh (subscriber, #8) [Link] (24 responses)

Sorry, but we are not taking a "pro DRM" position here at all. We are
merely stating that the DRM provisions as written in the GPLv3 are nothing
that we thing should be present in a software license.

As for usefulness of having the source code, but being unable to run it on
the machine, that too is something that not all of us agree upon, but we
do agree that again, it should not be something that is dictated by the
license, as it is very different from what the GPLv2 states.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 20:34 UTC (Fri) by ajross (guest, #4563) [Link] (21 responses)

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.

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.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 21:44 UTC (Fri) by alonso (guest, #2828) [Link] (1 responses)

You are right, you are not pro DRM. I would had to write:"I don't understand your position against the anti DRM clause in GPLv3". Now is clear to me that you think that a licence is not the right place to assert this. But where you think is the right place?

GPLv3 allows implementing DRM

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

Keep in mind that GPLv3 does not prohibit DRM, it just protects freedom #1 (the freedom to adapt the software you received to suit your needs) - which enables you to escape from DRM restrictions (if you want to).

Kernel developers' position on GPLv3

Posted Sep 22, 2006 20:02 UTC (Fri) by ibukanov (subscriber, #3942) [Link] (4 responses)

> The freedom argument is pointless, why GPLv2 is better than BSD? Because GPLv2 limit freedom of developer, they have to release modification of the code.

Very well said. I suspect that given the complexity of the current software a source that you can not modify becomes just another form of binary format. So in DRM world GPLv2 applied to a complex software becomes just another form of business-friendly BSD license.

On the other hand I wish FSF would not even mention too-political DRM in GPLv3 and just state instead that for a reasonable amount of money a user can get a box to run code with his modifications.

So if a kernel flash image requires signed code, the user should be able to sign it somehow even if that would require small fee. If the kernel resides in ROM, then the user should be able to get a chip with his modifications even if that requires to pay for another chip.

Kernel developers' position on GPLv3

Posted Sep 22, 2006 20:46 UTC (Fri) by alexbk (subscriber, #37839) [Link] (2 responses)

They only mentioned DRM in the first discussion draft. The second draft changed this to "No
Denying Users' Rights through Technical Measures".

Kernel developers' position on GPLv3

Posted Sep 22, 2006 21:01 UTC (Fri) by ibukanov (subscriber, #3942) [Link] (1 responses)

Thanks, I missed that. It is much better term to use. Still I do not think it covers ROM chips with compiled GPL-ed code, while explicitly says about encryption keys. For example, it prevents a company from offering an option to sign the code through, for example, usb-connected box without revealing the private keys.

Kernel developers' position on GPLv3

Posted Sep 24, 2006 15:40 UTC (Sun) by paulj (subscriber, #341) [Link]

You're wrong, the GPLv3 draft allows vendors to sign code (without revealing the signing keys) just fine.

Kernel developers' position on GPLv3

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

This is a misconception. GPLv2 or v3 only limits the freedom of the distributor. The don't limit the freedom of the developer unless the developers want to become a distributor. The distinction is the most important point in understanding GPLv2 or v3. It seems to me that kernel developers are too busy to really understand this whole issue. I don't know why they are taking a stand anyway.