Andreas Barth <[EMAIL PROTECTED]> writes:
> * Goswin von Brederlow ([EMAIL PROTECTED]) [041212 21:55]:
>> Andreas Barth <[EMAIL PROTECTED]> writes:
>
>> > * Goswin von Brederlow ([EMAIL PROTECTED]) [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
