Re: [DRAFT] resolving DFSG violations - Debian

This is a discussion on Re: [DRAFT] resolving DFSG violations - Debian ; On Thu, Oct 23, 2008 at 12:23:22PM -0500, Manoj Srivastava wrote: > On Thu, Oct 23 2008, martin f krafft wrote: > > It's all a matter of defining what your priorities are, which brings > > us back to ...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 98

Thread: Re: [DRAFT] resolving DFSG violations

  1. Re: [DRAFT] resolving DFSG violations

    On Thu, Oct 23, 2008 at 12:23:22PM -0500, Manoj Srivastava wrote:
    > On Thu, Oct 23 2008, martin f krafft wrote:


    > > It's all a matter of defining what your priorities are, which brings
    > > us back to the Social Contract, which says that these include:


    > > - 100% freeness
    > > - cater best to the interests of our users


    > Frankly, this mindset infuriates me. It frames the discussion
    > incorrectly, it implies that freeness and user interest are at
    > odds.


    No, it acknowledges that freeness and user interest are *sometimes* at
    odds, and leaves it up to humans with faculties of reason to sort out which
    of these two competing factors takes precedence in any given situation.

    Otherwise, it might as well have just said "Our priority is our users"; if
    you believe that what's best for free software is *always* what's best for
    our users, and that what's best for our users is to use only free software,
    then there's no need to spell this out as two *separate* priorities, right?

    For users whose world is not circumscribed by the boundaries of the Debian
    project, it is often the case that their short-term needs cannot be
    satisfied by strictly free-software solutions. To demand, then, that users
    make do with Free Software when it doesn't meet their needs is
    self-defeating: it denies us the support of users who are potentially
    sympathetic to the principles of Free Software, and it denies them the use
    of the best OS on the planet.

    To forestall the inevitable strawmen, I'll say plainly that I am *not*
    arguing that this justifies including non-free software in Debian proper.
    What I *am* arguing is that we are called by the Social Contract to help
    ensure Debian's continued utility to the general population, because if
    nothing else, that's where we find the next generations of developers who
    will keep our project alive. This doesn't mean we should all drop what
    we're doing and work on the firmware issue; but at the very least,
    developers shouldn't be sanguine about proposing the outright removal of
    firmware blobs, with no support for loading them from non-free, as a
    "solution".

    > The same goes for people who are complaining oabout advocates
    > of the social contract and libre software, calling them folks who do
    > not care for users. I contend that people who stuff main with non-free
    > stuff _are_ the ones acting against the interests of the users in the
    > long term,


    It's pretty insulting to suggest that there is a non-zero set of developers
    who have been "stuffing" non-free stuff into main, particularly when the
    very kernel team that's being maligned by this implication is the same group
    that has already done the heavy lifting of as much of the sourceless
    firmware removal as we've achieved so far.

    > Why is not putting non-free firmware in non-free not the right
    > thing to do?


    It is the right thing to do; and while I know there are people that
    disagree, I haven't seen anyone in *this thread* disagree with that. But
    there are lots of other things that are "right" to do, and not all of them
    are possible to achieve at the same time with limited resources. Is it
    still the Right Thing to remove non-free firmware if we don't also make it
    possible to load it from non-free at the same time? Is it the Right Thing
    to delay the next release indefinitely while the firmware problems are
    sorted out?

    Right now, I suspect the right thing to do might be for me to abandon this
    thread and go fix some bugs instead.

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    Ubuntu Developer http://www.debian.org/
    slangasek@ubuntu.com vorlon@debian.org


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

    On Fri, Oct 24, 2008 at 22:22, Manoj Srivastava wrote:

    > It should not take us an indefinite time to release with
    > firmware blobs gone. I'll stake my reutation that the period involved
    > is not indefinite, and there is a upper boundary to it.
    >
    > Testing out the patches that have been produced by Ben ought not
    > to take "indefinite" time. It took me just a couple of hours to test
    > the kernels on the four machines I own; and they worked just fine. Of
    > course, my machines are not affected by the firmware issues, so I know
    > this means little for the regression testing.


    I'm willing to stake my reputation on betting you are _not_ a firmware
    engineer. Your are totally wrong if you think all firmware blobs can
    be replaced by human readable source.

    There is hardware, for which to function, will always, for the
    lifetime of the equipment, require a firmware blob to operate. This
    will always be the case; there will never be a human readable version.
    It will never be possible to compile it (with non-free compilers) from
    source code. There seems to be the belief that there is some scary
    bogeyman at the end of this tunnel; some deliberate evil firmware
    engineer who refuses to release the "source" for the blob. This is
    hardly the case.

    In fact, the exact opposite is true; the most free pieces of hardware
    in the world require a firmware blob! A good example: try out the pci
    core from opencores.org. Even in that case, where you have the logic
    for the actual chip, you still have no choice but to distribute a
    firmware blob anyway.

    Going and flapping around and irritating hardware engineers with
    totally impossible requests (Give us your psoc firmware sourcecode or
    you suck! Thanks, the debian project.) makes us look like a bunch of
    clueless and irrational software engineers. You think there must be
    some magic way, well there is not.

    I doubt anyone reading this uses coreboot which means that the first
    instruction anyone ran today was a binary only firmware blob. Where is
    all your concern about that? Doubly annoying is that that firmware is
    actually x86 code and it is possible to get source code that can be
    compiled with gcc. That would actually be fruitful and practical.


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

  3. Re: [DRAFT] resolving DFSG violations

    On Sat, Oct 25, 2008 at 10:21 PM, Manoj Srivastava wrote:

    > Your argument boils down to: There is function that will never
    > be supported by free software.


    This is an incorrect assumption too, there are several pieces of free
    firmware already:

    Motorola DSP56001 (assembler for it is ITPed in #502508)

    prism54 wireless, the FreeMAC firmware (still in progress upstream)

    CHDK, firmware for some kinds of digital cameras

    rockbox, firmware for some kinds of digital music players

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

  4. Re: [DRAFT] resolving DFSG violations

    "Jeff Carr" wrote:

    > There is hardware, for which to function, will always, for the
    > lifetime of the equipment, require a firmware blob to operate. This
    > will always be the case; there will never be a human readable version.
    > It will never be possible to compile it (with non-free compilers) from
    > source code.


    How can that be? (That is an ernest question)

    The engineers will have some description of what the firmware should do
    (in terms of what to read and write from which register etc., not only
    in terms of "initialize communication"), and some rules how to translate
    these procedures into a binary blob.

    I doubt the translation needs to be done by hand, instead of by a
    compiler, but even if it was, wouldn't the software be useful? And
    couldn't the "description of what the firmware should do" be treated as
    the source, then?

    I mean, your argument seems to be "there is no such thing as source for
    firmware, so we cannot possibly require it". But isn't that description
    of the function just the source?

    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

  5. Re: [DRAFT] resolving DFSG violations

    On Sat, Oct 25, 2008 at 09:21, Frank Küster 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, no matter how good you intend on being, how much you love free
    software, you don't have any choice. Again, this is ironic since
    things like the opencores project are the most free hardware of all
    and are not given credit for it in this thread.

  6. Re: [DRAFT] resolving DFSG violations

    On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava wrote:

    > Your argument boils down to: There is function that will never
    > be supported by free software. Annoying people by asking them to expose
    > their function by freeing the software just irritates them, so we
    > should just suck it up and accept it.


    I don't think I'm explaining this well, as it seems you are still not
    getting it: there isn't any source code to get.

    > Guess how we cater to people who need non-free software for
    > some functionality they must have? We put it into a place called the
    > non-free archive.


    Great; totally useless raw data the chips on the machine need so we
    can write free device drivers to talk to them. Excellent. So the plan
    is: "Debian is only for hardware manufacturers that embed the firmware
    in flash. If you hide your non-free stuff, that'd be great because
    then we could pretend it doesn't really exist. Please don't disrupt
    our perfect version of how the world works."

    > You do not have to be a "firmware engineer" to grok that.


    I guess I'll find out. I think this proposal is just trying to pretend
    that there isn't firmware in the machines now. How does it help the
    free software movement if we try to ignore the non-free firmware
    booting our machines now? Why are we trying to shuffle that under the
    rug?

    > ps: back in the day, before I became a quantum mechanic, I toyed around
    > with seeing if designing microprocessors was for me. I did design a 27
    > instructions, 4 bit microprocessor with microcode, so I get what
    > firmware is.


    It depends,

    I'm talking about the synthesized image of the microprocessor (for the
    xlinux, altera, etc). I'm not talking about if you emulated it on
    solaris to check your processor (CS courses often do processor
    projects of that sort). I'm also not talking uboot/coreboot like
    firmware or psos-like things (also firmware but they _do_ have source
    code).

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

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


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

  7. Re: [DRAFT] resolving DFSG violations

    On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote:
    > "Jeff Carr" writes:
    >
    > > On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava wrote:
    > >
    > > > Your argument boils down to: There is function that will
    > > > never be supported by free software. Annoying people by asking
    > > > them to expose their function by freeing the software just
    > > > irritates them, so we should just suck it up and accept it.

    > >
    > > I don't think I'm explaining this well, as it seems you are still
    > > not getting it: there isn't any source code to get.


    I just want to find out: Under what circumstances does the blob need to
    be modified and who gets to do that modification?

    From earlier thread:

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


    Are these "chip manufacturer tools" physical tools/machines or software
    programs? (i.e. something I need to pick up in my hands or something I
    need to execute?) Is there any way that someone else can use the same or
    similar tools to modify the blob (even if it is only useful to do so on
    a different board / with a different chipset)?

    > If so, I don't get it either.
    >
    > If we use the “preferred form of the work for making modifications to
    > it” definition of source code, what is the form that best meets that
    > definition?


    If the chip is used on a different board with different configuration,
    is the blob going to need to be changed and who gets to change it? Can
    Debian include software that supports porting Debian to the new board or
    can the blob be used to lock Debian out? If I build a customised board
    myself, is the blob / lack of blob going to prevent me running free
    software on the chip/board?

    > If the vendor is able to send out a bit stream and (with or without
    > the owner's intervention) load that bit stream onto the
    > already-purchased hardware to modify its behaviour, then we just
    > crossed into the realm where the recipients of those bytes (the owners
    > of the hardware) deserve all the free-software freedoms in order to
    > retain ownership of their hardware.


    Sounds like a DRM type intervention.

    > If the bit stream is contained in hardware such that it not feasible
    > for the user *or* the vendor to modify, then they are both on equal
    > footing and it's much less important to demand free-software rights,
    > since the vendor doesn't have them either.
    >
    > > So yes, I think most people aren't going to "get" the issue unless
    > > they may have been firmware engineers.

    >
    > Thank you for continuing to discuss it; I'm genuinely interested in
    > testing the principles of software freedom to ensure they continue to
    > apply as computer designs change.


    From an embedded perspective - so am I. I admit, I know very little
    about the minutiae of hardware but I know I'm going to come up against
    these problems and I want to know more about fixing them - *without*
    needing to get permission from the chip manufacturers or getting their
    software tools or needing expensive hardware tools.

    --


    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)

    iEYEABECAAYFAkkFk4kACgkQiAEJSii8s+O2GgCg6MgIAINn4i 4xU2MIRlLTw5xR
    J0QAn0CQSwdInvYShXEY4H1HICxFj1YO
    =MdMk
    -----END PGP SIGNATURE-----


  8. Re: [DRAFT] resolving DFSG violations

    Neil Williams writes:

    > On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote:
    > > If the vendor is able to send out a bit stream and (with or
    > > without the owner's intervention) load that bit stream onto the
    > > already-purchased hardware to modify its behaviour,


    That qualifier in parentheses would perhaps be better worded as
    “(it's irrelevant for this distinction whether the user's
    intervention is required or not)”.

    In other words, I'm intending for this test to apply irrespective of
    whether we're talking about a firmware loading program that the user
    runs manually, or an automated phone-home update mechanism, or
    anything else. The test is only whether there is an intentional
    pipeline from “vendor distributes new bit stream” to “existing
    device now operating with newer vendor-supplied bit stream”.

    > > then we just crossed into the realm where the recipients of those
    > > bytes (the owners of the hardware) deserve all the free-software
    > > freedoms in order to retain ownership of their hardware.


    Further, if that bit stream is something we're proposing to be
    distributed as part of Debian, I'm saying this means that the Social
    Contract promises that the bit stream will be free.

    > Sounds like a DRM type intervention.


    Yes, that's one possible case, but I'm drawing a different line that
    may or may not encompass DRM. I hope that's clearer with the above
    expansion.

    > > If the bit stream is contained in hardware such that it not
    > > feasible for the user *or* the vendor to modify, then they are
    > > both on equal footing and it's much less important to demand
    > > free-software rights, since the vendor doesn't have them either.


    --
    \ “Here is a test to see if your mission on earth is finished. If |
    `\ you are alive, it isn't.” —Francis Bacon |
    _o__) |
    Ben Finney


    --
    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 10:10:19AM +0000, Neil Williams wrote:
    > On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote:


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


    > Are these "chip manufacturer tools" physical tools/machines or software
    > programs? (i.e. something I need to pick up in my hands or something I
    > need to execute?) Is there any way that someone else can use the same or


    Software.

    > similar tools to modify the blob (even if it is only useful to do so on
    > a different board / with a different chipset)?


    Ish. Someone else should be able to use the same tools (barring
    development environment issues) but modern FPGAs provide encryption
    mechanisms which mean that only someone posessing a security key blown
    into the hardware during the manufacturing process can generate an image
    that will be accepted.

    --
    "You grabbed my hand and we fell into it, like a daydream - or a fever."


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

  10. Re: [DRAFT] resolving DFSG violations

    On Sat, Oct 25, 2008 at 06:46:14AM -0700, Jeff Carr wrote:
    > I'm willing to stake my reputation on betting you are _not_ a firmware
    > engineer. Your are totally wrong if you think all firmware blobs can
    > be replaced by human readable source.
    >
    > There is hardware, for which to function, will always, for the
    > lifetime of the equipment, require a firmware blob to operate. This
    > will always be the case; there will never be a human readable version.
    > It will never be possible to compile it (with non-free compilers) from
    > source code. There seems to be the belief that there is some scary
    > bogeyman at the end of this tunnel; some deliberate evil firmware
    > engineer who refuses to release the "source" for the blob. This is
    > hardly the case.
    >
    > In fact, the exact opposite is true; the most free pieces of hardware
    > in the world require a firmware blob! A good example: try out the pci
    > core from opencores.org. Even in that case, where you have the logic
    > for the actual chip, you still have no choice but to distribute a
    > firmware blob anyway.


    I would expect anything on opencores.org to be perfectly readable VHDL
    code, which is the prefered format for manipulating it. So what was
    your point again? Besides FPGA's can work with eeproms, so no binary
    blob has to be distributed with the OS to work with the device.

    > Going and flapping around and irritating hardware engineers with
    > totally impossible requests (Give us your psoc firmware sourcecode or
    > you suck! Thanks, the debian project.) makes us look like a bunch of
    > clueless and irrational software engineers. You think there must be
    > some magic way, well there is not.


    For some firmware it does make sense, for others it does not.

    > I doubt anyone reading this uses coreboot which means that the first
    > instruction anyone ran today was a binary only firmware blob. Where is
    > all your concern about that? Doubly annoying is that that firmware is
    > actually x86 code and it is possible to get source code that can be
    > compiled with gcc. That would actually be fruitful and practical.


    Yes the BIOS doesn't include source code, but there also is no need for
    Debian to distribute the BIOS code in main for Debian to be able to
    install and run on my system.

    This whole debate is about Debian having to ship said firmware, not
    about whether hardware needs firmware or not. That is a different
    debate, but not one that directly involves the Debian distribution.

    So much as closed source binaries and firmware on flash chips in raid
    controllers may be annoying, it does not in any way affect the freeness
    of the code _distributed_ by Debian.

    --
    Len Sorensen


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

  11. Re: [DRAFT] resolving DFSG violations

    On Sun, Oct 26, 2008 at 06:38:53PM -0700, Jeff Carr wrote:
    > 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.


    But you provide input to the tool, usually VHDL code or similar. That
    would be the source, and you can provide that. That is the prefered
    format for editing. We use plenty of FPGAs at work, and I have seen how
    they are programmed, and yes I have seen what the source looks like. It
    is certainly human readable source code. If you think otherwise, then
    you don't know how FPGAs and CPLDs work.

    The tool doesn't have a magic buttong labeled 'make the chip do what I
    am thinking of now".

    > So, no matter how good you intend on being, how much you love free
    > software, you don't have any choice. Again, this is ironic since
    > things like the opencores project are the most free hardware of all
    > and are not given credit for it in this thread.


    And opencores.org distributes source, not binary blobs. Gee whiz.

    --
    Len Sorensen


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

    On Mon, Oct 27, 2008 at 11:35, Lennart Sorensen
    wrote:
    > On Sun, Oct 26, 2008 at 06:38:53PM -0700, Jeff Carr wrote:
    >> 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.

    >
    > But you provide input to the tool, usually VHDL code or similar. That
    > would be the source, and you can provide that. That is the prefered
    > format for editing. We use plenty of FPGAs at work, and I have seen how
    > they are programmed, and yes I have seen what the source looks like. It
    > is certainly human readable source code. If you think otherwise, then
    > you don't know how FPGAs and CPLDs work.


    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

    > The tool doesn't have a magic buttong labeled 'make the chip do what I
    > am thinking of now".
    >
    >> So, no matter how good you intend on being, how much you love free
    >> software, you don't have any choice. Again, this is ironic since
    >> things like the opencores project are the most free hardware of all
    >> and are not given credit for it in this thread.

    >
    > And opencores.org distributes source, not binary blobs. Gee whiz.


    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.

    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.

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


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

  13. Re: [DRAFT] resolving DFSG violations

    On Mon, Oct 27, 2008 at 11:26, Lennart Sorensen
    wrote:

    > I would expect anything on opencores.org to be perfectly readable VHDL


    Hardly perfectly readable - I put up code there too

    > code, which is the prefered format for manipulating it. So what was
    > your point again? Besides FPGA's can work with eeproms, so no binary
    > blob has to be distributed with the OS to work with the device.


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


    --
    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 Mon, Oct 27, 2008 at 05:36, Mark Brown wrote:

    >> similar tools to modify the blob (even if it is only useful to do so on
    >> a different board / with a different chipset)?

    >
    > Ish. Someone else should be able to use the same tools (barring
    > development environment issues) but modern FPGAs provide encryption
    > mechanisms which mean that only someone posessing a security key blown
    > into the hardware during the manufacturing process can generate an image
    > that will be accepted.


    What you said here doesn't make any sense. Barring development
    environment issues? That's just skimming the surface of the issues.


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

  15. Re: [DRAFT] resolving DFSG violations

    Jeff Carr wrote:

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


    Please explain what the issues are, then. The firmware blob has to be generated
    *somehow*. There is a tool that generates the blob. Which data does the tool
    need to generate it?

    --

    Felipe Sateler


    --
    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, Oct 27, 2008 at 03:10, Neil Williams wrote:

    > I just want to find out: Under what circumstances does the blob need to
    > be modified and who gets to do that modification?


    Probably only the hardware engineers.

    > Are these "chip manufacturer tools" physical tools/machines or software
    > programs? (i.e. something I need to pick up in my hands or something I
    > need to execute?)


    kind of. Modern machines are designed on older machines using software
    of some sort or another.

    > Is there any way that someone else can use the same or
    > similar tools to modify the blob (even if it is only useful to do so on
    > a different board / with a different chipset)?


    no, not usually unless you are the one that designed the board.

    > If the chip is used on a different board with different configuration,


    then you would generate your own firmware blob

    > is the blob going to need to be changed and who gets to change it? Can


    you as the board designer

    > Debian include software that supports porting Debian to the new board or


    thats where you write a gpl kernel driver

    > can the blob be used to lock Debian out? If I build a customised board
    > myself, is the blob / lack of blob going to prevent me running free
    > software on the chip/board?


    yes, if you don't load the blob into the chip, the chip stays
    un-initialized. Thats what /lib/firmware is for.

    You can put the blob on a flash chip in hardware to avoid software
    needing to load it, but on cheap devices, the manufacturers are
    usually trying to save on the cost of another chip.

    > Sounds like a DRM type intervention.


    no, that's something totally different. This firmware blob just tells
    the chip what it's wires do (electriclly/logically)

    > From an embedded perspective - so am I. I admit, I know very little
    > about the minutiae of hardware but I know I'm going to come up against
    > these problems and I want to know more about fixing them - *without*
    > needing to get permission from the chip manufacturers or getting their
    > software tools or needing expensive hardware tools.


    If you what to change how the chip works outside of the device you
    purchased you wouldn't be purchasing that device. For instance, you
    aren't going to be able to take a usb/ethernet device and turn it into
    a usb/sata device even if the chip was capable of it -- you'd have to
    change the board layout so changing the firmware blob there doesn't
    make any sense.

    In any case, all of this is theoretical; it's just doesn't make any
    sense to change the manufacturer firmware blob. If you want to do that
    and are smart and experienced enough, you would start your own company
    building hardware devices and compete with whatever device it is that
    isn't doing what you need it to do. That would be much easier than
    trying to change a chip/board you don't have schematics for.


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

  17. Re: [DRAFT] resolving DFSG violations

    On Mon, Oct 27, 2008 at 00:31, Ben Finney wrote:

    > If we use the "preferred form of the work for making modifications to
    > it" definition of source code, what is the form that best meets that
    > definition?
    >
    > What form of the work do the copyright holders use to make changes to
    > it?


    Usually it's whatever the chip manufacturer provides.


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

  18. Re: [DRAFT] resolving DFSG violations

    "Jeff Carr" writes:

    > On Mon, Oct 27, 2008 at 00:31, Ben Finney wrote:
    >
    > > If we use the "preferred form of the work for making modifications
    > > to it" definition of source code, what is the form that best meets
    > > that definition?
    > >
    > > What form of the work do the copyright holders use to make changes
    > > to it?

    >
    > Usually it's whatever the chip manufacturer provides.


    That doesn't seem to address my question. Here, “the copyright
    holders” means the copyright holders in the work under question; i.e.
    the work whose freedom is being discussed: the bundle of bits that get
    redistributed with the driver for loading onto the hardware.

    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.

    --
    \ “The future always arrives too fast, and in the wrong order.” |
    `\ —Alvin Toffler |
    _o__) |
    Ben Finney


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

  19. Re: [DRAFT] resolving DFSG violations

    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.
    It would also expose you to the tools that the hardware and logic
    engineers use to do this process. It would also expose you to the
    pre-requisite knowledge of the board design (layout, etc) that you
    have to have. Then I think it would make sense to you why this
    conversation doesn't make sense right now. It's that these "binary
    only blobs" only make sense to the chip. It's like they are a map of
    how the transistors are to function -- an oversimplification -- but
    generally that's the nature of it. *

    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. As a
    hardware engineer I can give you all the registers and an API and even
    some sample GPL code so you can write a device driver. Now, some
    people are smucks like nvidia and they don't give out diddly. Still,
    the firmware blob that you load into the chip isn't x86 code for the
    host -- it's raw junk for the chip. It's a totally different issue
    than distributing a binary only nvidia driver. That's not what I'm
    talking about here. 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. Once you
    have the chip initialized then you can hook it up to an oscilloscope
    to debug it (or maybe you're lucky and you can already talk to it from
    your device driver).

    * http://en.wikipedia.org/wiki/Floorpl...croelectronics)
    * http://en.wikipedia.org/wiki/Logic_synthesis
    * http://en.wikipedia.org/wiki/Place_and_route


    --
    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 Mon, Oct 27, 2008 at 08:30:38PM -0700, Jeff Carr wrote:
    > 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


    You are assuming there is gap when there may be not.

    > 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.
    > It would also expose you to the tools that the hardware and logic
    > engineers use to do this process. It would also expose you to the


    Would those be tools like a Verilog or VHDL synthetizer distributed by a
    FPGA manufacturer? Considering the hardware is FPGA, of course. In the
    case it is not, I assume there would still be procedures like logic
    design, routing, etc.

    > pre-requisite knowledge of the board design (layout, etc) that you
    > have to have. Then I think it would make sense to you why this
    > conversation doesn't make sense right now. It's that these "binary
    > only blobs" only make sense to the chip. It's like they are a map of


    So, why do they only make sense to the chip? Is it because there is no
    current implementation of a software simulator? And why would a software
    simulator not be feasible? The binary blobs would make sense to the
    simulator.

    > how the transistors are to function -- an oversimplification -- but
    > generally that's the nature of it. *
    >
    > 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. As a
    > hardware engineer I can give you all the registers and an API and even
    > some sample GPL code so you can write a device driver. Now, some
    > people are smucks like nvidia and they don't give out diddly. Still,
    > the firmware blob that you load into the chip isn't x86 code for the
    > host -- it's raw junk for the chip. It's a totally different issue


    If it's not clear by now, people are not arguing that hardware should
    not be used if it is not free hardware (either it is feasible or not to
    distribute or exist source code). The matter is whether source for code
    that will not execute in the main CPU is needed for those codes in the
    main section. So, your point that it is not x86 code is moot in the case
    "firmware" is considered to be the same as other software in Debian. If
    source code isn't available or "possible" for the chip carries the same
    requirements for DFSG as the case would be for the x86 code, in the case
    "firmware" should still follow DFSG.

    > than distributing a binary only nvidia driver. That's not what I'm
    > talking about here. 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 machine readable form would still be considered source if its
    interpretation by the machine could be presented to someone to make
    modifications to it. If it is not modifiable for some reason and every
    design should be done from scratch, perhaps there is a problem with the
    tools and/or processes used.

    > Even the chip manufacturers don't know what they are. It's totally
    > machine generated chip garbage as far as they are concerned. Once you


    Which machines do generate this "garbage"? Do they do it all by
    themselves? Are there machines designing new hardware now without human
    intervention? Or are those chips magically enhanced so they could make
    some sense of any random bitstream and there is no real mistery in
    generating this "garbage"?

    If the manufacturers are unaware of it, I doubt the designer is unaware
    of it.

    > have the chip initialized then you can hook it up to an oscilloscope
    > to debug it (or maybe you're lucky and you can already talk to it from
    > your device driver).
    >
    > * http://en.wikipedia.org/wiki/Floorpl...croelectronics)
    > * http://en.wikipedia.org/wiki/Logic_synthesis
    > * http://en.wikipedia.org/wiki/Place_and_route
    >
    >
    > --
    > To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    >


    Regards,
    Cascardo.

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

    iEYEARECAAYFAkkGmOoACgkQyTpryRcqtS0yFQCdGSdQZNTlQl QmZ/cDuZUOi2fX
    XlUAniXv2E9mAo0pHr6NlZPBOdeIfASf
    =xk8u
    -----END PGP SIGNATURE-----


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