Fedora Freedom and linux-libre

[David Woodhouse]

On Mon, 2008-06-16 at 08:15 -0500, Chris Adams wrote:
> Once upon a time, jeff <moe at blagblagblag.org> said:
> > The firmware hasn't always been known to be non-GPL. It was distributed for 
> > years under the GPL, so it *is* GPL, but they are violating the GPL by not 
> > shipping the source code.
> 
> They distributed a string of hex digits in a source file that said it
> was GPL.  Where does it say they have to give you anything else?

Section 3, where it says that you must provide, or offer to provide, the
'complete corresponding machine-readable source code' -- and clarifies
that as follows:

    "The source code for a work means the preferred form of the work for
     making modifications to it.  For an executable work, complete
     source code means all the source code for all modules it contains,
     plus any associated interface definition files, plus the scripts
     used to control compilation and installation of the executable."

So if hex _really_ is the preferred form of the work for making
modifications to it -- for example, if it's just a string of random
bytes, then that's fine. If not, then it is not being distributed under
the terms of the GPL.

I know there are people who'll crawl out of the woodwork now, claiming
that they _prefer_ to edit software in hex form rather than dealing with
what normal people would call the 'source code'. It's amazing what
nonsense people will come up with to justify what they want to believe.

But they'd have to be fairly delusional if they want to claim that hex
arrays really count as the 'the preferred form for modification' for
most¹ of the 'blobs' we have in the kernel. And you'll note that when
companies have lost court cases based on their GPL violations, they
never even _tried_ the "but we _prefer_ editing our kernels in a hex
editor" defence :)

-- 
dwmw2

¹ I say 'most' advisedly. Not _all_ of them, though -- when I went
through the deblob script looking for drivers to convert to
request_firmware(), I did point out a few which I believed to be false
positives, like this kind of stuff in asilantfb.c: 

static struct chips_init_reg chips_init_cr[] =
{
        {0x0c, 0x00},           /* Start address high */
        {0x0d, 0x00},           /* Start address low */
        {0x40, 0x00},           /* Extended Start Address */
        {0x41, 0x00},           /* Extended Start Address */
        {0x14, 0x00},           /* Underline location */
        {0x17, 0xe3},           /* CRT mode control */
        {0x70, 0x00}            /* Interlace control */

I don't see anything wrong with _that_ at all. I've added hex stuff like
that to the kernel and I _do_ believe it to be the preferred form for
making modifications in some cases.