Re: linux-2.6: includes nondistributable and non-free binary firmware
Sven Luther wrote:
> On Thu, Aug 17, 2006 at 10:07:42AM -0700, ldoolitt@recycle.lbl.gov 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 <neroden@fastmail.fm>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
Reply to: