Re: [DRAFT] resolving DFSG violations - Debian

This is a discussion on Re: [DRAFT] resolving DFSG violations - Debian ; "Jeff Carr" writes: > On Mon, Oct 27, 2008 at 18:41, Ben Finney wrote: > > > Whoever the copyright holder of that work is (I read your remark > > above to mean that the hardware manufacturer is that ...

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 98

Thread: Re: [DRAFT] resolving DFSG violations

  1. Re: [DRAFT] resolving DFSG violations

    "Jeff Carr" writes:

    > On Mon, Oct 27, 2008 at 18:41, Ben Finney 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


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: [DRAFT] resolving DFSG violations

    * Ben Finney [2008-10-28 16:38:41 +1100]:

    > > 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 “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”?


    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.

    > 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?


    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)

    iEYEARECAAYFAkkGwDMACgkQpNuXDQIV94rwAQCfd16x1bS5I9 7gd6BPHNwOavcR
    5dAAnRIBJ7jnMmVGkKp3ho6U9qZuEpbx
    =GLxZ
    -----END PGP SIGNATURE-----


  3. Free OS versus free hw

    On Mon, Oct 27, 2008, Jeff Carr wrote:
    > 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.


    Right; I share your concerns with the new burden Debian is attaching to
    itself when requiring the loadable firmwares to be free.

    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.

    At the same time, I'd love our DFSG to reject software which is written
    with unavailable documentation and unmaintainable without it.


    I see it much in the same way as when I'm interfacing thanks to a
    protocol with some remote servers: Google might be running proprietary
    software on its servers, but because we're exchanging HTTP/HTML we can
    interface with each other.
    Concerning hardware (with firmware builtin or firmware to preload), I
    care that I can ask the hardware to do stuff I care about.
    In the same way I can't fix bugs on the Google server, I can't fix
    bugs in firmware running on the hardware of my machines.

    Naturally, I'd love firmware to be freed up, or to only interface with
    servers running free code which I could inspect or replace if needs be.
    But this is a huge project, different from building an OS. OpenMoko
    does a good job at building a free hardware + software stack, but it
    still has the GSM stack closed; I find this perfectly acceptable
    because they interface over a serial port interface with it. There are
    other projects to free graphics, or for x86 based hardware.


    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?

    --
    Loc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Free OS versus free hw

    Loïc Minier writes:

    > On Mon, Oct 27, 2008, Jeff Carr wrote:
    > > 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.

    >
    > Right; I share your concerns with the new burden Debian is
    > attaching to itself when requiring the loadable firmwares to be
    > free.


    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.

    > 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.

    > 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?


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Free OS versus free hw

    On Tue, Oct 28, 2008 at 10:51:55PM +1100, Ben Finney wrote:
    [...]
    > *without* access to any specific extra data, vendor-specific programs,
    > or other non-free software.


    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.

    [...]
    > Ben Finney


    Cascardo.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkkHAP0ACgkQyTpryRcqtS2+cQCeKWyjbqFN+U tX7XJ7RNAnM8L5
    IqsAoIdNsmkezT95V7XO5XMyv6qpUieY
    =76BH
    -----END PGP SIGNATURE-----


  6. Re: Free OS versus free hw

    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/



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkHBpkACgkQiAEJSii8s+N9dACgnIsWCdn5Ln JngV+WkkgTFxlg
    i50AoIcdJYjSVMh2F6xXTOG9PPE5lX9J
    =LVlT
    -----END PGP SIGNATURE-----


  7. Re: Free OS versus free hw

    Neil Williams writes:

    > In the end, it comes down to "the preferred form for modification"


    I am convinced that's the most useful place to draw the line, yes.

    > 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.


    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?

    > Can we agree on this and get back to releasing Lenny?
    >
    > (please?)


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: [DRAFT] resolving DFSG violations

    On Mon, Oct 27, 2008 at 12:26:31PM -0700, Jeff Carr wrote:
    > 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


    I have a different theory.

    > 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.


    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).

    > 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.


    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.

    > 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).


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: [DRAFT] resolving DFSG violations

    On Mon, Oct 27, 2008 at 12:29:58PM -0700, Jeff Carr wrote:
    > Hardly perfectly readable - I put up code there too


    Oh well. Some people write ugly perl code, some write ugly VHDL. Not
    the language or tools fault, just bad programmers.

    > Which is often not the case on cheap devices (often usb) because of
    > cost, space, power, etc for another chip.


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Free OS versus free hw

    Hi,

    > 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.


    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.

    > 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.


    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)

    iJwEAQECAAYFAkkHMfoACgkQ0sfeulffv7tKGwP7BSyhRdkFiU oHx8nHsDne97wd
    Mfv0ERsec4KodGrL7n8CD03kIa8HaQAaTZXBLr7Vo5N+tTf8FC rfRFiuIY4uGiik
    pvI06n5YKqrqLVjS9c+/8x71Vt/lu+q9F9j92q7XiBUjWFFkzvoDu9ieWOLtEq4I
    u0bPepuDfxwll/3u4YM=
    =GdnY
    -----END PGP SIGNATURE-----


  11. Re: [DRAFT] resolving DFSG violations

    Thadeu Lima de Souza Cascardo (2008-10-28 16:07 -0200) wrote:

    > On Tue, Oct 28, 2008 at 06:01:45PM +0100, David Weinehall wrote:
    >> Throwing out the firmware doesn't help our users, it makes things
    >> worse for our users. And our users are our number one priority.

    >
    > Is it not providing them the best free/libre operating system?


    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. http://lkml.org/lkml/2006/9/27/414


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: [DRAFT] resolving DFSG violations

    "Jeff Carr" wrote:

    > On Sat, Oct 25, 2008 at 09:21, Frank Kster wrote:
    >
    >> How can that be? (That is an ernest question)

    >
    > 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.


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. 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.

    --
    Loc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: [DRAFT] resolving DFSG violations

    On Sun, 2008-10-26 at 20:17 -0700, Jeff Carr wrote:
    [...]
    > 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.


    You have to synthesise *from* something, be that Verilog or VHDL or
    Handel-C.

    > 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.


    Sure, it's not a program in the usual sense, but there is a source for
    it.

    > 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.


    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.

    > 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.


    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.

    > 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.


    IANAFE, though I probably will be soon.

    Ben.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBJB6uy79ZNCRIGYgcRAtK5AKCwXH1RhDi04FeRl5xtED HGwkPpMACgvuBn
    t+ZfdmLMBFi0cheuAhz6PHQ=
    =Y6as
    -----END PGP SIGNATURE-----


  15. Re: Free OS versus free hw

    Loïc Minier writes:

    > On Tue, Oct 28, 2008, Ben Finney wrote:
    > > 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.


    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.

    > > 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.


    Simply because anything that we ship as part of Debian must be
    DFSG-free.

    > 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.


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Re: [DRAFT] resolving DFSG violations

    On Mon, 2008-10-27 at 13:01 -0700, Jeff Carr wrote:
    [...]
    > In any case, all of this is theoretical; it's just doesn't make any
    > sense to change the manufacturer firmware blob.

    [...]

    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)

    iD8DBQBJB64079ZNCRIGYgcRAhwWAKC7SUvSHlP4UddhEaFZ7p k9AXb7/QCgyNbm
    MNCv1yxdL0VfJHMcaUI3n1I=
    =hx2M
    -----END PGP SIGNATURE-----


  17. Re: [DRAFT] resolving DFSG violations

    On Mon, 2008-10-27 at 20:30 -0700, Jeff Carr wrote:
    [...]
    > 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.

    [...]

    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)

    iD8DBQBJB7DD79ZNCRIGYgcRAvFkAJ9LpMM8RwvF8J2NDKsGl6 3m1I9MlQCglvVK
    UAHeWGtUBJEbiZug4E2aTCM=
    =Cxwy
    -----END PGP SIGNATURE-----


  18. Re: [DRAFT] resolving DFSG violations

    On Tue, 2008-10-28 at 18:01 +0100, David Weinehall wrote:
    [...]
    > 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)?


    Does the "EEP" mean nothing to you?

    > 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).


    Agreed.

    [...]
    > 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.

    [...]

    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)

    iD8DBQBJB7YR79ZNCRIGYgcRAmy1AJ4x8dcaLrYyMl2Cm6HKGG BsCSdJWgCeIggX
    YlO42pf3uPdGNB2DFbKG6yw=
    =UWxW
    -----END PGP SIGNATURE-----


  19. Re: [DRAFT] resolving DFSG violations

    Ben Hutchings writes:

    > This situation sucks. But we cannot claim to have a 100% free
    > distribution while including sourceless firmware.


    That is my main concern, yes.

    > 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.


    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  20. Re: [DRAFT] resolving DFSG violations

    On Wed, Oct 29, 2008 at 2:01 AM, David Weinehall wrote:

    > 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.


    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.

    > 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.


    Intel have resolved my bug report about source code for the firmware
    as wontfix, citing the FAQ about the FCC:

    http://www.intellinuxwireless.org/bu...ug.cgi?id=1594

    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

    http://wiki.debian.org/PaulWise


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast