Re: Free OS versus free hw
On Tue, Oct 28, 2008, Ben Finney wrote:
> The requirement for the contents of Debian to be free is not a new
> burden.
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.
> 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.
Yes, perhaps we need to delimit what this covers exactly.
> 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.
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.
> 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.
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.
> > 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.
>
> 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.
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.
> 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
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.
> 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 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?
> 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.
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.
--
Loïc Minier
Reply to: