Re: New summary: Binary peripheral software
Herbert Xu wrote:
> Nathanael Nerode <neroden@twcny.rr.com> wrote:
>>
>>> 3. Binary peripheral software is DFSG-non-free.
>>> We distribute it in main because users can't do without it.
>> Seems like I've heard this. Is this Herbert Xu's view?
>
> No.
>
> My view on this issue itself resembles 4 most closely. However,
> I only accept its plan of action with great reluctance.
Thanks for correcting me. :-)
> My order of preference for how this should be resolved are as follows:
>
> 1. Move all kernel packages to non-free.
>
> This pays homage both to our commitment to free software as well as
> our users' needs.
>
> Moving only the drivers affected to non-free is beyond my capacity.
> Someone else will have to invest the time and energy to create such
> a package and keep it up-to-date.
>
> Unfortunately I fear that this is too politically incorrect to be
> viable. I'd love to be proven wrong though.
I think if you moved your kernel packages to non-free someone else would
almost immediately volunteer to provide 'clean' kernel packages in main,
despite their lack of drivers. Haven't there *already* been volunteers?
Now, maybe it would be a disaster to have a big kernel package switchover
right at the end of a release cycle, but at the beginning of the next
release cycle, I'm sure this would happen reasonably smoothly and everyone
would adjust to it.
<snip>
> 3. Delete the affected drivers as they're reported. Stop supporting
> any drivers that contain binary firmware that may get them removed
> should someone report them.
>
> Although this will inconvenience many of our users, this is the only
> course of action that I find to be viable at this point in time.
>
> The reason that I'm stopping any support for these drivers even if
> I don't remove them straight away is that I do not wish to spend
> time to investigate/fix issues only for that effort to be rendered
> useless when the driver is removed from main when someone reports them
> for containing non-free firmware.
>
> The reason that I'm not removing them straight away is a feeble
> attempt on my part to minimise the effect on our users. I know
> quite a number of other drivers that are affected by this issue.
> No I won't be telling you where they are. If you want them all
> to be removed, you'll have to find them yourselves and report
> them.
Sounds like a scavenger hunt. ;-) How about I report all the ones I can
find and you report back intermittently on how many are still out there....
(Joking, joking.)
So I started doing a little audit of the kernel sources. Here are the cases
which look very, very suspicious in terms of being sourceless. There were
others I was (less) suspicous of, but I'll look at those later. I haven't
actually gotten to drivers/, but I went through everything else.
* arch/m68knommu/platform/68328/bootlogo.h
* arch/m68knommu/platform/68EZ328/bootlogo.h
No way is this the source code for a picture. Perhaps it was generated with
scripts/pnmtologo... but unfortunately there's no scripts/logotopnm, so
source would sure be useful.
* arch/ppc/syslib/btext.c
* arch/ppc64/kernel/btext.c
A vga_font, in hex, embedded in a C file. That's not the preferred form for
modification. Where's the source for this font?
Sound is hard to be sure about because there's a fair amount of relatively
legit magic numbers, even long strings of them. So I was very lenient.
* sound/isa/cs423x/pc9801_118_magic.h
This appears to be a magic blob of initialization code. Anyway, no source,
and no evidence of its origins at all.
(The cs4231, cs4232, and cs4236 drivers in the same directory seem to be
fine.)
* sound/isa/sb/sb16_csp_codecs.h
Sourceless microcode, under "GPL".
* sound/oss/724hwmcode.h
* sound/oss/Hwmcode.h
Sourceless microcode, though the comments might indicate they they've
genuinely have been written in hex. However, they appear to have no
permission to distribute. They also don't appear to actually be used by
anything in the kernel. These don't belong in the source package at all,
period, I think.
* sound/oss/maestro3.h
* sound/pci/maestro3.h
assp_kernel_image[] and assp_minisrc_image[] appear to be sourceless
microcode.
* sound/oss/ymfpci_image.h
* sound/pci/ymfpci/ymfpci_image.h
Sourceless microcode. Oh, plus no explicit copyright or permission to
redistribute!
Incidentally, while doing this, I discovered that there are an awful lot of
tables which really *ought* to be autogenerated (or at least have a little
program available to generate them), but aren't and don't. And how many
CRC checksum tables does the kernel really need to contain anyway? :-P
<snip>
>>> 6. Binary peripheral software is DFSG-non-free and, if GPLed,
>>> not even distributable in non-free because the preferred
>>> form for making modifications is not provided.
>>> We don't distribute it at all.
>> Um, yeah, this is my view as well, combined with 4.
>
> I find this view to be pedantic.
Well, yes.... how about this: if we feel sure that the copyright holder
will act sane, we can distribute it. If we don't, however, we don't.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
Reply to: