[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are BLOBs source code?



Bruce Perens <bruce@perens.com> writes:

> Goswin von Brederlow wrote:
>
>>Your opinion (and I would generaly agree there) would be that the
>>pseudo source files released are not source as per GPLs definition
>>
>>
> A lot of these BLOBs have been identified as ARM7 code, and generally
> "thumb" (the 8-bit ARM instructions). They come from C or assembly
> language, I bet mostly C. Various people have been able to identify
> the processor that is used, just by comparing the code to well-known
> instruction sets. If they wanted to take the trouble to encrypt the
> BLOB, they'd put FLASH on the card.
>
>>If it is not [source] it can't be in non-free due to license violation.
>>
>>
> That's why I say the BLOB should be in a file rather than the
> driver. Have the driver send the file to the device. It's I/O rather
> than part of the driver. Then, you can consider the license issues of
> the BLOB individually from any other code.
>
>     Thanks
>
>     Bruce

I never talked about blob included in the driver. The question was
about standalone blobs although that hardly matters. A few extra lines
of C code don't change the issue with the blob itself but the blobs
problems infect the driver. I'm all for splitting out firmware.

So how should/can blobs enter Debian at all?

As pure binary file it would have to be in non-free (which is fine)
but then it can't be GPL, BSD or the like. But the blobs I saw so far
had pseudo source files under those licenses.

Under GPL the pseudo source files don't fullfill the "prefered form of
modification" acording to most people. So GPL is ruled out completly.

Is the pseudo source file enough for BSD or Artistic license?


On the same subject but going in a totally different direction:

As you say many blobs have been identified as code. Having pseudo
source files under a free license would give everyone the right to
disassemble the code. Reverese engeneering of the firmware would be
allowed. Allowing pseudo source might be benefitial because it alows
this.

Why not disassemble the code? The makefile could md5sum check the
result to make sure the assembling works right. If the code is C
source the compilers fingerprint should be visible and maybe the code
can be further decompiled. Does debian have no gcc/as for arm7?

Overall I'm pulled in two directions: 1. releaseing obfuscated code to
comply to the license without actualy releaseing source is bad and
2. having a free binary to disassemble and decompile is good.

MfG
        Goswin



Reply to: