Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
The Linux kernel is under the GPL version 2. Not anything else. Some
individual files are licenceable under v3, but not the kernel in general.
And quite frankly, I don't see that changing. I think it's insane to
require people to make their private signing keys available, for example.
I wouldn't do it. So I don't think the GPL v3 conversion is going to
happen for the kernel, since I personally don't want to convert any of my
code.
I am against personal attacks and this is the first time where it
tooks more than a day before LKML people started with personal
attacks against me. So in principle this is some sort of progress
compared to former times.
(Log in to post comments)
Let's be clear here. Posted Jan 26, 2006 3:55 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Of course, Linus can license the code he has a copyright on however he wants.But according to the draft, keys must only be made available in situations where the code is otherwise unusable (because of DRM). For example, if a device has a digitally signed kernel, and refuses to execute a modified kernel without a proper digital signature, and the modified kernel contains GPLv3 code, means would have to be supplied to allow third parties to make modifications, and sign those modifications, in a way that the modified software would run. However, "Notwithstanding this, a code need not be included in cases where use of the work normally implies the user already has it." So if the usage model is conventional crypto, public-key crypto, or digital signatures, the usage model is that the user has appropriate keys. The language is only intended to be a problem for those who want to use GPLv3 code in devices that are intended to defeat modification by their users. If Linus wants to support Linux use in DRM gadgets, so that the Linux kernel works for "content providers" instead of for users, so be it, but he should say so openly instead of trying to obfuscate with inaccurate statements. However, Linus has another choice he apparently hasn't considered: dual licensing. He can then pick up the added permissions that allow GPLv3 code to link with, for example, Apache-licensed code, but users would still not be obligated to comply with restrictions that are only in GPLv3.
Let's be clear here. Posted Jan 27, 2006 11:11 UTC (Fri) by ekj (guest, #1524) [Link] It's a moot point anyway: Linus can only relicense code that he has copyrigth to. There are literally thousands of copyrigth-holders in the kernel, many of which are at this point unknown, even besides the unknown of who wrote what (not all was all that carefully documented in the old days)Even if Linus wanted it, he couldn't at this point easily create a legal GPLv3 kernel. Noone can. Only the sum total of the contributors can, and that ain't gonna happen. Even if you could find all of them (you can't!) there are lots of them with strong opinions, you can *bet* that a significant portion of them would refuse, even if Linus wasn't among this significant portion (which he is)
Quotes of the week Posted Jan 26, 2006 13:45 UTC (Thu) by gerv (subscriber, #3376) [Link] Linus' conclusion may be correct, but his rationale is all wrong. It's the license headers in the files which specify or do not specify "or any later version", not the copy of the licence in COPYING (which is always the same). You can see this if you read the section "How to apply these terms to your new licence".
If the kernel files say "or any later version" in the header (which some do and some don't), they can be used by anyone under v3 terms. If they don't, they can't.
Gerv
Quotes of the week Posted Jan 26, 2006 22:12 UTC (Thu) by iabervon (subscriber, #722) [Link] He was talking about the large number of files where don't have individual license text on them (and are therefore "all rights reserved", except for the license on the kernel as a whole, which is the COPYING file). The "How to apply these terms to your new program" section is only informational (it's right after the end of the license), and the kernel mostly doesn't follow it, due to the note at the top of COPYING and the fact that most of the kernel files don't explicitly state other terms. Some files do specify GPLv2+, some specify BSD, some specify weird other things. But, for example, kernel/fork.c is copyright Linus and doesn't grant any license by itself.
Quotes of the week Posted Feb 2, 2006 15:39 UTC (Thu) by forthy (guest, #1525) [Link] The "GPL v2 only" note in the COPYING file of Linux did not occur before 2.4.0 (I checked with a cvsweb repository of the kernel sources). So how comes that Linus could alter the license back then (GPL defaults to "or any later version" unless explicitely specified otherwise)? IMHO, this statement is null and void. He didn't include it with the consensus of the other developers, therefore he can take it out without the consensus of the other developers, as well, as it never was valid. I don't think Linus' statements of the week on top of the kernel COPYING ever could work out in court.
Quotes of the week Posted Feb 9, 2006 2:45 UTC (Thu) by arcticwolf (guest, #8341) [Link] He could not alter the license back then; but that's irrelevant, since he did not do so. For an explanation of what he did and didn't do, read what he wrote. It's all in there.
Copyright notice by file Posted Jan 30, 2006 3:07 UTC (Mon) by xoddam (subscriber, #2322) [Link] The file is a purely arbitrary division -- copyright in a chunk of codeis not going to be awarded or enforced based principally on the notice at the top of the file. Such things are just as easy to alter as the code itself, after all. Sometimes a chunk of code is clearly all from one source and in those instances it is easy to determine who has copyright in it and -- in the case where an entire file is from a non-collaborative source and has clearly marked copyright and licence notices -- easy to determine what licence conditions the copyright holder granted. Much of the core of the Linux kernel is in files which were originally clearly copyright Linus (dating either from the earliest days of the kernel or from the time of Linus' Alpha port), and have subsequently been patched so ubiquitously by so many contributors that the copyright ownership can only meaningfully be considered 'collective'. But the corollary to this is that all contributors made their contributions on Linus' terms, which means under Version 2 of the GPL as has been made abundantly clear for many years. For these heavily-worked pieces of code, the notices at the tops of the files matter not one jot in the face of repeated clarifications. *All* contributors are bound by this licence for development work conducted collaboratively via lkml. The *only* exceptions are work which has clearly been contributed whole by a particular copyright holder from a different source; then the copyright holder has every right to offer alternative licence terms.
Keys, versions, dual licensing Posted Jan 26, 2006 19:40 UTC (Thu) by kmself (subscriber, #11565) [Link] Count me as among those very confused by Linus's "it's insane to require people to make their private signing keys available" comment. If he's drawing that conclusion from the v3 draft section 1, I believe he's misinterpreted it. Is anyone aware of backstory or discussion on this? As some of the LKML discussion makes clear, allowed license versions are governed by explanetory text plus section 9 plus the version of the license mentioned as applied to the work. So, the Linux kernel doesn't include the "or at your option, any later version" language suggested by the GPL, but it does specify the GNU GPL version 2 in the COPYING file of the kernel source, so the kernel is governed by GPL v2 and won't automatically migrate to subsequent versions. I pointed out to a national reporter a few weeks ago that while GPL v3 would not by default apply to the kernel as a whole, it would be very possible for developers to start dual-licensing their submissions (and relicensing old submissions) under both GPL v2 and v3, leading at least to a largely v3 kernel if not one wholly licensed under v3. Linus's comments support this view.
Keys, versions, dual licensing Posted Feb 6, 2006 19:56 UTC (Mon) by garick (guest, #33218) [Link] I don't know linus's reasons, but I can see potental issues with TPM andthe linux kernel at least. What if I want to make a voting machine that is tamperproof using TPM? Who would need to get copies of the source code and _key_ for that kernel? Each voting district? TPM has real potental uses (IMO) for special purpose systems. I think there is value to having a system where niether the developer nor the purchaser have the key, but only a trusted third party (like a commerical CA)
For those who have never worked with smartcards, they provide this kind of
As I read it a bank card applet couldn't be GPLv3, because when you are
I understand the DRM fears, but I'd don't thow out a whole yet-to-mature
DRM will fail. Eventually the RIAA will lose that battle or just plain be
I think it'd be a shame to doom any unborn FOSS GPL'd TPM systems.
Better voting machines, safer banks, not right away, but someday...
What's with Joerg Schilling and the kernel developers? Posted Jan 27, 2006 8:31 UTC (Fri) by mmarkov (guest, #4978) [Link] I tried to follow the argument on lkml, but the technicalities are totally obscure for me. What is the feature that Linux lacks, according to Joerg?
What's with Joerg Schilling and the kernel developers? Posted Jan 28, 2006 12:56 UTC (Sat) by bronson (subscriber, #4806) [Link] I only scanned it quickly so I'm probably missing some rather important bits... But, as far as I can tell, Joerg and his team dislike enumerating devices using the new sysfs/udev devices. They say that it just has no rigor (and they're right). A device may be /dev/cdwriter on Red Hat, /dev/cdburner on SuSE, /dev/cdrecorder on Debian... They say that to fix this, you need to chuck sysfs/udev out the window and add /dev/scg* transports so that you can go back to enumerating devices using the SCSI protocol from your application.
Vojtech and his team agree that there's no rigor, but they don't see that as a problem. "Just allow the user to set the device from the cd burning application!" And distributions will generally ship with the correct presets. That fixes two things: gets the scsi protocol out of applications, and allows current apps to work with radically different transports in the future.
Personally, I tend to agree with the latter group. I believe that with a bit of time sysfs and udev will settle down, everyone will agree on names, and everything will just work. Adding low level transports to userspace apps... eeeeew. That's so 1980s.
|
|||||||||||||