Re: [DRAFT] resolving DFSG violations - Debian

This is a discussion on Re: [DRAFT] resolving DFSG violations - Debian ; On Wed, Oct 29, 2008, Ben Finney wrote: > > 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. ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 98

Thread: Re: [DRAFT] resolving DFSG violations

  1. Re: Free OS versus free hw

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


    Yes; we agree on the current constraints.

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


    Of course, producing a Debian including free firmwares would be
    superior than producing a Debian which ships non-free firmwares, but
    the actual option at hand is producing a Debian without the firmwares.

    Naturally, I can imagine some people making use of the free firmwares
    would they be available in Debian, but:
    - this would probably be very little people
    - it would be almost impossible to get the sources for all firmwares
    generally useful to run a modern computer, as well as associated
    compilers and hardware documentation; the FCC regulations make this
    hard for instance
    - this forces an effort for hardware which requires runtime loading of
    a firmware, but does not force anything for hardware which has
    preloaded firmware in flash or rom; so we effectively made the
    freeness cover firmware for some random hardware
    - this could be achieved by a separate project while still having an
    useful and free Debian OS, except for firmware files

    The size and risks of the task versus it's usefulness makes me think
    the ghetto will rather be Debian if we can't support common PCs.

    --
    Loïc Minier


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

  2. Re: Free OS versus free hw

    Loïc Minier writes:

    > Of course, producing a Debian including free firmwares would be
    > superior than producing a Debian which ships non-free firmwares,
    > but the actual option at hand is producing a Debian without the
    > firmwares.


    Since the Social Contract promises Debian *won't* ship non-free
    things, that's not an option compatible with the promises made by the
    Debian project.

    > Naturally, I can imagine some people making use of the free
    > firmwares would they be available in Debian, but:


    > - this would probably be very little people


    The same argument can be made for free software targeted to the
    motherboard CPU. It can also be refuteded with similar
    counter-arguments: for example, those few who *can* make use of free
    software can improve and redistribute it, thereby benefiting many
    others beside themselves. This is only possible if the work is
    distributed as free software.

    > - it would be almost impossible to get the sources for all
    > firmwares generally useful to run a modern computer


    I only expect the Debian project to hold to its promises for
    distributing Debian as free software. Any firmware not being
    distributed by Debian is outside the aegis of the project.

    --
    \ “Probably the toughest time in anyone's life is when you have |
    `\ to murder a loved one because they're the devil.” —Emo Philips |
    _o__) |
    Ben Finney


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

  3. Re: Free OS versus free hw

    Ben Finney writes:

    > Loïc Minier writes:
    >
    > > Of course, producing a Debian including free firmwares would be
    > > superior than producing a Debian which ships non-free firmwares,
    > > but the actual option at hand is producing a Debian without the
    > > firmwares.

    >
    > Since the Social Contract promises Debian *won't* ship non-free
    > things, that's not an option compatible with the promises made by
    > the Debian project.


    Poorly worded on my part. Try this:

    Since the Social Contract promises Debian *won't* contain non-free
    things, [shipping non-free firmware in Debian] is not an option
    compatible with the promises made by the Debian project.

    --
    \ “I call him Governor Bush because that's the only political |
    `\ office he's ever held legally.” —George Carlin, 2008 |
    _o__) |
    Ben Finney


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

    On Wed, Oct 29, 2008, Ben Finney wrote:
    > Since the Social Contract promises Debian *won't* ship non-free
    > things, that's not an option compatible with the promises made by the
    > Debian project.


    I might not have said it clearly enough:
    - I agree the current DFSG and social contract imply we need to provide
    sources for these firmware if they are shipped in Debian
    - in turn, this implies that I'm suggesting we might need to reword
    parts of them to reduce the perimeter of Debian to something
    achievable which we still love and aim for

    Ah I'm certainly going to get a pile of flame-ish mails for suggesting
    we might need to change the social contract of the DFSG. It remains
    that the current versions imply a too large work which I think
    shouldn't be Debian's.

    > > - this would probably be very little people

    > The same argument can be made for free software targeted to the
    > motherboard CPU. It can also be refuteded with similar
    > counter-arguments: for example, those few who *can* make use of free
    > software can improve and redistribute it, thereby benefiting many
    > others beside themselves. This is only possible if the work is
    > distributed as free software.


    Yes; it just helps putting things in perspective. Just like when we
    decide to remove free software from the archive. This is not an
    argument that the firmwares shouldn't come with source code, it's an
    argument that if we allowed firmwares to come without source code, it
    wouldn't affect a lot of people. Of course it would still affect some
    people. If this itch is worth scratching, another project could be
    started or these people could join one of the "free hardware" projects
    which are becoming more common these days.

    --
    Loc Minier


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


    [Teemu Likonen]
    > 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".


    Did you miss the other sentence? "We promise that the Debian system
    and all its components will be free according to these guidelines."

    You can argue about whether the firmware files meet the DFSG source
    requirement when they don't have separate source code. You can argue
    whether this violates the GPL on the kernel drivers. But I don't see
    how you can argue that the firmware files we distribute on our CDs are
    not part of "the Debian system and all its components".
    --
    Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

  6. Re: Free OS versus free hw

    On Tue, Oct 28, 2008 at 8:38 AM, Simon Richter wrote:
    > 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.
    > (snip)
    > Almost the same thing goes for FPGAs, which need to be optimized for the
    > specific chip.
    > (snip)
    >
    > 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
    >


    I'm not a DD and didn't want to jump into the middle of what had been
    a heated discussion, but I've done a bunch of hardware work and I've
    realized reading related discussions over the past week that many DD's
    might not be familiar with some of the lower-level complexities.
    Simon mentioned that free compilers aren't available for many devices.
    Of course the next logical question is: why not create a free
    compiler? It isn't that easy (and in some cases impossible because at
    least Xilinx and Altera are very unlikely to cooperate, as Simon
    alludes).

    In the FPGA/CPLD world, Xilinx and Altera are the top vendors. VHDL
    source code to run on their chips would be better than a binary blob.
    As Simon mentions, although there are free tools for synthesizing VHDL
    ("synthesizing" is the English term usually used for "compiling"
    VHDL), those tools won't produce anything that will run on Xilinx or
    Altera FPGAs. You must use the manufacturers' own non-free (except
    sometimes for student editions), non-open tools to synthesize your
    VHDL.

    The format of the final blob is something those two manufacturers
    treat as proprietary. Knowing the structure of a Xilinx or Altera
    binary blob would give their "Hertz vs. Avis" competitor insight into
    their devices' low-level chip architecture. Without the binary blob
    structure being public knowledge, you'll never see open tools to
    synthesize VHDL that will actually run on these devices.

    But at least if you could get the VHDL source, it would be an
    improvement over just a binary blob. You'd then have something you
    could maintain, albeit with non-free tools. On the flip side, this
    also means that nobody can just tweak some values in a binary file for
    a Xilinx or Altera device -- the VHDL source must exist somewhere.


    Many non-FPGA microprocessors load programs and otherwise update
    EEPROM locations using the Intel Hex File format. In this case,
    source code for a program probably exists written in assembler or some
    higher-level language. However, it is reasonable for a vendor to use
    a raw Intel Hex File to modify a few parameter values at specific
    EEPROM locations on their device once the main program is loaded. The
    only other case I can think of a vendor _maybe_ writing a raw Intel
    Hex File instead of at least assembly language source might be to
    create a highly optimized, very tiny bootloader. But even then, they
    should be able to get the smallest machine code possible using a good
    assembler.

    So for a tiny bootloader or to just modify some parameters stored at
    fixed EEPROM addresses, it is reasonable for a vendor to only use a
    binary blob (Intel Hex File or some equivalent). From the point of
    view of long-term maintenance though, any sane vendor should be
    maintaining anything larger than that in some type of source code
    form.

    FWIW, PostScript can at times be considered a proper source language.
    Along the lines of "when all you have is a hammer everything looks
    like a nail," since I know PostScript I've often directly written
    PostScript programs to generate graphics images, calendars, etc.

    "The reasonable man adapts himself to the world; the unreasonable one
    persists in trying to adapt the world to himself. Therefore all
    progress depends on the unreasonable man." -- George Bernard Shaw


    Paul Hardy
    GPG Key ID: E6E6E390


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

  7. Re: Free OS versus free hw

    Loïc Minier writes:

    > On Wed, Oct 29, 2008, Ben Finney wrote:
    > > Since the Social Contract promises Debian *won't* ship non-free
    > > things, that's not an option compatible with the promises made by
    > > the Debian project.

    >
    > I might not have said it clearly enough:
    > - I agree the current DFSG and social contract imply we need to
    > provide sources for these firmware if they are shipped in Debian
    > - in turn, this implies that I'm suggesting we might need to reword
    > parts of them to reduce the perimeter of Debian to something
    > achievable which we still love and aim for


    Thanks for making it clear.

    I disagree completely with that suggestion. I agree with the current
    promise that all of Debian (that is, the operating system in whole and
    all its parts) must be free.

    --
    \ “Whenever you read a good book, it's like the author is right |
    `\ there, in the room talking to you, which is why I don't like to |
    _o__) read good books.” —Jack Handey |
    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

    Am 2008-10-28 09:33:07, schrieb Tristan Seligmann:
    > Again, assuming I'm not misspeaking, that form of the work is already
    > what we have.


    ACK ;-)

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCNgyC0FPBMSS+BIRAs+cAKCocY/n1jPiupWp94a+DYS2mZbEsACdFfBk
    9QiQ7owYjdhqIDC8K+ENhss=
    =6xUz
    -----END PGP SIGNATURE-----


  9. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-28 12:41:31, schrieb Ben Finney:
    > "Jeff Carr" writes:
    > > 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.


    I use a 8000 US$ software under Windows XP to build highly optimized
    (very small) firmware and there is nothing like a C source code.

    The project IS a binary blob which then can directly uploaded into the
    device.

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCNOzC0FPBMSS+BIRApcLAJ4i2LsJAe9eSDKsoX+8cB YJESjXLQCfcfD2
    YJM7CqoAhmck0lcwW7K0x4o=
    =0uVj
    -----END PGP SIGNATURE-----


  10. Re: [DRAFT] resolving DFSG violations

    Hi Jeff,

    Am 2008-10-27 12:26:31, schrieb Jeff Carr:
    > Some modern devices let the OS load this code
    > into the chip then we are able to write fully GPL drivers for the
    > device.


    This sounds a little bit weird...

    What does have the FIRMWARE to do with a DEVICE DRIVER?

    The FIRMWARE is intend to be loaded INTO the DEVICE, and then the DEVICE
    DRIVER is in the OS to access the hardware. The DEVICE DRIVER can be
    anyway written under GPL even if the FIRMWARE is a binary blob.

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCNtPC0FPBMSS+BIRAtOJAKCYSf2Blcpi/cm69RmTYF16UxeFWQCglneI
    2NOdZ2glIIpJXa5eob7MKZg=
    =4LHz
    -----END PGP SIGNATURE-----


  11. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-29 00:39:40, schrieb Ben Hutchings:
    > 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...


    Most PCI hardware has a very small bootloader which checks some signals
    on the PCI bus... I have a book about it but no time to read in since
    it is very complicated...

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCNjgC0FPBMSS+BIRAtptAKDGCIb/ph/m0U3jYqB8N0JRzz2uOgCeMlsd
    QMfOpzr3/drPvL/u5+2Spl4=
    =lwGW
    -----END PGP SIGNATURE-----


  12. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-28 02:45:31, schrieb Thadeu Lima de Souza Cascardo:
    > 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.


    Anw what do you do with sourcode, for which there is not even a compiler
    availlable under Linux/BSD? And you HAV to buy a 8000 US$ development
    suit from the chip manufacturer to build the firmware?

    I have such software and EVEN me can not read the firmware.

    I have ONLY a "project" in my IDE and it produce the firmware.

    And now you!

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


    Do you have already tried to modify a binary blob or simply opened a (no
    mather which) binary from /bin/ in a HEX editor and tried to modify it?

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


    The software/IDE use "projects" which are not in human readable form...
    ...and if you have finisched, you klick the button "Output firmware"
    and then you have the firmware blob.

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


    ???

    It seems you have never designed Hardware or realy coded software for it

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCNanC0FPBMSS+BIRApJiAKCCnZK3QiyzGvyTkWZukz 9tS/pEPQCguDFI
    Xu5ZaWIMLJ0XGo1nYPJ7bSE=
    =T6qR
    -----END PGP SIGNATURE-----


  13. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-28 10:00:31, schrieb Lennart Sorensen:
    > 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).


    Curently I am building a hardware where the parts cost arround 40US$ per
    device (@10.000) and using the same microcontroller with a "big" FLASH
    memory would mke this Hardware arround 5 US$ in final production more
    expensive.

    So for the end-users arreound 10 US$ or 8 Euro

    Are you willing to pay arround 15-18% more for such hardware?

    Also you shouls know, that code generated by SDCC is 3 times bigger then
    the one build by my IDE provided by the Microcontroller manufacturer.

    Which mean, I must switch from a 32 kByte model to a 128 kByte one.

    Or by attaching an external NVRAM of 128 kByte like the Atmel AT29BV010A
    and I think, you can check the price for yourself...

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


    Again: ARE you realy willing to pay at least
    10US$ or 8 more for the hardware?

    I mean, the I am trying currently servera hardware models since I need
    highly optimized one (for solar-Energie Systems) and there is nothing in
    production yet. I am 100% free what to do and how I do it...

    Since all of my software must run under GNU/Linux and is licensed under
    GNU GPL version 3 I like to see, that my hardware/Software fit the DFSG
    which mean, must run with "main".

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCO13C0FPBMSS+BIRArSiAKDVQzBNOzoyDaIcm4K2YB CZMv6bMwCgjqFU
    wdp8gwclzIHBJzEwBrbop48=
    =U1at
    -----END PGP SIGNATURE-----


  14. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-27 17:01:50, schrieb Felipe Sateler:
    > 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?


    The IDE/Software which produce the firmware blobs mostly generate it
    directly and the projects the developers are using are binary stuff.

    Parts of it maybe human readable but not suffisant to compile it or do
    anything usefull with it.

    And as I have already written, SDCC compiled code is 3 times bigger as
    the firmeware blob generated by a 8000 US$ IDE.

    And using a Microcontroller/ASIC with bigger memory is no solution since
    sometimes it would be very costly...

    In my case arround 3 million Euro more for the final production (18mio).

    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFJCNx0C0FPBMSS+BIRAug4AJsE4SVwEHJKzTl6kXA8AZ bVSL3/cACfaGXJ
    b1s1IqBvyycDVXli0lShz+M=
    =pvCM
    -----END PGP SIGNATURE-----


  15. Re: [DRAFT] resolving DFSG violations

    On Wed, 2008-10-29 at 22:33 +0100, Michelle Konzack wrote:
    >
    > Anw what do you do with sourcode, for which there is not even a
    > compiler
    > availlable under Linux/BSD? And you HAV to buy a 8000 US$
    > development
    > suit from the chip manufacturer to build the firmware?


    Free software is an iterative process; we started with nothing, using
    proprietary C compilers, kernel, libc - everything. And we iterated, and
    iterated - now we have a free stack including BIOS, and are continuing
    to push freedom deeper down the stack.

    I feel for you that you are on the cutting edge, where you cannot do
    what you need to do without spending 8K US to buy a proprietary tool.

    > I have such software and EVEN me can not read the firmware.
    >
    > I have ONLY a "project" in my IDE and it produce the firmware.


    Well, your IDE is software, it can read the input settings to generate
    the firmware. So its part of the tool chain to build the firmware.
    Whatever data the IDE edits as you change settings, thats the source for
    the firmware. (You may be combining other binary blobs when you compile
    the firmware, but thats the nature of this part of the industry, as I
    understand it).

    And yes, people can fry their *own hardware* if they mess up the
    firmware. So what - I started with monitors you could completely fry if
    you put the wrong X11 config settings into it, which is vastly easier to
    do than rebuilding a firmware.

    None of this changes the fundamental aspects though:
    - The output firmware is not the preferred form for modification (it is
    the output, not the alterable portion of the input).
    - The output firmware *may* need to be replaced if there is an issue
    found after the hardware ships. (Its not a write-once event to create
    firmware).

    This clearly means that we cannot ship it in main or contrib under the
    social contract.

    (I found http://en.wikipedia.org/wiki/Open_source_hardware and
    http://en.wikipedia.org/wiki/Semicon..._property_core
    useful reading, as I'm not personally coding down at this level).

    -Rob

    --
    GPG key available at: .

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

    iD8DBQBJCRP8hnv5qfvT644RAuwLAJsEDL421Tt9SdQUAIEhRe AgUCoYRQCfWuQj
    5GeMymrAiZOMsHIZhbLi0S4=
    =dRni
    -----END PGP SIGNATURE-----


  16. Re: Free OS versus free hw

    On Wed, 2008-10-29 at 15:15 +0100, Loc Minier wrote:
    > On Wed, Oct 29, 2008, Ben Finney wrote:
    > > Since the Social Contract promises Debian *won't* ship non-free
    > > things, that's not an option compatible with the promises made by the
    > > Debian project.

    >
    > I might not have said it clearly enough:
    > - I agree the current DFSG and social contract imply we need to provide
    > sources for these firmware if they are shipped in Debian


    Good .

    > - in turn, this implies that I'm suggesting we might need to reword
    > parts of them to reduce the perimeter of Debian to something
    > achievable which we still love and aim for


    I think that that would not be Debian anymore.

    -Rob
    --
    GPG key available at: .

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

    iD8DBQBJCRiOhnv5qfvT644RArTNAKCH9DvoOHBZ6E+TFSEBGV a5wpAfCwCePOGR
    zPPAfdn/qD0YrtWf4OiYs5o=
    =TspL
    -----END PGP SIGNATURE-----


  17. Re: [DRAFT] resolving DFSG violations

    Am Donnerstag, den 30.10.2008, 01:48 -0500 schrieb William Pit****:
    > On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote:
    > > But regardless, Debian has promised that Debian is only free software.

    >
    > Then why does Debian have non-free? Is that not part of Debian?


    "Thus, although non-free works are not a part of Debian, ..."
    Social contract, paragraph 5.


    > If non-free is meant to be an opt-in part of Debian, then put the
    > distributable firmware there and be done with it.


    You know, quite a big part of the discussion is about whether this is
    a) feasible at all
    b) feasible so short before a release

    Thomas




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

    On Wed,29.Oct.08, 22:11:27, Michelle Konzack wrote:

    > I am not realy sure, 50.000 customers would accept hardware which cost
    > 45 US$ instead of 40 US$ because there are 2-3 OSS frickler which want
    > access to the source because they want to fix something.
    >
    > Do you would give the FIXES back to the manufacturer?


    I thought that was the nice thing about GPL. If you want to distribute
    your changes the receiver has to get the source too

    > IF the hardware is working under Linux, BSD, MacOS, Windows and others,
    > are you realy willing to give the changes back even the other users are
    > using Windows?
    >
    > I know a hardware manufacturer which gaved the sourcecode away under GPL
    > and it is IN the Debian distribution, but its OSS frickler upstream has
    > never gaved the changes back to the manufacturer so others can benefit
    > from it...


    The manufacturer can get it with a copy of Debian if he wants to

    > Note: The OSS firmware IS NOT compatibel with Windows and does
    > not add any additional functionalyty except it is open!


    And why is this NOT important?

    Regards,
    Andrei
    --
    If you can't explain it simply, you don't understand it well enough.
    (Albert Einstein)

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

    iEYEARECAAYFAkkJYU0ACgkQqJyztHCFm9lX/gCcDU7O9tdzrW2Re32I5it3UJ8S
    ZXsAoJk7KNlnq67xf+E9Bdhkx7Vk4/Mm
    =AKoZ
    -----END PGP SIGNATURE-----


  19. Re: [DRAFT] resolving DFSG violations

    On Wed, Oct 29, 2008 at 10:42:56PM +0100, Michelle Konzack wrote:
    > Am 2008-10-29 00:39:40, schrieb Ben Hutchings:
    > > 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...

    >
    > Most PCI hardware has a very small bootloader which checks some signals
    > on the PCI bus... I have a book about it but no time to read in since
    > it is very complicated...


    PCI (Express) hardware has to be able to initialise at least the bus
    interface and PCI config space at power-on reset. That includes board-
    specific information like subsystem IDs.

    The network controllers I work with can initialise their config
    registers either from built-in ROM or from external EEPROM or flash,
    selected by strap pins. Production boards always initialise from flash;
    thankfully no-one expects to be able to remove flash from NICs as they
    need to provide PXE boot code to the host.

    Ben.

    --
    Ben Hutchings
    It is a miracle that curiosity survives formal education. - Albert Einstein

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

    iD8DBQFJCYrv79ZNCRIGYgcRAoGnAKC/TjqNDRI6IaeYWIJjheZmtHCq2ACdHP5V
    7ytcB+OHRRjKQM7s3VyPDQI=
    =fJWl
    -----END PGP SIGNATURE-----


  20. Re: [DRAFT] resolving DFSG violations

    On Wed, Oct 29, 2008 at 10:33:27PM +0100, Michelle Konzack wrote:
    > Am 2008-10-28 02:45:31, schrieb Thadeu Lima de Souza Cascardo:
    > > 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.

    >
    > Anw what do you do with sourcode, for which there is not even a compiler
    > availlable under Linux/BSD? And you HAV to buy a 8000 US$ development
    > suit from the chip manufacturer to build the firmware?


    If the source code is not "human-readable", but it is free/libre, I
    would study it in the case I consider the chance there is a bug.
    Perhaps, if it was of my interest, I would even study the possibility of
    reverse-engineering it, so it could be more "human-readable" and provide
    tools to "build" it.

    > I have such software and EVEN me can not read the firmware.
    >
    > I have ONLY a "project" in my IDE and it produce the firmware.
    >
    > And now you!


    I consider that a problem with the tool you use. It has a major defect
    ("by design"): it is not free/libre. So you cannot modify your IDE to
    give you any more "human-readable" format or something else.

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

    >
    > Do you have already tried to modify a binary blob or simply opened a (no
    > mather which) binary from /bin/ in a HEX editor and tried to modify it?


    In my /bin/ directory? If I had to really modify it, why would I use a
    hex-editor if I have source code in C?

    However, I have programmed a microcontroller using a text editor and
    hexadecimal numbers, even had to recode some constants present in code
    because I had to add a single instruction in the middle of it. Until I
    stopped being too lazy to code a simple assembler.

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

    >
    > The software/IDE use "projects" which are not in human readable form...
    > ...and if you have finisched, you klick the button "Output firmware"
    > and then you have the firmware blob.


    Again, this is a issue with your IDE. It could certainly be modified to
    output some more "human-readable" format that represents its internal
    representation of the "project"... if only it were free/libre.

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

    >
    > ???
    >
    > It seems you have never designed Hardware or realy coded software for it


    Does writing a microprocessor in Verilog count as designing hardware?

    > Thanks, Greetings and nice Day/Evening
    > Michelle Konzack


    Anyway, this is about the DFSG and the requirement of distributing
    source code. I would really like that the requirement for distributing
    the needed tools to build and modify this source code was in DFSG too.
    Unfortunately, they are not. Fortunately, many packages that
    Build-Depends on packages on non-free are in contrib. I hope that will
    be the case too for any "firmware".

    So, it doesn't matter if the preferred form of modification (by the way,
    do you open on your IDE your output "firmware" or your "project"?) is
    "human-readable" or not. It is, in anyway, required by DFSG. If it is
    the same as the "binary" distributed, the other DSFG requirementes still
    apply.

    Regards,
    Cascardo.

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

    iEYEARECAAYFAkkJmikACgkQyTpryRcqtS1EfQCghcw0Bm+JQj rsh8mMZW4lAZEV
    8iEAn3sC1jf754D/fy1qKiVJwVZwW7tW
    =LJK7
    -----END PGP SIGNATURE-----


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