Re: [DRAFT] resolving DFSG violations
"Jeff Carr" <basilarchia@gmail.com> writes:
[color=blue]
> On Mon, Oct 27, 2008 at 18:41, Ben Finney <ben+-debian@benfinney.id.au> wrote:
>[color=green]
> > 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.[/color]
>
> 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.[/color]
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 :-)
[color=blue]
> It's that these "binary only blobs" only make sense to the chip.[/color]
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.
[color=blue]
> 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.[/color]
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.
[color=blue]
> Still, the firmware blob that you load into the chip isn't x86 code
> for the host -- it's raw junk for the chip.[/color]
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.
[color=blue]
> It's a totally different issue than distributing a binary only
> nvidia driver. That's not what I'm talking about here.[/color]
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.
[color=blue]
> 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.[/color]
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
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
* Ben Finney <ben+debian@benfinney.id.au> [2008-10-28 16:38:41 +1100]:
[color=blue][color=green]
> > Still, the firmware blob that you load into the chip isn't x86 code
> > for the host -- it's raw junk for the chip.[/color]
>
> That “raw junk” 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 “raw junk for the motherboard's CPU”?[/color]
What Jeff seems to be saying is that the tools the hardware
manufacturers use to modify the firmware work with it in that binary
form, as opposed to most software which is compiled into "machine-code
form" from separate human-readable source code. This would appear to be
akin to editing a raster image in an image editor while keeping it in
JPEG form, as opposed to using either a more complex format supporting
layers etc., or a vector graphics format.
[color=blue]
> What, then, does the chip manufacturer — who, if I understand you
> correctly, is the copyright holder and vendor of the firmware — 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
> “source code for the firmware”. Yes?[/color]
Again, assuming I'm not misspeaking, that form of the work is already
what we have.
--
mithrandi, i Ainil en-Balandor, a faer Ambar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkGwDMACgkQpNuXDQIV94rwAQCfd16x1bS5I97gd6BPHNwOavcR
5dAAnRIBJ7jnMmVGkKp3ho6U9qZuEpbx
=GLxZ
-----END PGP SIGNATURE-----
Re: Free OS versus free hw
Loïc Minier <lool@dooz.org> writes:
[color=blue]
> On Mon, Oct 27, 2008, Jeff Carr wrote:[color=green]
> > have little flash chips holding these bits all over in your
> > machine now. You just don't know it. And now, because someone is
> > giving you the luxury of actually loading them via software (with
> > gpl software no less) you seem to be all ticked off.[/color]
>
> Right; I share your concerns with the new burden Debian is
> attaching to itself when requiring the loadable firmwares to be
> free.[/color]
The requirement for the contents of Debian to be free is not a new
burden. It's spelled out in the Social Contract; the founders and
drafters of that document are clear that the intention was always for
all of Debian to be free, not just some parts of Debian.
What's relatively new is the realisation that some of those parts
(such as firmware) have a programmatic function but can, in some
cases, have *no* better form for making modifications than the binary
blob itself.
At least, that's my understanding of some of the use cases presented
here: that even the vendors of those blobs routinely modify the binary
blob directly to generate a new version of it, much like
bit-manipulating a machine-code executable and running it.
As strange as it may seem to my mind used to the roomy expanses and
flexibility to be found in a motherboard CPU, it may be an optimal way
to work when the processor in question barely has room in its program
memory or instruction set for the functional blob, and no extra room
for even embedded diagnostic tools, let alone debuggers or symbol
tables. I don't know that to be the case, but I'm not going to reject
the possibility only because it's difficult for me personally to
imagine.
[color=blue]
> I fear it's not an easy task to delimit which (sub-)system we
> require to be free though. I'd love it if someone could come up
> with some sane wording for it.[/color]
I think the Social Contract makes it fairly clear that all of the
Debian operating system is promised to be free. I don't see a
compelling reason to allow breaches of that promise to be rationalised
away by differences in functional classification of the works.
[color=blue]
> How do others feel about this? Is there any contamination of the
> firmwares when shipped in a free OS which is not possible to
> prevent?[/color]
My opinion is that recipients of Debian should have unfettered access
to exercise the freedoms of running/performance, inspection,
modification, and redistribution of the entirety of Debian, using
nothing but operating system tools that are similarly unfettered and
hardware that's commonly used for such activities.
That means: free access to exactly the same form of the work that the
vendor might use to make modification to any part of the operating
system, be it the language instructions and APIs that gets rendered to
a machine code program, or the full-layered vector document that gets
rendered to a PNG file, or the reStructuredText document and style
sheets that get rendered to a PDF file, or the firmware blob that gets
manipulated as-is. Whatever the vendor can do to the work in order to
inspect, modify, and redistribute it, a Debian recipient equipped with
suitable generic hardware can expect to have free reign to do the
same.
It's clear that not every recipient of Debian will have access to the
hardware nor expertise necessary to develop useful modifications to a
GPU-targetted instruction blob, just as not everyone has a digital
camera for capturing high-resolution photographic data. But every
Debian recipient can certainly expect to be free to redistribute
Debian to someone arbitrary party (who is not necessarily the vendor)
who *does* have such hardware and expertise, and for that party to be
free to apply requested modifications and redistribute the work back
to them, *without* anyone in that chain needing extra permissions and
*without* access to any specific extra data, vendor-specific programs,
or other non-free software.
If the above isn't the case for any part of Debian, I consider that a
breach of the Social Contract, to be considered a serious bug and
fixed appropriately by ceasing redistribution of that work in Debian
until it's fixed, and (ideally) fixing it so the work can again be
included in Debian.
--
\ “An expert is a man who has made all the mistakes which can be |
`\ made in a very narrow field.” —Niels Bohr |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: Free OS versus free hw
On Tue, Oct 28, 2008 at 10:51:55PM +1100, Ben Finney wrote:
[...] [color=blue]
> *without* access to any specific extra data, vendor-specific programs,
> or other non-free software.[/color]
I agree here, although, I wouldn't say the DFSG requires that source
code should be modifiable with software distributed in Debian. But it
would certainly be an improvement, mainly in the presence of bitstreams
which are the corresponding source code themselves and are only modified
using vendor-specific tools, which may not be available as free/libre
software.
[...][color=blue]
> Ben Finney[/color]
Cascardo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkkHAP0ACgkQyTpryRcqtS2+cQCeKWyjbqFN+UtX7XJ7RNAnM8L5
IqsAoIdNsmkezT95V7XO5XMyv6qpUieY
=76BH
-----END PGP SIGNATURE-----
Re: Free OS versus free hw
On Tue, 2008-10-28 at 22:51 +1100, Ben Finney wrote:[color=blue]
> What's relatively new is the realisation that some of those parts
> (such as firmware) have a programmatic function but can, in some
> cases, have *no* better form for making modifications than the binary
> blob itself.[/color]
OK, to my eyes, this means that if the relevant providers of such
firmware can give such an assurance and that this is added to
debian/copyright, the bugs reported against these items of firmware can
be closed as fixed. I see no problem with that.
Now, whether such packages should include some hints or links to docs
that explain the kind of tools that are required to do that manipulation
(software and physical tools), I think we can leave to minor or wishlist
bugs, manpages and README.Debian.gz. That isn't RC.
[color=blue]
> As strange as it may seem to my mind used to the roomy expanses and
> flexibility to be found in a motherboard CPU, it may be an optimal way
> to work when the processor in question barely has room in its program
> memory or instruction set for the functional blob, and no extra room
> for even embedded diagnostic tools, let alone debuggers or symbol
> tables. I don't know that to be the case, but I'm not going to reject
> the possibility only because it's difficult for me personally to
> imagine.[/color]
At last, some sanity in this thread.
I have only the most limited exposure to hardware design / modification
but I can see that sometimes you do simply need to avoid uninitialised
data by using a binary blob that sets a sane value, amongst other tasks.
The mere fact that this is done by directly prodding the chip/pins with
a lump of binary code rather than by using gcc is inconsequential.
It leaves a question of just when such a method is still deemed
reasonable and whether the size of the blob (or the apparent complexity
of the blob) should be taken into account when assessing the validity of
a claim in debian/copyright. Nevertheless, the mere presence of a binary
blob is not a breach of the DFSG, IMHO.
[color=blue]
> My opinion is that recipients of Debian should have unfettered access
> to exercise the freedoms of running/performance, inspection,
> modification, and redistribution of the entirety of Debian, using
> nothing but operating system tools that are similarly unfettered and
> hardware that's commonly used for such activities.[/color]
(and that such hardware does not have to exist within the confines of
the hardware within or available to be plugged into a normal PC but may
include any hardware commonly used for the activity, including tools
that would be familiar to anyone commonly undertaking such activities.)
[color=blue]
> That means: free access to exactly the same form of the work that the
> vendor might use to make modification to any part of the operating
> system, be it the language instructions and APIs that gets rendered to
> a machine code program, or the full-layered vector document that gets
> rendered to a PNG file, or the reStructuredText document and style
> sheets that get rendered to a PDF file, or the firmware blob that gets
> manipulated as-is. Whatever the vendor can do to the work in order to
> inspect, modify, and redistribute it, a Debian recipient equipped with
> suitable generic hardware can expect to have free reign to do the
> same.
>
> It's clear that not every recipient of Debian will have access to the
> hardware nor expertise necessary to develop useful modifications to a
> GPU-targetted instruction blob, just as not everyone has a digital
> camera for capturing high-resolution photographic data. But every
> Debian recipient can certainly expect to be free to redistribute
> Debian to someone arbitrary party (who is not necessarily the vendor)
> who *does* have such hardware and expertise, and for that party to be
> free to apply requested modifications and redistribute the work back
> to them, *without* anyone in that chain needing extra permissions and
> *without* access to any specific extra data, vendor-specific programs,
> or other non-free software.
>
> If the above isn't the case for any part of Debian, I consider that a
> breach of the Social Contract, to be considered a serious bug and
> fixed appropriately by ceasing redistribution of that work in Debian
> until it's fixed, and (ideally) fixing it so the work can again be
> included in Debian.[/color]
Equally, if the above *is* the case and debian/copyright can include a
declaration to that effect, then IMHO the DFSG is satisfied and the bug
needs to be closed as fixed.
In the end, it comes down to "the preferred form for modification" and
the reality that the preferred form *can* include binary code, machine
code or any other data of a type that may well be generated in many
other cases but is actually manipulated directly in this specific case.
Can we agree on this and get back to releasing Lenny?
(please?)
--
Neil Williams
=============
[url]http://www.data-freedom.org/[/url]
[url]http://www.nosoftwarepatents.com/[/url]
[url]http://www.linux.codehelp.co.uk/[/url]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAkkHBpkACgkQiAEJSii8s+N9dACgnIsWCdn5LnJngV+WkkgTFxlg
i50AoIcdJYjSVMh2F6xXTOG9PPE5lX9J
=LVlT
-----END PGP SIGNATURE-----
Re: Free OS versus free hw
Neil Williams <codehelp@debian.org> writes:
[color=blue]
> In the end, it comes down to "the preferred form for modification"[/color]
I am convinced that's the most useful place to draw the line, yes.
[color=blue]
> and the reality that the preferred form *can* include binary code,
> machine code or any other data of a type that may well be generated
> in many other cases but is actually manipulated directly in this
> specific case.[/color]
I acknowledge it as a possibility (and my huge thanks to those who
have patiently explained this possibility). The existence of that
possibility doesn't significantly detract from the possibility that a
given firmware blob is *not*, in fact, the preferred form for making
modifications to it.
So I think that raises the important issue of what assurance is needed
to trust that we *are* redistributing the preferred form for making
modifications in any specific instance; and, while that issue is not
unique to programmatic blobs (c.f. raster graphic image data, for
another example of the same issue), it appears to me that the risk of
redistributing a non-source form (and thus unwittingly failing to meet
our Social Contract) is greater with programmatic binary blobs.
What assurance would those who are likely to have the inclination and
means to modify a processor's firmware, as distributed in Debian,
going to require to be satisfied that they have the preferred form of
the specific work for making modifications to it?
[color=blue]
> Can we agree on this and get back to releasing Lenny?
>
> (please?)[/color]
I wasn't aware that work on releasing Lenny was halted while we
discuss this.
As for agreement, the existence of more possibilities in this matter
only appears to increase the burden of evidence. What application does
this have on the current firmware blobs in Debian? How do we determine
whether those specific blobs definitely are or definitely are not
being redistributed without the preferred form of the work for making
modifications?
--
\ “I like to fill my bathtub up with water, then turn the shower |
`\ on and pretend I'm in a submarine that's been hit.” —Steven |
_o__) Wright |
Ben Finney
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
On Mon, Oct 27, 2008 at 12:26:31PM -0700, Jeff Carr wrote:[color=blue]
> True, I certainly feel like that at times with the opencores project
> I've been trying to maintain.
>
> On the other hand, I sure know that I know a pile more than you do or
> we wouldn't be having this discussion :)[/color]
I have a different theory.
[color=blue]
> Yes Gee whiz. You're not getting it. The firmware is a binary blob.
> You can distribute the source but you can't synthesize it. So, in the
> debian installer, you can't include it according to this insane
> policy.[/color]
You could synthesize it if you had the tools for it.
Debian's policy is not insane. It is consistent. Any hardware maker
that wants their hardware to work with free software could use an
eeprom to store the firmware within the device, so that there is nothing
non-free that has to be distributed. That is what Debian is concerned
with. If the firmware is embedded in the device, then it has nothing to
do with Debian anymore, and it is entirely up to the user whether they
care about how the hardware they buy is made. Those that do care can
simply avoid that type of hardware (or at least try to).
[color=blue]
> But the opencore case is the easy case, hybrid chips don't even have
> source. The firmware blob is often generated when you fabricate the
> chip & changes with the physical board layout. You guys just don't
> understand the issues here. There isn't some nafarious intent; you
> have little flash chips holding these bits all over in your machine
> now. You just don't know it. And now, because someone is giving you
> the luxury of actually loading them via software (with gpl software no
> less) you seem to be all ticked off. You seem to want to stick your
> head in the sand and pretend this doesn't exist.[/color]
If they use flash chips, then it doesn't affect Debian, because the
flash chip already contains what is needed for the device to work.
Debian doesn't have to have anything to do with updating them, and hence
there is no distribution of non-free to worry about.
[color=blue]
> And no, it's not about telling users "This is all free". That's a lie
> at this level anyway. None of it is free. Whether you load it from
> /lib/firmware/ or if it's already stored on your motherboard doesn't
> change anything. It just makes us Debian look ridiculous. The message
> should be: "There are some firmware blobs for some hardware that there
> is no known way to generate code for, nor any way to compile such code
> if we had it or any way to figure out how we would write a compiler
> for it either. This firmware is also hidden in flash for most of the
> chips on your machine. Some modern devices let the OS load this code
> into the chip then we are able to write fully GPL drivers for the
> device. Debian's focus is on free software; not free hardware designs
> (although we love those too).[/color]
It does make a difference. Debian makes no promise about the freeness
of the users hardware since Debian did no provide it. Debian promises
that everything they provide is free. That really isn't very hard to
understand. Debian policy is only concerned with the software Debian is
distributing. If Debian didn't provide it as part of the distribution,
then Debian's policy has nothing to do with it. Hence your motherboard
and its BIOS and other firmware in flash has nothing to do with Debian's
polcies at all. If your hardware requries closed source firmware to
operate, then at best Debian can distribute that in non-free, and using
it during the install will be slightly tricky (but not that hard. I
have done so and it wasn't that big a deal. It just meant I had to
personally accept that I was about to use one piece of non-free code to
make that particular system work and it was my choice, not Debian's that
made my system contain a piece of non-free code. That is how it should
be with Debian).
--
Len Sorensen
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
On Mon, Oct 27, 2008 at 12:29:58PM -0700, Jeff Carr wrote:[color=blue]
> Hardly perfectly readable - I put up code there too :)[/color]
Oh well. Some people write ugly perl code, some write ugly VHDL. Not
the language or tools fault, just bad programmers.
[color=blue]
> Which is often not the case on cheap devices (often usb) because of
> cost, space, power, etc for another chip.[/color]
I know. So I can either pay more (if I can find someone that still
makes a proper complete device), or I can not use that device, or I can
accept that to use it I must install some file from non-free. It should
not be support by Debian main.
--
Len Sorensen
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: Free OS versus free hw
Hi,
[color=blue]
> At least, that's my understanding of some of the use cases presented
> here: that even the vendors of those blobs routinely modify the binary
> blob directly to generate a new version of it, much like
> bit-manipulating a machine-code executable and running it.[/color]
No, it's more a case of there not being any free compiler available that
could produce a working blob.
A lot of new USB hardware uses an off-the-shelf controller, one of the most
popular ones is the FX2, which has an 8 bit CPU with banked memory. gcc's
"state machine" approach to compiling is pretty much lost on this hardware.
Almost the same thing goes for FPGAs, which need to be optimized for the
specific chip (a lot of FPGAs have dedicated circuitry around the
programmable area for e.g. FIFOs or buffers, and compilers need to be able
to utilize those).
We do have compilers for these systems, but they will not generate code
that can fit into the actual hardware.
The commercial compilers that can handle this are not free software.
[color=blue]
> My opinion is that recipients of Debian should have unfettered access
> to exercise the freedoms of running/performance, inspection,
> modification, and redistribution of the entirety of Debian, using
> nothing but operating system tools that are similarly unfettered and
> hardware that's commonly used for such activities.[/color]
We cannot provide that even with the consent, however unlikely, of hardware
manufacturers, simply because their tools are not free software, so at the
current time lobbying for free firmware is a pretty pointless effort.
The only thing that will give us free firmware is actually writing it, and
writing the tools to compile it; the thing we need from hardware vendors
has not changed: documentation for the interfaces from the programmable to
the hardwired bits.
Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iJwEAQECAAYFAkkHMfoACgkQ0sfeulffv7tKGwP7BSyhRdkFiUoHx8nHsDne97wd
Mfv0ERsec4KodGrL7n8CD03kIa8HaQAaTZXBLr7Vo5N+tTf8FCrfRFiuIY4uGiik
pvI06n5YKqrqLVjS9c+/8x71Vt/lu+q9F9j92q7XiBUjWFFkzvoDu9ieWOLtEq4I
u0bPepuDfxwll/3u4YM=
=GdnY
-----END PGP SIGNATURE-----
Re: [DRAFT] resolving DFSG violations
Thadeu Lima de Souza Cascardo (2008-10-28 16:07 -0200) wrote:
[color=blue]
> On Tue, Oct 28, 2008 at 06:01:45PM +0100, David Weinehall wrote:[color=green]
>> Throwing out the firmware doesn't help our users, it makes things
>> worse for our users. And our users are our number one priority.[/color]
>
> Is it not providing them the best free/libre operating system?[/color]
Perhaps so, but it has also become quite clear that different people
have different goals and different definitions for software freedom. The
Social Contract means different things to different people. Therefore
it's a good paper to back up one's own views, whatever they are.
1. Debian will remain 100% free
[...] We will never make the system require the use of a
non-free component.
The "system" doesn't require non-free components; it's just some users
and their hardware that does. Debian cares about the "system".
4. Our priorities are our users and free software
We will be guided by the needs of our users and the free
software community. We will place their interests first in our
priorities. [...]
Probably everybody has an opinion about what "our users" and the "free
software community" needs. By definition, "our users" are people who use
Debian. If they stop using Debian (perhaps because they don't like it or
it doesn't work in their machine) they are not our users anymore so
those people don't count. In the end Debian developers can just think
that "what I need is also the need of our users." :-)
I'm not ranting. I'm actually very happy and "passionate moderate"[1]
Debian user. Thanks you, everyone.
----------
1. [url]http://lkml.org/lkml/2006/9/27/414[/url]
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
"Jeff Carr" <basilarchia@gmail.com> wrote:
[color=blue]
> On Sat, Oct 25, 2008 at 09:21, Frank Kster <frank@debian.org> wrote:
>[color=green]
>> How can that be? (That is an ernest question)[/color]
>
> Because that's how the hardware works. If you are making a widget and
> you need a fpga or hybrid chip of any sort, then you generate a binary
> blob using the chip manufacturers tools.[/color]
So it seems to me that there actually is source: The input files for
"the chip manufacturer's tools". Isn't that correct?
Then the problem wouldn't be to provide the source, but to have free
tools available (and maybe the keys mentioned in some other mail).
Regards, Frank
--
Frank Kster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grne KV Miltenberg
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: Free OS versus free hw
On Tue, Oct 28, 2008, Ben Finney wrote:[color=blue]
> The requirement for the contents of Debian to be free is not a new
> burden.[/color]
What's new here is the number of firmwares which one need to make a
computer useful and the consequence on the perimeter of the Debian
project.
[color=blue]
> It's spelled out in the Social Contract; the founders and
> drafters of that document are clear that the intention was always for
> all of Debian to be free, not just some parts of Debian.[/color]
Yes, perhaps we need to delimit what this covers exactly.
[color=blue]
> What's relatively new is the realisation that some of those parts
> (such as firmware) have a programmatic function but can, in some
> cases, have *no* better form for making modifications than the binary
> blob itself.[/color]
I certainly wouldn't want to argue that the binary blob is the
preferred form of modification; I don't put in question that the
firmware files are programs which have been generated by some
development process out of some type of sources and some software.
Instead, I'd much rather limit what needs to be free in Debian to what
we care to interface with: I don't care that my BIOS is closed source
to run Debian on it. I wouldn't mind having a free BIOS updated which
would include BIOS update images made of non-free software if Debian
had the rights to redistribute them and to modify the binaries in
anyway.
[color=blue]
> At least, that's my understanding of some of the use cases presented
> here: that even the vendors of those blobs routinely modify the binary
> blob directly to generate a new version of it, much like
> bit-manipulating a machine-code executable and running it.[/color]
I don't believe it's the most common case for the generation of the
lib/firmware files. I think those are the result of a complex
engineering and release process, and some parts are certainly source
code. Just documentation of the hardware is something I find essential
in order to maintain the firmwares, even in binary form.
[color=blue][color=green]
> > I fear it's not an easy task to delimit which (sub-)system we
> > require to be free though. I'd love it if someone could come up
> > with some sane wording for it.[/color]
>
> I think the Social Contract makes it fairly clear that all of the
> Debian operating system is promised to be free. I don't see a
> compelling reason to allow breaches of that promise to be rationalised
> away by differences in functional classification of the works.[/color]
I see one in that it's likely a much harder project than building a
free OS, and I wouldn't care much: I'm not a hardware engineer. I also
find it unrealistic that all these firmware bits will be freed up. I
don't buy the "preferred form of modification is the binary" argument
either.
[color=blue]
> That means: free access to exactly the same form of the work that the
> vendor might use to make modification to any part of the operating
> system[/color]
So you consider the bits of code which runs on the hardware part of the
OS? I consider it's part of what gets on the CDs to ship, and in the
archive, but I don't see it as a runtime part of the OS; I see it as a
runtime part for hardware with which the OS interfaces.
[color=blue]
> It's clear that not every recipient of Debian will have access to the
> hardware nor expertise necessary to develop useful modifications to a
> GPU-targetted instruction blob, just as not everyone has a digital
> camera for capturing high-resolution photographic data.[/color]
But changing the code which runs on the GPU is building a different
system, for GPUs. I can imagine booting my GPU straight from VBIOS to
run actual code, without booting Debian at all from the main CPU.
Other projects can work on freeing up the GPU to do more useful stuff
than what the interface the hardware (with suitable driver loaded)
offers, but why would Debian need to consider this? Graphics can be
driven by the VESA API for example; it's not very powerful, but it
works. Why not allow shipping a file which enables using a different,
but agreed upon API if we have the right to ship the file and don't
need to care about its content but just about its conformance to the
API?
[color=blue]
> If the above isn't the case for any part of Debian, I consider that a
> breach of the Social Contract, to be considered a serious bug and
> fixed appropriately by ceasing redistribution of that work in Debian
> until it's fixed, and (ideally) fixing it so the work can again be
> included in Debian.[/color]
I ackowledge that the current requirements of the social contract as
it's worded and intended require us to ship the source code of the
lib/firmware blobs. What I'm not sure about is why we couldn't have an
equally useful social contract to build an OS, but is worded to allow
shipping of utility binary files which enable additional hardware to
work with agreed upon APIs.
--
Loc Minier
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
On Sun, 2008-10-26 at 20:17 -0700, Jeff Carr wrote:
[...][color=blue]
> If you did synthesize it, you might not have even "seen" it if you put
> it on a cpld. Then you might have just thought you were "programming"
> the chip.[/color]
You have to synthesise *from* something, be that Verilog or VHDL or
Handel-C.
[color=blue]
> No; you were just writing it to flash. Thus bypassing the
> dilemma. If you build a product and don't want to pay to have the
> extra chip onboard (common on cheap low end parts) then you have to
> load it via software. Thus the firmware blob. And yes, for the 50th
> time: THERE IS NOT SOURCE CODE. There can not be source code, it
> didn't start as source code. You can't "compile" it because there
> isn't a compiler. It's not instructions for a microprocessor -- in
> your case -- it is the microprocessor itself. That's right, lets say
> that again, the firmware blob is your 4 bit microprocessor.[/color]
Sure, it's not a program in the usual sense, but there is a source for
it.
[color=blue]
> So this whole free 4 bit microprocessor you just made, you can publish
> the source and everything (see also: openrisc & opensparc). But, to
> run it, you have to give people a firmware blob so they can run it.[/color]
If people want microprocessors then they buy ASICs, which are much
cheaper, faster, and power-efficient. So far as I can see, the major
use for open hardware designs is as modules ("IP") in larger designs
which will later be synthesised into ASICs. The people using them will
need the source; they already have the synthesis tools.
There aren't a whole lot of mass-produced devices using CPLDs or FPGAs
either, as that doesn't usually make economic sense.
[color=blue]
> Perhaps you can't even make an installer for it because you can't
> initialize the chip in the installer because you can't put the fimware
> you need in the installer.[/color]
I believe we can distribute firmware binaries in main if we can also
distribute their sources. We might need to make an exception to the
policy that we build all binaries using tools in main.
[color=blue]
> So you can only support hardware where you
> can flash the firmware on the motherboard. Also not ideal because you
> might have a version out of sync with the kernel device driver you
> wrote. Great, thanks a lot freedom.
>
> So yes, I think most people aren't going to "get" the issue unless
> they may have been firmware engineers.[/color]
IANAFE, though I probably will be soon.
Ben.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJB6uy79ZNCRIGYgcRAtK5AKCwXH1RhDi04FeRl5xtEDHGwkPpMACgvuBn
t+ZfdmLMBFi0cheuAhz6PHQ=
=Y6as
-----END PGP SIGNATURE-----
Re: Free OS versus free hw
Loïc Minier <lool@dooz.org> writes:
[color=blue]
> On Tue, Oct 28, 2008, Ben Finney wrote:[color=green]
> > That means: free access to exactly the same form of the work that
> > the vendor might use to make modification to any part of the
> > operating system[/color]
>
> So you consider the bits of code which runs on the hardware part of
> the OS? I consider it's part of what gets on the CDs to ship, and
> in the archive, but I don't see it as a runtime part of the OS; I
> see it as a runtime part for hardware with which the OS interfaces.[/color]
I don't consider “runtime part of the OS” to be the limit of what
needs to be free. I consider “the OS”, that is, whatever we ship and
say is Debian, no matter what transient functional classifications it
may have in any particular instance, to be the limit of what needs to
be free.
For my own part, I want *all* digital information to be free; but
that's not the mandate of the Debian project. What *is* the mandate of
the Debian project is that it produce the best free operating system.
Anything that the project produces as part of that operating system,
whether it happens at any particular moment to be interpreted as
“executable”, “documentation”, “configuration”, “data”, or some
simultaneous blend of functional classifications, must be free.
[color=blue][color=green]
> > If the above isn't the case for any part of Debian, I consider
> > that a breach of the Social Contract, to be considered a serious
> > bug and fixed appropriately by ceasing redistribution of that work
> > in Debian until it's fixed, and (ideally) fixing it so the work
> > can again be included in Debian.[/color]
>
> I ackowledge that the current requirements of the social contract
> as it's worded and intended require us to ship the source code of
> the lib/firmware blobs.[/color]
Simply because anything that we ship as part of Debian must be
DFSG-free.
[color=blue]
> What I'm not sure about is why we couldn't have an equally useful
> social contract to build an OS, but is worded to allow shipping of
> utility binary files which enable additional hardware to work with
> agreed upon APIs.[/color]
That would be far less useful as a social contract because it allows a
ghetto of non-free parts to be redistributed within Debian, and make
false the core idea that “I have received a free operating system, so
I know that for *everything* in here I have certain basic freedoms”.
--
\ “Room service? Send up a larger room.” —Groucho Marx |
`\ |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
On Mon, 2008-10-27 at 13:01 -0700, Jeff Carr wrote:
[...][color=blue]
> In any case, all of this is theoretical; it's just doesn't make any
> sense to change the manufacturer firmware blob.[/color]
[...]
It can do. Firmware has bugs, and many hardware manufacturers have an
unfortunate habit of abandoning firmware after the product is no longer
shipping. Sure, the most serious bugs get fixed before release, but
other bugs may only appear in conjunction with other hardware or may
turn out to be serious in some case that wasn't tested.
Just as a demonstration:
$ git grep -i '\bfirmware\b.*\bbug\b' drivers | wc -l
27
Ben.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJB64079ZNCRIGYgcRAhwWAKC7SUvSHlP4UddhEaFZ7pk9AXb7/QCgyNbm
MNCv1yxdL0VfJHMcaUI3n1I=
=hx2M
-----END PGP SIGNATURE-----
Re: [DRAFT] resolving DFSG violations
On Mon, 2008-10-27 at 20:30 -0700, Jeff Carr wrote:
[...][color=blue]
> 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.[/color]
[...]
How exactly do you propose to load the firmware, if not through a JTAG
port? Back in the world of production hardware which Debian runs on,
ASICs tend to have power-on-reset logic built-in...
Ben.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJB7DD79ZNCRIGYgcRAvFkAJ9LpMM8RwvF8J2NDKsGl63m1I9MlQCglvVK
UAHeWGtUBJEbiZug4E2aTCM=
=Cxwy
-----END PGP SIGNATURE-----
Re: [DRAFT] resolving DFSG violations
On Tue, 2008-10-28 at 18:01 +0100, David Weinehall wrote:
[...][color=blue]
> Please try to explain to a hardware manufacturer that free their
> hardware will only work with free software if they store their firmware
> on an eeprom, and they'll laugh you in the face (or possibly send you
> off to an asylum). Do you really think that it's better for our users
> that the firmware is impossible to replace (and thus impossible, even
> for the hardware vendors, to bugfix)?[/color]
Does the "EEP" mean nothing to you?
[color=blue]
> Face it, all hardware has firmware, either loadable or in EEPROM. In
> most cases that firmware is closed source. In most cases they are for
> custom chips that have no compilers/developer kits/whatever available in
> Debian anyway, so having the source wouldn't make any difference (and in
> some cases, the binary blobs *is* the source code; I've spent more than
> enough time programming 8-bit directly from a machine-code monitor).[/color]
Agreed.
[...][color=blue]
> Now, imagine Debian having this hypothetical yearly conference, called,
> oh, let's say DebConf. During that conference we organise a special day
> for our users, let's call it Debian Day. Lots of potential new Debian
> users show up with their laptops and wants to install Debian. As the
> kind souls we are, we hand out credit-card CD's with netinst images that
> they can use with the WiFi available at the conference.
>
> Oh, but wait. They cannot access the WiFi, because their wireless cards
> are not supported. Or rather, the drivers are available, but they all
> report the same error message "Firmware not found". Happy, happy, joy,
> joy.[/color]
[...]
This situation sucks. But we cannot claim to have a 100% free
distribution while including sourceless firmware. The obvious solution
is to have official free and not-quite-official non-free variants of the
installer. But since most users won't know in advance whether they need
sourceless firmware, the safe default would always be to choose the
non-free variant - thus this is no solution. I wish I could think of
something better.
Ben.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJB7YR79ZNCRIGYgcRAmy1AJ4x8dcaLrYyMl2Cm6HKGGBsCSdJWgCeIggX
YlO42pf3uPdGNB2DFbKG6yw=
=UWxW
-----END PGP SIGNATURE-----
Re: [DRAFT] resolving DFSG violations
Ben Hutchings <ben@decadent.org.uk> writes:
[color=blue]
> This situation sucks. But we cannot claim to have a 100% free
> distribution while including sourceless firmware.[/color]
That is my main concern, yes.
[color=blue]
> The obvious solution is to have official free and not-quite-official
> non-free variants of the installer. But since most users won't know
> in advance whether they need sourceless firmware, the safe default
> would always be to choose the non-free variant - thus this is no
> solution. I wish I could think of something better.[/color]
One possibility is that there's no better option but to draw a similar
line in the sand as was done for free software 25 years ago.
Hardware vendors now appear (from my understanding of this discussion)
to be at the same point where software vendors were 25 years ago:
unquestioningly pushing out software works that are increasingly
flexible and updatable, but without even considering that some
recipients might expect freedom in the work, and in formats that can't
be feasibly modified without additional works that are themselves
non-free.
Whether or not the future holds a similar flowering of baseline
freedom as has occurred so far in CPU-targeted software works, I don't
know. I also don't know from where the expertise, resources, and
funding will come to reform or replace the established non-free
hardware vendors.
What I do know is that it will never happen unless a significant
number of hardware owners and operating system distributors decide
that the current trend of increasing dependence on non-free software
for running our hardware is unacceptable.
--
\ “If you fell down yesterday, stand up today.” —_The Anatomy of |
`\ Frustration_, H. G. Wells, 1936 |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
Re: [DRAFT] resolving DFSG violations
On Wed, Oct 29, 2008 at 2:01 AM, David Weinehall <tao@debian.org> wrote:
[color=blue]
> As for the iwl3945 firmware, I do not know for sure whether it's written
> in C, assembler, or whatever else (I'm fairly certain it's NOT in some
> obscure 8-bit CPU or similar). Personally I wouldn't mind having
> the source code, but I do know, that if the choice is between either
> having the firmware in EEPROM or having it as a binary blob, I'd take
> the binary blob anytime.[/color]
It is fairly likely that it is written in C, since the firmware blob
contains the names of .c files that were probably used to compile it.
[color=blue]
> For laptops running Intel chipsets, the most common wireless chipsets are
> iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary
> only firmware. With Intel's recent track record of releasing
> sources, it's reasonable to assume that they would have released the
> sources if they saw it as possible, so hoping for a source release seems
> fairly futile.[/color]
Intel have resolved my bug report about source code for the firmware
as wontfix, citing the FAQ about the FCC:
[url]http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1594[/url]
Personally I intend to switch to a more free-software friendly
wireless hardware provider as soon as is realistic. I considered doing
something similar to the prism54 FreeMAC project, but I have nowhere
near enough experience to even start such a thing.
--
bye,
pabs
[url]http://wiki.debian.org/PaulWise[/url]
--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
