Sven Luther wrote: > On Thu, Aug 17, 2006 at 10:07:42AM -0700, [EMAIL PROTECTED] wrote: >> Maks - >> >> On Thu, Aug 17, 2006 at 06:05:30PM +0200, maximilian attems wrote: >> > > Something about [bug #242866] seems broken, however, >> > > because RC-buggy linux-2.6 packages keep making it into >> > > testing. Is it obvious how to keep this from happening, >> > > without starting a new bug attached to linux-2.6? >> > >> > if you feel like it reassign it,
Bugs merged and assigned to linux-2.6. I think the "kernel" pseudo-package is mostly obsolete: it should be reserved for bugs affecting multiple kernels. This bug doesn't affect freebsd, hurd, etc. It does affect linux-2.4 and linux-2.2, but those are scheduled for removal before etch anyway. So actually, I'd like to suggest running through the bugs against 'kernel' and reassigning them to linux-2.6 or closing them as appropriate. Does that seem like a reasonable thing to do when I'm bored and not feeling up to programming, or would there be some complaint about it. <snip> >> > anyway if you want to improve the legal situtation use: >> > http://wiki.debian.org/KernelFirmwareLicensing >> > dilinger succeeded in various firmware relicensing >> > thanks to his quest to the vendors. feel free to pick up. Broadcom tg3 relicensing alone took over two years. This is a lovely thing to do, and I am *very very* impressed with dilinger's diligence and his success (I tried but failed to contact anyone at Broadcom). "dgrs" and "qla2xxx" are the only other drivers he had *any* success with, according to the wiki page. I am afraid we need a shorter-term solution. >> For each offending file, there are three possible solutions: >> 1. Get the author to release source code under a DFSG-free license >> 2. Move the firmware to non-free, patching the driver to use >> request_firmware() >> 3. Delete the driver and firmware entirely. > 4. Move the whole friver to non-free, without major patching. > 5. Reverse engineer the needed firmware, and create a trully free > driver. > >> AFAIK, the best outcome yet from the relicensing discussions >> on http://wiki.debian.org/KernelFirmwareLicensing is to properly >> permit the redistribution of the binary, without source code. > > Indeed, but even that was laughed at back then when we started at it, and > you should have seen the reaction of LKML when i mentioned it there. Not to mention the reaction I originally got from the netdev maintainers, which was rather more hostile than being 'laughed at'. I think a lot of people genuinely believed that you could license an unsourced binary under the GPL.... I can't imagine *why* they believed that, though. <snip> >> That's fine for debian non-free, and a necessary step for making >> option (2) above work properly. Until and unless the entire >> Linux kernel is moved to non-free, such relicensing doesn't >> solve the fundamental bug. > > Indeed. > >> I agree that option (3) is bad, but I still recommend it for >> the short term. It's the quickest path to a legal and > > For the short term, 4. is a better solution. Right. If a driver really can't build out-of-tree comfortably, (4) may not be feasible and (3) or (2) may be necessary, but let's cross that bridge if we come to it. What can I do to help with (4)? :-) >> SC-conforming Linux release, and it will bring people out >> of the closet to volunteer to work on (2). I think (2) >> is the actual goal, but maybe not one that can be finished >> before the proposed etch freeze -- especially since most >> of the blobs need to be relicensed before they can be made >> part of firmware-nonfree. > > Indeed, which is because we could also consider : > > 6. Pass another GR to allow debian/etch to release as is, provided we If the GR includes a commitment to include a statement regarding this violation of the SC in the *release notes*, then I would be satisfied with this from a freeness point of view: at least Debian would be advertising its failure to live up to the SC. If there is no such commitment, I would expect to see the same charade for etch+1. There's also a problem with Sven's analysis of option (6) relative to options (4) and (2). >From a legal point of view, distributing the 'undistributable' (mislicensed) blobs in 'main' and distributing them in 'non-free' is equally bad. If it's OK to distribute them in the kernel package, it's OK to distribute them in 'firmware-nonfree'. It is up to the ftpmasters, the release team, and or the DPL to decide whether they are comfortable with it or not. If they are, then the blobs can be put in firmware-nonfree and (4) is perfectly straightforward. If they are not, then the blobs must be removed from the archive. (6) offers no advantage over (4) with regard to this. (This doesn't affect the non-free blobs which are properly licensed.) > commit to a real effort to solve this for etch+1, or better yet, with > some pro-active wording, which say we will make every effort to solve > this issue, but don't provide timelines and schedules, as upstream will > probably bring more problematic firmware in in unsuspecting ways. Actually, it probably won't bring very many: most of the identified items in 2.6 were already in linux 2.4. I attribute this to three things: * the new "Signed-off-by" scheme required for new submissions to upstream: unattributed material doesn't get in any more * the greater attention to licensing since the SCO cases: material with licensing of questionable distributability doesn't get in as often any more * and most importantly, the presence of firmware loading code, and the upstream policy that new drivers should use it. Not for freeness reasons, but because embedding these large blobs into the kernel image is not a wise use of space, and because it allows the firmware to be updated without changing the kernel. (There are exceptions, blobs which are new to linux-2.6. I believe that most of these merged early in the 2.6 development process, before any of the factors I described above were true. In particular, there are some blobs added to already-blobby drivers; several blobs arrived with the ALSA merge; ttusb-budget arrived before 2.6.0. Howeveer, the cassini blob in arrived in 2.6.14-rc3 in September 2005, the starfire blob arrived in 2.6.13, the bnx2 blob arrived in 2.6.12 in June 2005, and the ti_usb_3410_5052 blobs arrived in 2.6.10 in January 2005. So there are clearly *some* new blobs arriving upstream. The starfire blob is a really sad case of incompetence. The 2.4 driver states that the firmware is nondistributable, and not included. The 2.6 driver includes binary-only firmware, probably due to the work of someone who contacted Adaptec -- but due to incompetence, it's licensed under the GPL, which means that it's nondistributable. AARGH! I wish people would contact someone with a clue before contacting companies... "GPLed" material without source code is equivalent to "you may not distribute this" material.) <snip> > There is not much time before the actual etch release is at hand, which is Do I remember something to the effect of "Debian releases when it is ready"? ;-) -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
