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

Re: LCC and blobs



Bruce Perens <bruce@perens.com> writes:

> 			 Goswin von Brederlow wrote:
>
>           Apart from being ugly the above is perfectly legal and nothing speaks
> against adding it, _provided_ this is the source. I have actually seen
> GPL sources with such byte sequences in it for cases where the
> toolchain couldn't emit the right opcodes.
>   
>
>
> Yes, but in that case the byte stream was the "preferred form of the work for
> making modifications to it" per the GPL. In the case of a BLOB, that's not the
> 				    case.
> The BLOB code was compiled and assembled at some time, from a source file you
> 				 don't have.
> 				      Thanks
> 				      Bruce

Which is another point in question on some blobs. Is the blob the
source? Was it programmed in hex or with some toolchain?

Your opinion (and I would generaly agree there) would be that the
pseudo source files released are not source as per GPLs definition

| The source code for a work means the preferred form of the work for
| making modifications to it.

but the result of some toolchain. But then the binary blob would be
without source, violating the GPL and thereby be undistributable, not
even in non-free.

So any blob under GPL would have to be purged from Debian.


So lets assume we have a firmware blob under BSD license with a source
file alla

char data[] = { ... };

Does that go to main? Lets check the DFSG.

The only thing in question is if point 2 is fulfilled:

| 2. Source Code
|
| The program must include source code, and must allow distribution in
| source code as well as compiled form.

Which again comes down to "Is the c file source?".

If it is source then it can go to main but not be linked into the
kernel. Given that BSD does not say preferred form of modification or
the like this could be source.

If it is not it can't be in non-free due to license violation.


This sucks more and more.

MfG
        Goswin



Reply to: