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

Re: Are BLOBs source code?



Andreas Barth <aba@not.so.argh.org> writes:

> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [041212 21:55]:
>> Andreas Barth <aba@not.so.argh.org> writes:
>
>> > * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [041212 20:25]:
>> >> Compiled in the blob MUST comply to the GPL. The nature of being a
>> >> blob already seems to violate that.
>
>> > Only if the blob is derived from the GPL-code.
>
>> No, always. Compiled in it is part of the binary which is a work
>> derived from the GPLed work. It is like linking to a non GPL library.
>> 
>> Only seperate (e.g. in an initrd) you can say it is just an
>> aggregation of works.
>
> Why should elf-aggregation always mean to be part of a derived code, and
> fs-level aggregation mean that not? Even e.g. Linus writes that there
> _are_ examples where elf-aggregation does not mean a derived work (well,
> of course: the default assumptation is that it is derived, but it could
> be proven otherwise).

Which will be extremly hard with the driver code itself having the
'char data[] = { ... }' in its source files.

As a simple test for aggregation I would ask: Can you remove the
seperate parts? Does the remainder stil work?

Do you have a program that can remove firmware from an vmlinuz file?
An initrd you can mount and delete the file or copy all but the file
and make a new image.

In the case of a module things are maybe less clear. The module would
be on the initrd so it is just an aggregation imho.

But the module as a whole (driver+firmware) would be as non-free as
the firmware and the drivers license must allow it. The driver and
firmware then can't be part of the linux source package or it wouldn't
be an aggregation.

> Cheers,
> Andi

MfG
        Goswin



Reply to: