Re: New summary: Binary peripheral software
Hamish Moffatt writes:
> On Mon, Apr 05, 2004 at 08:33:45PM +0200, Andreas Barth wrote:
>> No, that's not acceptable. Because that means that we just can drop
>> DFSG #2. However, if the upstream maintainer (not necessarily the
>> copyright holder) _treats_ the binary as source for his own changes,
>> than it is the source.
>
> Really?
>
> What's to stop somebody distributing binaries for a program,
> licensed under the GPL, and when asked for the source (in the preferred
> form for modification), saying the binary is it? For any binary at all.
What's to stop somebody from selling me a computer loaded with GPL
programs and then refusing to give me the source code for the CPU
microcode? Clearly the whole work must be licensed compatibly with
the GPL.
When you are talking about a binary blob of firmware, for loading or
execution in some separate device, there is a clear distinction, in
both function and interface, between the driver/control software and
the firmware. Someone earlier in this thread made the argument that
when it is just firmware, one should consider it "mere aggregation":
The Program (driver) is a distribution media for the microcode and an
interface to it, but they are separate works not derived from one
another.
I am not sure what the legal implications of that would be for
something like a graphics driver, especially since the boundary is not
so clear, but I suspect the vendor would want the binary blob to be
licensed in GPL-incompatible terms anyway, rendering the whole
(including the stubs) GPL-incompatible.
After all, the point of software freedom is to let the user make
useful changes (by the user's definition of useful, and nobody else's)
to the software he uses. There are both benefits and drawbacks to
having free-as-in-speech firmware, but I do not see how an
indecipherable blob of firmware impairs that software freedom.
Michael Poole
Reply to: