Re: [DRAFT] resolving DFSG violations
"Jeff Carr" <basilarchia@gmail.com> writes:
> On Mon, Oct 27, 2008 at 18:41, Ben Finney <ben+-debian@benfinney.id.au> wrote:
>
> > Whoever the copyright holder of that work is (I read your remark
> > above to mean that the hardware manufacturer is that copyright
> > holder), there must be a "preferred form of the work for making
> > modifications to it". What form is that? *Someone* must have it,
> > in order to make modifications that become new releases of the
> > work to run on the same hardware.
>
> I guess it's really hard to explain because there is a massive gap;
> I can't teach you to be an electrical engineer or logician here :) I
> think if you had the time to go through and synthesize "firmware
> blobs" for some chips then you would see why this doesn't make
> sense.
Nevertheless I really appreciate the effort you're taking to explain
this. Not just for myself either:
If bunches of bits are to be redistributed in Debian, that needs to be
done in a manner compatible with the explicit promises of the Social
Contract, regardless of whether those who package those bits for
redistribution are themselves trained electrical engineers.
So, it's important for the freedom issues to be understood by we mere
mortals who don't deal with logic boards; and that involves bridging
gaps in understanding, without requiring all of us learning everything
about each others's field :-)
> It's that these "binary only blobs" only make sense to the chip.
I'm not disputing that. The reason these programmatic bit streams are
an issue is that if they're to be redistributed by Debian, the
recipient needs to have the guarantees of freedom as per the Social
Contract. So, it is irrelevant (for the purpose of satisfying the
contract of freedom) which particular hardware they are intended to be
loaded into, be it a CPU or a daughterboard processor.
> For example, lets say you have a pci device. If you don't load the
> firmware blob, the pins will just remain in an uninitialized state.
> That is; the chip default. Programming in the firmware blob will
> tell the chip how to work as a pci bus. Now you are good to go. It's
> now possible to write a pci device & there are registers, etc.
So, it sounds like we're talking about exactly the same freedom
issues, just with a different processor involved: the PCI board's
processor instead of the motherboard's CPU.
> Still, the firmware blob that you load into the chip isn't x86 code
> for the host -- it's raw junk for the chip.
That +IBw-raw junk+IB0- is, if I understand you correctly, instructions and
data for controlling the behaviour of the processor on the PCI chip.
How is this different from saying that the machine-code form of a
program is +IBw-raw junk for the motherboard's CPU+IB0-?
I get the impression you're saying it's different in some way other
than which processor the bit stream is destined for, but I'm trying
without success to see what difference exists that eliminates the
right of the recipient to have freedom in that work.
> It's a totally different issue than distributing a binary only
> nvidia driver. That's not what I'm talking about here.
Understood; I'm fairly sure the distinction between which processor
these bits are intended for is clear to readers of this thread.
What I don't see is a justification for denying the right of freedom
in that bit stream for the recipient of the Debian operating system
where these bits are redistributed.
Note that +IBw-only a tiny fraction of the recipients could ever make
practical use of the source form of the work+IB0- is no justification for
denying any recipient the freedom to get that source form; we don't
accept that argument for processor code destined for a motherboard
CPU, after all.
> I'm only trying to explain there are binary only firmware blobs for
> most chips, you have them for most of the chips on your motherboard
> and in many cases, there is no human readable form. Even the chip
> manufacturers don't know what they are. It's totally machine
> generated chip garbage as far as they are concerned.
What, then, does the chip manufacturer +IBQ- who, if I understand you
correctly, is the copyright holder and vendor of the firmware +IBQ- have
as the means of generating *new* processor firmware targeted to the
*same*, already-sold, hardware?
I would argue that that form of the work meets the definition of
+IBw-source code for the firmware+IB0-. Yes?
--
+AFw- +IBw-The best mind-altering drug is truth.+IB0- +IBQ-Jane Wagner, via Lily |
`+AFw- Tomlin |
_o__) |
Ben Finney
Reply to: