Re: linux-2.6: includes nondistributable and non-free binary firmware
On Fri, Aug 18, 2006 at 07:46:56PM -0400, Nathanael Nerode wrote:
> 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.
Thanks,
> 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.
Yes, it is the best thing. We should also ask the BTS admin's to assign new
bugs to kernel pseudo package directly to linux-2.6, this is i believe
possible.
> <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"
I have to disagree on this, between the moment i contacted broadcom, and the
solution, there was at most 2-3 months or so.
> 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.
Well, we didn't really pursue any of the other drivers. That makes 3 out of 3
we really pursued though, and they can all be handled in parallel.
The real problem is stuff like the acenic driver, where the copyright holder
is lost. Altough we could try to gather a position statement by various
possible copyright holders, where they claim not to hold copyright of this
part, or something and then add this and wait until someone complains, showing
our good faith and best effort, and then asking whoever complains to clarify
the copyright.
> >> 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
Err, i was laughed at by some people here, the LKML was indeed a bit more
hostile than that.
> 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 will be a GR one way or another rather soon, just be vigilant that there
is an ammendment which fits you well, since i have seen some pretty
inacceptable propositions.
> 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.)
It is just the ftp-master's call and a question of the risk encoured by
debian, rather than a principle thing though. and i believe the risk here is
pretty low, and the benefit high. but then you have to compare it with the
miboot and its apple boot sector.
> > 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.
non-free firmwares are here to stay, and will become more numerous in the
future.
> 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
Ok.
> * the greater attention to licensing since the SCO cases: material with
> licensing of questionable distributability doesn't get in as often any more
ok.
> * 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.
indeed.
> (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.)
this is actually the most case of those problematic cases i would attribute it
to ignorance rather than incompetence though.
> <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"? ;-)
This has been waived for etch, and it now is "we will release on december 6
2006".
Friendly,
Sven Luther
Reply to: