David Schwartz wrote:
>>Well whoever wrote that seems to have taken the stand that >>the openfirmware package was were the firmware came from. >>The person obviously made a lot of statements without >>bothering checking out the real source. Well it didn't come >>from there, I got it from Alteon under a written agreement >>stating I could distribute the image under the GPL. Since >>the firmware is simply data to Linux, hence keeping it under >>the GPL should be just fine. > > >You cannot distribute anything under the GPL if you cannot >also distribute the source code (the preferred form of the >software for the purpose of making modifications to it). How >Linux sees it is irrelevant. For any piece of software, one >can imagine some processor that can only see it as data. The >GPL doesn't distinguish between processors.
I think this is undisputed.
>Alteon's written agreement notwithstanding, you cannot >distribute the firmware under the GPL if you cannot provide >the preferred form of the firmware for the purpose of making >modifications to it. The firmware does not run on Linux, so >saying "linux sees it as data" is as absurd as saying I can >distribute the x86 Linux kernel without the source because my >calculator can only see it as data. > >You cannot distribute the firmware binary under the GPL. >Period.
This is where you are wrong IMMHO. All that is needed for you to distribute the hexdump blob under the GPL is a declaration from the copyright holder saying "this, to me, is the preferred form for modification of the firmware and hence the source code under the GPL."
>Now, if you were trying to say that you could aggregate the >firmware with another work and distribute the result under >the GPL, the test would be whether the final result is "mere >aggregation" or not. This is a fantastically tricky question >and I don't think anyone on this list could give you >particularly useful guidance.
After a *lot* of discussion, it was deliberated on d-l that this is not that tricky at all, and that the "mere aggregation" clause applies to the combination, for various reasons, with a great degree of safety. (Safer than that, only after court) :-)
>My own opinion is that it's a threshold issue based upon >several factors. For example -- has the firmware been >specifically designed to work with the Linux driver or is it >"generic" firmware? If you can't take the thing you're >distributing (the combined binary) and extract two works from >it (the firmware and the work whose source you are offering), >I cannot see how you can claim it's mere aggregation.
Now, if the firmware was specifically designed to work with the linux driver, than it *is* a derivative work on the kernel as a whole and the source code should be provided upon redistribution as per GPL section 3 etc.
*BUT* this does not preclude Broadcom from stating: "our engineers generated by hand the hex codes that make our hardware work."
>If you believe the linker "merely aggregates" the object code >for the driver with the data for the firmware, I can't see >how you can argue that any linking is anything but mere >aggregation. In neither case can you separate the linked work >into the two separate works and in both cases the linker >provides one work direct access to the other.
No-one is saying that the linker "merely aggregates" object code for the driver; what *is* being said is: in the case of firmware, especially if the firmware is neither a derivative work on the kernel (see above) nor the firmware includes part of the kernel (duh), it is *fairly* *safe* to consider the intermixing of firmware bytes with kernel binary image bytes in an ELF object file as mere aggregation.
>If you only distribute the source to the driver and don't put >a GPL notice in the files that contain the firmware data, I >think you're okay. I think you're asking for trouble if you >distribute a combined compiled/linked driver.
Disagreed.
>DS
HTH,
Massa
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
