On Tue, 2008-10-28 at 22:51 +1100, Ben Finney wrote: > 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. 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. > 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. 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. > 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. (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.) > 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. 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part