Re: [DRAFT] resolving DFSG violations - Debian

This is a discussion on Re: [DRAFT] resolving DFSG violations - Debian ; On Wed, Oct 29, 2008 at 10:58:12PM +0100, Michelle Konzack wrote: > 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 ...

+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 61 to 80 of 98

Thread: Re: [DRAFT] resolving DFSG violations

  1. Re: [DRAFT] resolving DFSG violations

    On Wed, Oct 29, 2008 at 10:58:12PM +0100, Michelle Konzack wrote:
    > 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 thetool
    > > 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.


    And what do you type in this software to produce this "project"? This
    "project" would be source code, anyway. Even if we did not have the
    tools to produce the same "firmware" from this.

    > 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 do you write C code in your IDE? What else does this IDE provide you
    to help you optimize your C code? If it's not C code, what is it? And it
    would be very hard to compare C-code with hand-written assembly.

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


    A good solution would be to improve the free/libre software available in
    Debian, since you seem to claim that SDCC is an option as a development
    tool to this said micro-controller. Is it a 8051?

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


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

    iEYEARECAAYFAkkJnAQACgkQyTpryRcqtS0FtQCfax7g78Q/UYLC8Fjyj5HUeSjy
    6O0An2rgO0FAWK/1Jnov6qTauiyE9uzM
    =ED9g
    -----END PGP SIGNATURE-----


  2. Re: [DRAFT] resolving DFSG violations

    On Wed, Oct 29, 2008 at 10:40:03PM +0100, Michelle Konzack wrote:
    > 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


    In which cases? Which of the firmwares? How can you be sure?

    Regards,
    Cascardo.

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

    iEYEARECAAYFAkkJmr0ACgkQyTpryRcqtS2uhQCeOBVXvmzPh4 sW8bpWtsRKZtiG
    UT4An0sDkTQcgOpOzvFm1yMApmMZ3uoZ
    =a2ve
    -----END PGP SIGNATURE-----


  3. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-29 22:52:52, schrieb Thomas Bushnell BSG:
    > > I am sure, my enterprise is not the only one wondering about such
    > > requirement to let users modify firmware of sensibel hardware which CAN
    > > destuct the whole computer since they have to leafe out some stuff to
    > > get it into the small memories...

    >
    > How is this a reason not to provide source code?


    Manufacturerers can be sued...

    You get the hell if you for example modify the firmware uf a GSM modem
    and you disturb the GSM communication...

    It is NOT the Software distributor, but the Hardware Manufacturer which
    run into touble. I must certify my Hardware to be used in GSM networks.

    The if you modify the Firmware of my "24V DC Modular ATX PSU" which is
    connectedt to 24V Batteries and a SolarCharger and now you change the
    Reference vomtage from 24V (Gel batteries) to 25,9V (Li-Poly batteries),

    You can burn your computer and after this, there is NO preuv, it was my
    Firmware or your modified one.

    So now as a Manufacturer I have the choice between

    1) Use a huge NV/FLASH/EEPROM Memory which make the Hardware maybe
    10-20 Euro more expensive and I will lost customers.

    2) Use huge external SRAM (makes the Hardware expensive too) to let
    users load there own non tested and non-optimised blob and become
    sued if something goes wrong.

    So, the Open-Source System does not realy work on Hardware...

    > I don't understand why this matters to you. Provide the source code;
    > Debian ships it, and nobody is hurt. If nobody ever makes use of it,
    > how has it harmed you?


    The sourcecode is the blob. I can reload it into my Develoment suit and
    edit it, but thats all. This SDKs use highly optimized builders/compilr
    and there is NO OpenSource solution for it. Increasing FLASH/SRAM only
    because someone maybe want to burn its hardware or damage others is
    braindamaged since they are NO waraties something will work correctly...

    The problem is, IF someone (e.g. Hobby frickler) do something wrong, I
    can be f...ed.

    I do not know HOW OpenMoko do this, but the certification for GSM
    software/firmware IS expensive and it IS required by law.

    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)

    iD8DBQFJCeIkC0FPBMSS+BIRAgm/AJ9r9IV3BquVT/s2yFWKdvaLK9XTiwCghF5J
    zeocFyeUAkuLuAxOS3YLy7U=
    =hkbF
    -----END PGP SIGNATURE-----


  4. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-30 17:49:40, schrieb Giacomo A. Catenazzi:
    > But most of the firmwares are outside wireless communication.


    Right, but they are some like the one from me.

    > How many manufacturers was sued because users burn the monitors
    > (it was very easy) or other hardwares (e.g. try with hdparam) ?


    Do you think, someone (manufacturers) is making it public?

    > How many non conforming GSM devices are sold? How many of such devices
    > are recalled by manufactures?


    You can not even sell GSM devices, if your software is not certified.
    The recalls are very very low... because they are tested

    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)

    iD8DBQFJCerDC0FPBMSS+BIRAu+HAKDXTMuFv0OB5lkOzrz9Kn znTF+uTgCgkqWy
    3KCiypbQO5yQcY6vpBujIu8=
    =sSj6
    -----END PGP SIGNATURE-----


  5. Re: [DRAFT] resolving DFSG violations

    Michelle Konzack wrote:
    > Am 2008-10-29 22:52:52, schrieb Thomas Bushnell BSG:
    >>> I am sure, my enterprise is not the only one wondering about such
    >>> requirement to let users modify firmware of sensibel hardware which CAN
    >>> destuct the whole computer since they have to leafe out some stuff to
    >>> get it into the small memories...

    >> How is this a reason not to provide source code?

    >
    > Manufacturerers can be sued...
    >
    > You get the hell if you for example modify the firmware uf a GSM modem
    > and you disturb the GSM communication...


    But most of the firmwares are outside wireless communication.

    How many manufacturers was sued because users burn the monitors
    (it was very easy) or other hardwares (e.g. try with hdparam) ?

    How many non conforming GSM devices are sold? How many of such devices
    are recalled by manufactures?

    ciao
    cate


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

  6. Re: [DRAFT] resolving DFSG violations

    I'll add my two cents.

    I have some experience with radios. The FCC requires all radios to be
    certified before they can be sold, and there is a requirement that you
    must not make a device that is easily modifiable to operate outside
    the limits put forth by the FCC. In this case, it would be illegal to
    release the firmware's source code since it would violate the FCC
    rules, violate and void the radio's certification (and this also
    applies to Wifi/Bluetooth devices).

    I do agree firmwares fall under the DFSG and the social contract, and
    they should be split out, but included on the CD/DVDs so I can at
    least enable full hardware support out of the box.
    Michael

    On Thu, Oct 30, 2008 at 1:11 PM, Michelle Konzack
    wrote:
    > Am 2008-10-30 17:49:40, schrieb Giacomo A. Catenazzi:
    >> But most of the firmwares are outside wireless communication.

    >
    > Right, but they are some like the one from me.
    >
    >> How many manufacturers was sued because users burn the monitors
    >> (it was very easy) or other hardwares (e.g. try with hdparam) ?

    >
    > Do you think, someone (manufacturers) is making it public?
    >
    >> How many non conforming GSM devices are sold? How many of such devices
    >> are recalled by manufactures?

    >
    > You can not even sell GSM devices, if your software is not certified.
    > The recalls are very very low... because they are tested
    >
    > 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)
    >



    --
    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 Thu, Oct 30, 2008 at 12:10:48AM +0100, Michelle Konzack wrote:
    > 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?


    Yes I would. Given that hardware modems were still available but at
    higher cost after software modems started taking over the market just
    shows that there are people who will pay for good hardware that can
    actually be supported by free software.

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


    So, maybe SDCC could be improved.

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


    Not as if that's big by today's standards.

    > Or by attaching an external NVRAM of 128 kByte like the Atmel AT29BV010A
    > and I think, you can check the price for yourself...
    >
    > Again: ARE you realy willing to pay at least
    > 10US$ or 8? more for the hardware?


    Absolutely. I know I may be a minority, but I do pay extra to buy high
    quality hardware rather than the cheapest crap I can find. On the other
    hand I am much happier with my stuff because it works better, lasts
    longer, and doesn't waste my time dealing with @#$#$ firmware files.

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


    Well if you require firmware to be provided by the OS to the hardware,
    then the firmware either includes sources and goes in free, or it doesn't
    and goes in non-free and some people will want to avoid buying it for
    that reason.

    --
    Len Sorensen


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

    Le jeudi 30 octobre 2008 16:03 -0400, Lennart Sorensen a crit :
    > > Again: ARE you realy willing to pay at least
    > > 10US$ or 8? more for the hardware?

    >
    > Absolutely. I know I may be a minority, but I do pay extra to buy high
    > quality hardware rather than the cheapest crap I can find. On the other
    > hand I am much happier with my stuff because it works better, lasts
    > longer, and doesn't waste my time dealing with @#$#$ firmware files.


    Your assertion that it is better to put firmware in a flash ROM rather
    than in the driver, including for software freedom, is utterly wrong.

    All software has bugs and firmware is no exception. And when time comes
    to update the firmware in a flash ROM, like in those crappy Smart Array
    controllers, what will you do? Not only will the update not be available
    with regular system upgrades, but you will have to install non-free
    software provided by the manufacturer to update the ROM, and execute it
    *on the host system*, with all the security implications.

    Distributing the non-free firmware with regular package updates in
    non-free ensures that you are able to update it for bug fixes with
    system upgrades, and this is a definite improvement for users. And it
    also ensures that the only thing that is done with this non-free
    firmware is to upload it to the dedicated chip, which is an improvement
    for both users and software freedom.

    But the most important thing is that it gives leverage to convince
    manufacturers to actually distribute the firmware with a free license.
    We may have to put some firmware images in non-free, but we now have
    also a lot of them in main with permission to modify them, and some of
    them are even distributed with the source.

    The net result is that manufacturers are actually starting to open up
    their hardware. If you want to avoid that and keep your hardware bugs,
    go ahead and buy this hardware with flash ROMs.

    Cheers,
    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

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

    iD8DBQBJDri2rSla4ddfhTMRAkWVAJ99UQ3rcxrCV2e+jDcLss KXebuzxACg6GYP
    BUh4BqRBWsKiMFEIcEL1lnA=
    =J9UE
    -----END PGP SIGNATURE-----


  9. Re: [DRAFT] resolving DFSG violations

    Michelle Konzack dijo [Thu, Oct 30, 2008 at 12:10:48AM +0100]:
    > 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?


    So probably the end result won't be shipping raw Debian in your
    product - As you are not willing to release the firmware, Debian
    cannot inlcude it. Yes, even if it is worthless without a $8000
    compiler. Who knows? If the device is interesting enough and becomes
    highly successful, somebody (i.e. the Debian project?) can decide to
    pay $8000 for the compiler license and be able to fix bugs or enhance
    your firmware?

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


    If sharing the source for the firmware is not an option to you, and
    raising the price so the device can be self-sufficient without the
    computer uploading a firmware to it, then... Well, your device won't
    be natively supported by Debian. And that's not necesarily a curse! Of
    course I'd like every device on Earth to be Debian-based, but
    sometimes reality does not agree with my wishes.

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


    Oh, here we have a problem. You are 100% free and want to use GPL3 -
    So you are required to distribute the sources, the preferred form of
    modification. If not even the input you give to the mighty $8000
    compiler qualifies as source, then maybe the schematics you have on
    the whiteboard do? You just cannot say "there is no source". That
    would imply the firmware is a result of your computer's creativity -
    and I'd seriously doubt it.

    --
    Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
    PGP key 1024D/8BB527AF 2001-10-23
    Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


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

  10. Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)

    Josselin Mouette writes:

    > Distributing the non-free firmware with regular package updates in
    > non-free [has a particular effect]
    >
    > But the most important thing is that it gives leverage to convince
    > manufacturers to actually distribute the firmware with a free
    > license.


    How does this follow? Surely if the firmware is already being
    distributed by the project, that's a *smaller* incentive to the vendor
    to change the license.

    The position “Your license isn't acceptable to us; please change the
    license so that we can begin distributing to our users” is surely
    stronger than “We're distributing your firmware and all our users can
    get it, but please change the license so that it's slightly easier to
    get”. In the latter case, the vendor stands to gain less from making
    the license free, so that's less leverage.

    Yet that seems at odds with what you're saying. What's missing?

    --
    \ “Always code as if the guy who ends up maintaining your code |
    `\ will be a violent psychopath who knows where you live.” —John |
    _o__) F. Woods |
    Ben Finney


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

  11. Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)

    Le mardi 04 novembre 2008 * 10:23 +1100, Ben Finney a écrit :
    > How does this follow? Surely if the firmware is already being
    > distributed by the project, that's a *smaller* incentive to the vendor
    > to change the license.
    >
    > The position “Your license isn't acceptable to us; please change the
    > license so that we can begin distributing to our users” is surely
    > stronger than “We're distributing your firmware and all our userscan
    > get it, but please change the license so that it's slightly easier to
    > get”. In the latter case, the vendor stands to gain less from making
    > the license free, so that's less leverage.


    Past experience shows that manufacturers aren’t really listening to
    arguments such as “we won’t distribute your drivers unless you do that”.
    See nVidia if you want a good example.

    On the contrary, by distributing firmware images in a way that makes
    them already technically modifiable and subject to reverse-engineering,
    it becomes clear that they have nothing to lose by distributing the
    sources, and much to win as it allows the community to help them in
    maintenance tasks.

    In other words, I think the carrot has better leverage on them than the
    stick. Of course it all depends on who we’re talking, as the stick will
    work just fine on an obscure Chinese manufacturer but not on a
    world-leading company that sells high-grade hardware at 10 times the
    price.

    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

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

    iD8DBQBJEEfVrSla4ddfhTMRAq5kAJ9bJhwUO9WOmh2mpy1rKG 7MBl5TrwCfaQu9
    A9CYmS5sTOb9SdJ4wzyh3tU=
    =Jt7Y
    -----END PGP SIGNATURE-----


  12. Re: Leverage in licensing discussions

    Josselin Mouette writes:

    > Le mardi 04 novembre 2008 * 10:23 +1100, Ben Finney a écrit :
    > > How does this follow? Surely if the firmware is already being
    > > distributed by the project, that's a *smaller* incentive to the
    > > vendor to change the license.

    >
    > Past experience shows that manufacturers aren’t really listening to
    > arguments such as “we won’t distribute your drivers unless you do
    > that”. See nVidia if you want a good example.


    My understanding was that nVidia *do* listen, and have engaged the
    discussion numerous times; they just openly disagree. That's fine,
    they're free to do that, and I'll continue to recommend against their
    hardware for that reason.

    > On the contrary, by distributing firmware images in a way that makes
    > them already technically modifiable and subject to
    > reverse-engineering, it becomes clear that they have nothing to lose
    > by distributing the sources, and much to win as it allows the
    > community to help them in maintenance tasks.


    I find this interesting; if so, it would appear to be a different
    tactic from what we find effective in host-CPU-targeted works. Do you
    have a reference for an occurrence of this tactic succeeding?

    > In other words, I think the carrot has better leverage on [some
    > vendors] than the stick.


    Doubtless that's true in some cases.

    --
    \ “I hope if dogs ever take over the world, and they chose a |
    `\ king, they don't just go by size, because I bet there are some |
    _o__) Chihuahuas with some good ideas.” —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

  13. Re: [DRAFT] resolving DFSG violations

    Am 2008-10-30 09:35:32, schrieb Thadeu Lima de Souza Cascardo:
    > A good solution would be to improve the free/libre software available in
    > Debian, since you seem to claim that SDCC is an option as a development
    > tool to this said micro-controller. Is it a 8051?


    Yes, several of my projects use the Dallas DS80C4xx and NXP ones, since
    they cost only 8-10 US$/pcs @1000.

    But mainly I am switching to 7TDMI but they are ways more expensive with
    15-30 US$/pcs @1000. The advantage is, even a small 32 MByte NAND Flash
    with 16-32 MByte SDRAM can hold a whole EmDebian installation...

    My GSM router (based on Atmel AT91SAM9G20) with four POTs, one S0 (ISDN)
    and 4-port Fast-Ethernet switch will have probably enough NAND Flash and
    SDRAM to run a full blown EmDebian installation with asterisk on it.

    Peoples already have aske me and requested more then 256 MByte of NAND.
    (a Micron 512 MByte NAND Flash cost 13.05 US$ for a singel piece)

    So, if I know, users like to pay more for hardware, IF they can do more
    with it as "only using" I am willing to build the Hardware to this needs

    But for me is the question:
    Are customers willing to pay sometimes 10-30% more for the hardware?

    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)

    iD8DBQFJC6IqC0FPBMSS+BIRAg+SAJ4xackvgevaWV7BwDd1Wi jKirjAWgCfVcv+
    rz1QGxEsGtgBYU0Gy7qA6nA=
    =3M+J
    -----END PGP SIGNATURE-----


  14. Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)

    Am 2008-11-04 14:02:14, schrieb Josselin Mouette:
    > In other words, I think the carrot has better leverage on them than the
    > stick. Of course it all depends on who we???re talking, as the stick will
    > work just fine on an obscure Chinese manufacturer but not on a
    > world-leading company that sells high-grade hardware at 10 times the
    > price.


    Thats not all...

    I have goten a Chinese Manufacturer who has already build a GSM Module
    supporting Voice, SMS, MMS, VideoTelephone, GPRS, EDGE UMTS and HSDPA.

    The problem is, that even if it is mass production since some time, I
    can not distribute the firmware as open source since it change the
    behavour of the hardware which then can distrurb the GSM network.

    Attaching a FLASH memory of several MByte to it, would the module make
    6 times more expensive... and no one would buy it anymore... And as I
    have already written, I do not know HOW OpenMoko will solv this problem,
    but FreeRunner/OpenMoko or PurpleMagic are not allowd to run in Europe
    with Open Source GSM-Firmware. And of course, PurpleMagic has never
    respond to my three E-Mails and one Letter. (they are in France)

    This was the last word of the TV Rheinland...

    The manufacturer MUST asure, that the, e.g., GSM/UMTS network will no be
    disturbed...

    IF, Debian distribute the OpenMoko Software within Debian, it could harm
    the Debian Projecc for legal reason...

    And they is some other hardware on which one can not install Debian, IF
    the installer has no access to the firmware to activate a device...

    And YES, my SmartPhone "Nokia 6120 classic" (ARM926-EJ, 312 MHz, 128 MB
    Flash, 64 MByte mobile SDRAM, 8 GByte micoSDHC) is now running EmDebian
    but it does not help, if the Firmware written by me, can not be
    distributed as Open Source, hence not in /main/ and the installer can
    not install anything since you must first upload the firmware to
    activate something...

    If the Debian CD/DVD/BlueRay do not include the /non-free/ directory or
    ship the stuff in /main/ or /contrib/ then there are many devices which
    can not be used with Debian, even it should work with it...

    Note: There are MANY Open-Source Extremists, which give a fsck on it
    and saying: "I would not buy such hardware" but this has NOTHING
    to do with the manufacturer but network security and law.

    Unfortunately I know several of them (a group) which code there
    own GSM firmware but the problem is, if they come in my near and
    switch from GPRS to UMTS I lost my GSM connection...

    Also there is a Website of a women, which has created a small
    hardware which can kick-off GSM devices... She has designed it,
    because she was very angry about peoples, using ther cell-phones
    to laud in public... Using her device can lead to juridical
    actions against the user... Disturbing of Public-Networks.

    So ANY hardware which MUST use tested certified hardware and
    software can not be used with Debian...

    Note 2: Since my Outdoor HandBag TablePC use as Main CPU an i.MX31 and
    as GSM Processor a PNX6712 the firmware will be not updatable
    from users... I give a fsck on users who say:

    "Then I will not buy your hardware!"

    because such users are assholes since the can not even Upgrade
    the Firmware of there Cell-Phone which is to 99% based on
    ARM926-EJ and could run EmDebian witout any problems.

    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)

    iD8DBQFJE31QC0FPBMSS+BIRAoHfAJ9DDOxvTzXtCknhYRJBlz IU2uqnuQCgpg/q
    Ed4D/kjXPMHk1EU3tBFMsIA=
    =wAyp
    -----END PGP SIGNATURE-----


  15. Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)

    At Fri, 7 Nov 2008 00:27:13 +0100,
    Michelle Konzack wrote:

    > And as I
    > have already written, I do not know HOW OpenMoko will solv this problem,
    > but FreeRunner/OpenMoko or PurpleMagic are not allowd to run in Europe
    > with Open Source GSM-Firmware. And of course, PurpleMagic has never
    > respond to my three E-Mails and one Letter. (they are in France)


    I spent 5 minutes reading the OpenMoko wiki and mailing lists, and it
    seems to me that they do not have open source firmware for the GSM
    modem. The reasons given (essentially the fragility of the GSM
    network) more or less agree with what you write. If this is what you
    meant to write, it was not successfully communicated to me.

    David



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

    Michelle Konzack writes:

    > Am 2008-11-03 12:59:53, schrieb Gunnar Wolf:
    > > So probably the end result won't be shipping raw Debian in your
    > > product - As you are not willing to release the firmware, Debian

    >
    > ??? -- I am willing to do this! It is EUROPEAN LAW which make
    > HARDWARE manufacturer responsable if someone MODIFY Firmware and disturb
    > public e.g. GSM networks...


    Any recipient can do this equally well without a license from the
    vendor allowing them to do it. If they have the firmware blob, and
    have the technical capacity to modify it, they can modify it and
    redistribute it +IBQ- either breaching copyright or not, depending on the
    copyright license.

    Are you saying that EU law makes the vendor liable *only* in the case
    where the copyright license to the firmware permits the recipient to
    modify and redistribute, but *does not* make the vendor liable if the
    license doesn't allow this?

    --
    +AFw- +IBw-To me, boxing is like a ballet, except there's no music, no |
    `+AFw- choreography, and the dancers hit each other.+IB0- +IBQ-Jack Handey |
    _o__) |
    Ben Finney


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

  17. Openmoko GSM/GPS firmwares (was Re: Leverage in licensing discussions)

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

    iJwEAQECAAYFAkkUVN4ACgkQZwOMsWhEDTOUOwQAjJxrkQV+H3 RDi4jcrdPMxdDS
    /wondguYzFN8ecXJc0Jo5FqeR5d9Wur6pr9MUspoZJiSW2x3lda p2IgIJc8ASO+T
    aiY5gE40uSB5Q55O202UODswEy5klKayl838uC3Hho07jX7gdP 7TDdr3e8UCwHAH
    ZMRM+GRbwrdBn8WiACw=
    =OZUQ
    -----END PGP SIGNATURE-----

  18. Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)

    Le vendredi 07 novembre 2008 00:27 +0100, Michelle Konzack a crit :
    > The problem is, that even if it is mass production since some time, I
    > can not distribute the firmware as open source since it change the
    > behavour of the hardware which then can distrurb the GSM network.


    This reasoning, as any security-by-obscurity one, is completely flawed.
    As long as the firmware is distributed separately, you can modify it,
    whether it is open source or not. Not having the source never prevented
    people from making modifications.

    This is precisely a reason why manufacturers should actually distribute
    the sources for such firmware files. Having the source available helps
    fixing bugs and in the end you can make a new, improved firmware that
    can be submitted, if necessary in your country, to the local authorities
    for being allowed for use on production hardware.

    When the firmware is not open source, the only things that you will see
    people do by modifying it will be breaking the limitations to work with
    frequencies they are not supposed to. When it is open source, you can
    still expect that, but you can also expect actual improvement in the
    firmware and the driver. Pick your choice.

    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

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

    iD8DBQBJFFgzrSla4ddfhTMRAmojAKD5wZ73SjrfgyC9o/pQM8hmApYuagCg+6ur
    0PfUIMFQBLeSUecCb+6i4YU=
    =Ak/s
    -----END PGP SIGNATURE-----


  19. Re: [DRAFT] resolving DFSG violations

    Le vendredi 07 novembre 2008 * 00:48 +0100, Michelle Konzack a écrit :
    > ??? -- I am willing to do this! It is EUROPEAN LAW which make
    > HARDWARE manufacturer responsable if someone MODIFY Firmware and disturb
    > public e.g. GSM networks...


    Bull****. You’ll have a hard time finding a court that will conclude
    that the manufacturer is liable instead of the person who has actually
    modified and distributed the firmware. Especially if the manufacturer
    disclaims clearly any responsibility for modifying it in the
    documentation.

    > Such sensibel stuff must be protected...


    It will NEVER be protected by ideas as stupid as just keeping the source
    closed.

    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

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

    iD8DBQBJFFjmrSla4ddfhTMRAvmNAKDADS8mmPwYAKAnlJY//kmO0Qs2/ACg+T8R
    OSqF6HP4qyli90k0aZIugIY=
    =zlnN
    -----END PGP SIGNATURE-----


  20. Re: Leverage in licensing discussions

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Josselin Mouette wrote:
    > Le vendredi 07 novembre 2008 * 00:27 +0100, Michelle Konzack a écrit :
    >> The problem is, that even if it is mass production since some time, I
    >> can not distribute the firmware as open source since it change the
    >> behavour of the hardware which then can distrurb the GSM network.

    >
    > This reasoning, as any security-by-obscurity one, is completely flawed.
    > As long as the firmware is distributed separately, you can modify it,
    > whether it is open source or not. Not having the source never prevented
    > people from making modifications.


    Even if it is no guarantee for prevention of modifications, it makes
    those much more difficult.

    > This is precisely a reason why manufacturers should actually distribute
    > the sources for such firmware files. Having the source available helps
    > fixing bugs and in the end you can make a new, improved firmware that
    > can be submitted, if necessary in your country, to the local authorities
    > for being allowed for use on production hardware.


    It is not a bug that certain _hardware_ has more capabilities than is
    reasonable to offer the user to tweak. Even if a physical radio
    transmitter (wifi, cell phone, radio,) is technically capable of
    transmitting/receiving at many frequencies, it is usually not desirable
    to have any average user actually _use_ it at any frequency they wish.

    I'm fully in favour of open source and people tweaking the code running
    on their computers, but I'd have to stop leaving the house, if people
    started to mess with the software controlling the breaks of their cars...

    > Le vendredi 07 novembre 2008 * 00:48 +0100, Michelle Konzack a écrit :
    >> ??? -- I am willing to do this! It is EUROPEAN LAW which make
    >> HARDWARE manufacturer responsable if someone MODIFY Firmware and disturb
    >> public e.g. GSM networks...

    >
    > Bull****. You’ll have a hard time finding a court that will conclude
    > that the manufacturer is liable instead of the person who has actually
    > modified and distributed the firmware. Especially if the manufacturer
    > disclaims clearly any responsibility for modifying it in the
    > documentation.


    You'll have a hard time to prove that it was some modified firmware...
    - that killed the person with the pace maker or

    - that caused the accident by differently controlling the car's
    electronics or

    - that causes the connection problems in your flat (via neighbours
    trying to increase the range of their wireless).

    >> Such sensibel stuff must be protected...

    >
    > It will NEVER be protected by ideas as stupid as just keeping the source
    > closed.


    Closed source might not indefinitely protect it. But open source in some
    cases might outright jeopardize it.

    Don't forget that there is good reason why even our beloved Debian
    employs 'security by obscurity' before the DSA is out and patched
    packages are available...

    Again that's not to say that closed source guarantees security. But maybe
    it helps in certain cases.

    Just my 2ct,

    Johannes

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkkUaaAACgkQC1NzPRl9qEUkgwCbBfUWcbzxsc Pzq/s0JDD49Jpe
    vqoAmwRammq95ThAyMfE7m/BbBxt74CG
    =8hr/
    -----END PGP SIGNATURE-----


    --
    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 4 of 5 FirstFirst ... 2 3 4 5 LastLast