Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Debian

Debian Removes Binary-only Firmware From Kernel 121

Posted by timothy from the and-they're-stickin'-to-it dept.
mbanck writes "The Debian Linux kernel maintainer has announced that he will remove firmware from GPL'd drivers which obviously lack source code in its preferred form (i.e. something more appropriate than a hexdump inside a char[]), in accordance with the release manager's decision. The alternatives are user-space loading of the firmware via hotplug's request_firmware() API or making the vendors aware of the issue. How do the other distributions handle this?"
This discussion has been archived. No new comments can be posted.

Debian Removes Binary-only Firmware From Kernel More

Debian Removes Binary-only Firmware From Kernel

Comments Filter:

  • how other distros handle it (Score:3, Insightful)

    by 7-Vodka ( 195504 ) on Wednesday April 21, 2004 @10:32AM (#8928668) Journal
    How do other distros handle it? What a retarded question.
    Obviously, other distributions just include them because they want their stuff to work and don't like pissing off their userbase.
    Ah, debian we love you for it though.

    • Re:how other distros handle it (Score:5, Insightful)

      by swillden ( 191260 ) * <shawn-ds@willden.org> on Wednesday April 21, 2004 @11:02AM (#8928976) Journal

      Ah, debian we love you for it though.

      Yes, we do.

      This is an example of a rare thing called "Integrity": sticking to your principles, even when it's inconvenient, or painful.

      Lots of people are going to call Debian foolish and narrow-minded, but it's the same foolish and narrow-minded sense of principle that started this whole Free Software movement, and it seems to me that with the burgeoning commercialization of Free Software, it's very important that we have some voices who maintain the "pure" vision. Not because the commercialization is bad, but because commerce is pragmatic and that pragmatism poses some risks to a movement whose foundation is idealism.

      Ultimately, making Free Software a truly viable option for computing requires a mix of both idealism and pragmatism, and we do, indeed, love Debian for providing an idealistic counterbalance.

      Oh, and it's a damned fine operating system, too :-)

    • It's about time a linux distro stop pandering to hardware providers and demand they start thinking open source. It's a ballsy move, lets see where this goes...
  • Although removing any possible licensing issues is a good thing, this will only hurt Debian. People simply expect their hardware to work, without having to jump through massive hoops. Requiring full source code only makes certain hardware harder to get working, and does not contribute to the adoption of Linux. Now that RedHat is mostly focusing on the enterprise market, there has to be another distro to take its place (Fedora is still in its infancy), and Debian will soon not become that distro.

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Wednesday April 21, 2004 @10:46AM (#8928830)
      Comment removed based on user account deletion
      • Sorry if I'm a tech newbie but...

        Doesn't this limit the programing languages that can be used to develop the code? I mean you can only include a finite number of compilers.

        Also some code is massive but becomes tiny once compiled, doesn't that make no sense to include the source? What if someone wrote this firmware in Visual Basic (exageration but whatever) Linux has to miss out on it for that reason? Unfortunate.

        Solution proposal from noob: Leave source online, don't include non-esential drivers with t
    • I would guess that people who simply expect their hardware to work and those using Debian are (mostly) different groups.
    • Debian doesn't want to be RedHat, and Debian users are far more likely to be in favour of this change than RedHat users. People don't switch to Debian because it's the easiest or most popular distro to use. They switch because they like the ideals (or maybe because apt-get is so damn terrific) of the Debian group. I suspect Debian users are more accustomed than other Linux users at having to put a little effort into getting some of their gear working.
    • are you smoking crack?

      what makes you think Fedora is in its "infancy"? it's the same thing that Red Hat 9 was (plus the improvements that would have made it Red Hat 10). what about Red Hat 10 would have been an infant distro?

    • Requiring full source code only makes certain hardware harder to get working, and does not contribute to the adoption of Linux.

      I spent over a day this week wrestling with a RAID controller to discover that the closed-source binary-only driver only works with an outdated version of RedHat.

      If they had released the source with a GPL-compatible licence it would have been incorporated into the kernel. Then I could've used any recent distribution and the controller would have Just Worked with no driver di

  • Obviously "best" is subjective. Sure source is better, but what if the device uses an architecture embeded processor that lacks a compiler or assember to build the binary or the tools aren't normally installed?

    I see this as a similar problem with Lex/Yacc based applications. GCC, for example, requires bison to compile it. GCC ships with both the source grammer files and the compiled grammer file. Yes, I call the .c file compiled because it is an output file. That way, GCC can be compiled without having

    • GCC, for example, requires bison to compile it. GCC ships with both the source grammer files and the compiled grammer file.

      Which is fine. There's nothing wrong with shipping the output file so long as the original source is shipped as well. Of course it's still not strictly GPL compatible if you can't freely obtain the entire toolchain required to build it (and have that provided on request) but such is life.

      Most people don't need to use the source, but if there's a bug you need to fix then that source

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

      • Re:What if that's the "best" way (Score:5, Insightful)

        by Marillion ( 33728 ) <ericbardes&gmail,com> on Wednesday April 21, 2004 @12:35PM (#8930225)
        I'm sorry, I wasn't as clear as I could have been. I agree, vendors should do all that.

        But, a point I was trying to make, what if the toolset required to generate isn't open? There could a dozen reasons for that from technical (the device's CPU is not supported by GCC) to political (tool used by vendor is closed - either by the vendor or by NDA).

        Now were back to the discusion of device proliferation and hardware compatability. This point is already begin discussed quite well with one noteable exception.

        What about vendors who lock their code into on-board EEROM chips? That class of vendor surely covers over 95% of them out there. Think about it CD-ROM drives, Video card 3D engines, Printers, Phones, Music Players. These all have on-board systems. But if the firmware is locked in the device for the most part, it's out of sight, out of mind. But, when you get right down to it, there's no difference between a hex-dump in a kernel file or code locked in on-board EEPROM.

        The "Great Moment" that launched Richard Stallman's crusade to liberate software was when his trying to get a printer manufacturer to give him the source code to a buggy printer so he could fix those bugs. They said no. Not long after that incident and watching computer makers "steal" X11 for their own versions of UNIX, the GPL was born.

        • Re: (Score:2, Interesting)

          by account_deleted ( 4530225 )
          Comment removed based on user account deletion
        • The letter of the GPL allows one to the use of a non GPL compiler/translator. If a vendor wrote their on compiler/translator, then the source is whatever the vendor uses to generate the binary. The module could load the firmware with a statement such as: "load_firm(board_id,port,parm1,...)". The compiler/translator could generate an inline routine to load the firmware and buffer with the firmware data. The module is compliant with the GPL as the source is written in The language of the compiler/tran
    • A binary file can be converted into an array of char in C and compiled again. It's not really in the spirit of the licence but it is providing the source. e.g.

  • tg3 Driver Affected (Score:5, Informative)

    by semaj ( 172655 ) on Wednesday April 21, 2004 @10:44AM (#8928805) Journal
    One of the drivers I use - the tg3 Gigabit Ethernet driver - is affected by this. The driver currently contains non-free firmware that is uploaded to the card in a couple of cases.

    An interesting thing about this driver is that it appears to work (to the extent that most people need) without the firmware. There has been some attempt on the linux-kernel mailing list to make the firmware part of the kernel optional. That way Debian can just turn that option off and presumably remove the associated firmware from their kernel. Anyone who needs the bug fixes/features provided by the firmware can use a non-Debian kernel.

    Not everyone's in favour of this idea though. There's more about it on the mailing list [google.com] if anyone's interested.
    • An interesting thing about this driver is that it appears to work (to the extent that most people need) without the firmware.

      Yeah, that has been discussed on debian-devel as well. Seems the chances are good that tg3 might get back in, with a patch disabling the firmware.

      Michael

    • Darn it all to heck!

      Just yesterday, I installed a server with 2 3Com gigabit NICs that use the tg3 driver. I hope this is more tested by the time I need to upgrade the kernel again.

      I guess it's time to set up a test server, or maybe start buying a gigabit NIC that uses a different driver.

  • Let me see if I've got this... (Score:5, Insightful)

    by Anonymous Coward on Wednesday April 21, 2004 @10:44AM (#8928808)
    Correct me if I'm wrong.

    There are currently some vendors whose hardware require firmware to be uploaded to them (for example, Broadcom NICs), and these vendors have esentially embedded the binary for the firmware into the kernel source.

    Since the firmware is most likely not GPL, and the kernel source is GPL, we've got a GPL violation on our hands.

    So the suggested fix is to have these vendors pull the firmware out into its own file, and rewrite that part of the kernel source to pull in the firmware dynamically.

    Doesn't really seem like that big of a deal, unless I'm missing something?

    • Re:Let me see if I've got this... (Score:5, Informative)

      by luferbu ( 703405 ) <luferbu@fluids[ ]al.com ['ign' in gap]> on Wednesday April 21, 2004 @10:54AM (#8928907)
      This has been already discused in the past, in fact, Richard Stallman published an article where he states that the Linux kernel is in violation with the GPL because of the firmware included without source code, see the article at here [linuxworld.com]

      • The Stallman article is interesting, at least the last five paragraphs. The rest of the article is a rant about saying "GNU/Linux" instead of "Linux" and how Bitkeeper is evil. At least we know it was definitely written by RMS.

        • I don't see violent or extravagant writing there. I see thoughtful analysis which ties together the issues of leaving out credit for GNU, choosing Bitkeeper over free software replacements, and ending up with a kernel which is itself non-free but is ironically commonly taken as the symbol of the free software movement. These issues are related because the thought that leads from dismissing software freedom will give rise to encouraging people to make choices based on technical efficiency instead of softwa

    • Re:Let me see if I've got this... (Score:4, Insightful)

      by Cecil ( 37810 ) on Wednesday April 21, 2004 @11:08AM (#8929053) Homepage
      Since the firmware is most likely not GPL, and the kernel source is GPL, we've got a GPL violation on our hands.

      Correction is on its way:

      The GPL offers no restrictions on what code you can put into the GPL'd project. If you were putting the kernel into a non-GPL product, then that's definitely a GPL violation, but not the other way around. So, if you are allowed to put the firmware binary code into the kernel, through fair-use, a license, whatever, then it's fine to do that. If you're not licensed to do it somehow you're (to use the popular vernacular) stealing. This is probably where the dynamic-pulling of the firmware comes in. If you own the device in question, and pull the firmware right out of it, there's no question that's your right as owner of the device.

      The problem here is that using binary garbage is against the spirit of the GPL. I could make a GPL'd version of a short C program that reads in a bunch of opcodes from a large array and executes them, resulting in a full-featured (browser/word processor/database/widget/whatever). Is this program open-source? Not really, but technically since it is under the GPL, Debian would allow it. They're now changing that position, and saying that this does not in fact count as open-source software, and they do not want it in their distribution.

      Doesn't really seem like that big of a deal, unless I'm missing something?

      Freedom never really seems like a big deal. I constantly hear people berating RMS, but contrary to popular belief, there is a purpose behind the things he does and says. Same with the Debian project. I agree it is probably going to be frustrating and stupid in the short term. But most of these strange, philosophical sort of decisions are all about long term goals and this one is no exception.

      • Re:Let me see if I've got this... (Score:5, Insightful)

        by Make ( 95577 ) <max.kellermann@g[ ]l.com ['mai' in gap]> on Wednesday April 21, 2004 @11:44AM (#8929524) Homepage
        Your point is wrong.

        You are allowed to put non-free firmware into the kernel and use it for yourself. But you are _not_ allowed to distribute this kernel, unless you license the firmware under GPL. Read the GPL carefully. Derived work has to be licensed under the same conditions as the original work - which is GPLv2 for the Linux kernel code.

        Which way you insert code - either GPL code into non-free code or the other way round - simply makes no difference.

      • Comment removed (Score:4, Informative)

        by account_deleted ( 4530225 ) on Wednesday April 21, 2004 @11:49AM (#8929599)
        Comment removed based on user account deletion
      • The problem here is that using binary garbage is against the spirit of the GPL.

        Not only the spirit, the GPL is pretty clear:

        From section 3:

        "The source code for a work means the preferred form of the work for making modifications to it."

        Go on and modify those hexdumps.

      • That is absolutely wrong. WRONG! (Score:1, Insightful)

        by Anonymous Coward
        If you can't distribute the entire collective work under the GPL, you can't distribute the GPLed portions. The only exceptions are for "mere aggregation" or "fair use" as you stated. Those are not the case for large binary chunks embedded into a GPLed driver. Distributing it is a copyright violation (a GPL violation isn't a real thing, it's always a copyright violation). Please don't spread misinformation on this issue!

  • Hmm.. (Score:1, Troll)

    by noselasd ( 594905 )
    This is usually firmware for a device connected to the pc..
    Do we really need the sourcecode for it ? .. Why ?
    And where does this stop ? Should we not install linux
    on computers with a non open source BIOS ?
    What about devices with firmware already loaded and where it need not
    be loaded by a driver from an OS, should we "ban" those as well ?

    • Re:Hmm.. (Score:5, Interesting)

      by Slowping ( 63788 ) on Wednesday April 21, 2004 @11:08AM (#8929060) Homepage Journal
      I agree that this is going a little far.

      The firmware code doesn't get executed by the CPU, and thus in a sense it doesn't get executed by Linux. Firmware is used by an off-board processor, and thus I don't see a GPL violation here.

      Consider if a piece of hardware needed a Magic Number string to start up. No code, no logic, no meaning; just a magic number required to activate the device. Can't we consider the firmware code as just a magic number? After all, Linux doesn't interpret or execute it.
      • It may not be a GPL violation but it is a clear violation of the Debian social contract, which is why the firmware is being removed.
      • Correct. The firmware might not even be software. It might be data that cannot be adequately represented by source code, even the manufacturer wanted to. Or it might be source that is useless without a specialized proprietary build tool.

        In other words, that binary data could very well be the PREFERRED form of the firmware for everyone but the manufacturer, regardless of one's religious adherence to the GPL.

        • Re:Hmm.. (Score:4, Insightful)

          by mbanck ( 230137 ) on Wednesday April 21, 2004 @04:27PM (#8933024)
          In other words, that binary data could very well be the PREFERRED form of the firmware for everyone but the manufacturer, regardless of one's religious adherence to the GPL.

          If the firmware really is the preferred form of modification and is (along with the rest of driver) GPL'd, everything is fine. Of course, this is a bit hard to check, but talking to the vendor might help here.

          But keep in mind that we are talking about the preferred form of modification here, from the POV of the vendor.

          Michael

      • Here is a little thought experiment to go along with the parent post. Suppose I make DeluxoWrite, the best Word Fragmenting program ever imagined. I want to make a logo commensurate to the sheer awesomeness of my word fragmenter. So, I go into GIMP, and I make a deluxo logo. The preferred form for editing is my multilayered GIMP file, and the custom perl script I made to make things perfect.

        So, I decide to use my logo, and I save it as a PPM, and I include it in the source to my program. Is it a GPL v

    • Re:Hmm.. (Score:3, Insightful)

      by Tonetheman ( 173530 )
      I second that... hell we should not run linux on any computer where we cannot have an open source bios.

      Debian has to be the biggest bunch of holier than thou morons... why would you intentionally make it hard on the user of your software to get something done?

      And I am not even trying to troll on this. It is a valid question. There is no good reason to do this other than a few zealots who are SO out of touch with the rest of the world.

      If I was using Debian in a commercial setting that required the use

      • Re:Hmm.. (Score:2, Insightful)

        by Ibix ( 600618 )

        If I was using Debian in a commercial setting that required the use of one of the "bad" drivers... what would my choices be? Stop my business until the "evil" drivers magically become open source? No I tell you what I would do... I would switch distros or even worse jump to Windows where the damn things are supported and probably already work.

        Very good point. Now what would you do if some asshole of a kernel developer decides that the drivers amount to a violation of the GPL on his code? The developer

      • Legal acts (Score:4, Interesting)

        by nuggz ( 69912 ) on Wednesday April 21, 2004 @12:25PM (#8930071) Homepage
        The GPL does not permit this bundling. It is clearly linked, and it is not the source code.
        To distribute it like this is a violation of the GPL.
        Your choices in your situation would be to add the driver yourself. The supplier could likely write a trivial patch to install it into your kernel source. You could then freely use it.

        You're complaining about debian holding you hostage when it is actually the supplier of the closed module who is causing the problem. They could always release a GPL compatible driver.

        • Re:Legal acts (Score:3, Interesting)

          by nathanh ( 1214 )

          The GPL does not permit this bundling. It is clearly linked, and it is not the source code. To distribute it like this is a violation of the GPL.

          Just to play devil's advocate, the GPL doesn't care too much about linked, but more about derived works. RMS has argued in the past that linking is a sure sign of a derivative, but the recent LKML arguments over the nvidia driver prove that other people disagree with that interpretation. You do not even need linking to create a derived work; I have seen argum

          • When the code with a different license is distributed within an otherwise GPL source file I think it is clear that the resultant GPL+non GPL single file of code is a derived work.

      • Debian has to be the biggest bunch of holier than thou morons...

        This comment makes no sense. Debian is a community-developed project, and the community who develops it has the opinion that this is the right thing for them to do with their project. In no way are they holding a gun to your head, proselytizing at your doorstep, etc. Want to change how they do things? Join the developer community and start making your voice heard. Don't care enough, or just plain don't like Debian? Don't use it! But

        • Debian is a community-developed project

          No it's not. It is an oligarchy of those who have commit bits to the debian source tree. Just like every other project out there. Users don't get to decide stuff like this. Heck, this VERY ISSUE was decided by a single Debian developer!

          • > Debian is a community-developed project

            No it's not. It is an oligarchy of those who have commit bits to the debian source tree.

            Which, according to the dictionary, is a community. Please try again.

            • Under that definition, Communist China is community-run. Want to be less pedantic?
            • Please quote from your dictionary. It sounds like it might be an amusing diversion.
              • About 1000 people are part of the Debian project. Admission is based on skills and adherence to the Debian social contract alone, not based on personal preference. If you don't call that a community, I can't help you. I certainly do.

                Michael


              • Please quote from your dictionary. It sounds like it might be an amusing diversion.

                OK. From the American Heritage Dictionary, Fourth Edition:
                -----
                community

                1.
                a. A group of people living in the same locality and under the same government.
                b. The district or locality in which such a group lives.

                2.
                a. A group of people having common interests: the scientific community; the international business community.
                b. A group viewed as forming a distinct segment of society: the gay community; the communit

                • The original postulation was, "Debian is a community-developed project." The Debian community is not developing Debian, instead a self-selected subset of the Debian community is doing it. While this subset is indeed a community unto themselves, it is NOT the same as the Debian community.

                  If you go out into the world (or merely the Debian development lists) and ask "who is the Debian community", you will not be told it's only a thousand or so specific individuals. Instead you're going to be told about tens o

      • If I was using Debian in a commercial setting that required the use of one of the "bad" drivers... what would my choices be?

        Add a non-free apt repository?

        This is about main. There's plenty of non-free software in contrib and non-free. They're just pulling this non-free software out of main as main only contains 100% Free software. Most likely there will be a few encumbered kernels in the non-free repositories at some point, or loadable modules for hotplug.

        Additionally, you could place presure on the har

    • Should we not install linux on computers with a non open source BIOS ? What about devices with firmware already loaded and where it need not be loaded by a driver from an OS, should we "ban" those as well ?

      The GPL is about code distribution, not everything that gets executed. If a Debian .iso came with a hex dump of a custom BIOS, then Yes, it should be removed for GPL-compatibility reasons. Really, it's not that hard to grok: if you distribute the code in a GPL'd product, you need to make the source ava


    • This is usually firmware for a device connected to the pc..
      Do we really need the sourcecode for it ? .. Why ?

      Because Debian can't distribute the binary code and yet still be following the Debian Free Software Guidelines.

      And where does this stop ? Should we not install linux
      on computers with a non open source BIOS ?

      Is Debian distributing that non open source BIOS, in violation of the DFSG?

      What about devices with firmware already loaded and where it need not
      be loaded by a driver from an OS, s

  • Go Team Debian (Score:2, Insightful)

    by darksmurf ( 190761 )
    "The alternatives are ..."

    Nah, the alternative is to roll your own kernel. ;-)

    The firmware licensing issue has been debated and resolved by the kernel people already.

  • about time (Score:5, Insightful)

    by mcelrath ( 8027 ) on Wednesday April 21, 2004 @11:17AM (#8929169) Homepage
    It's about time someone stood up to this issue.

    This could be a very good thing for linux. It could encourage vendors to provide updated firmware that can be installed from userspace, without requiring a kernel patch. It could encourage vendors to provide firmware at all designed for linux. For some other vendors it will surely encourage them to release the source, which will only lead to a massive hack-fest and fast improvement in capabilities of the firmware, which the company can negotiate to include in their windoze product. It seems to me separating firmware is win/win for both vendors and users, even if it is rocky while the separation is taking place.

    -- Bob

    • Re:about time (Score:3, Insightful)

      by Brandybuck ( 704397 )
      It could encourage vendors to provide firmware at all designed for linux.

      Firmware is OS specific? The utility to load (or manipulate) the firmware might be, but I seriously doubt the firmeware itself is.

      • Re:about time (Score:3, Insightful)

        by mcelrath ( 8027 )
        Firmware is not (necessarily) OS specific, but installation utilities and distribution is. For example, with separated firmware, the vendor can provide an rpm/deb package that contains only the firmware, and would work with any kernel version. As things stand, the vendor has to submit a kernel patch, which may or may not get incorporated, and various incarnations of the kernel in the wild will or will not support their device properly, a nightmare for a vendor trying to provide linux support.

        It allows v

    • It could encourage vendors to provide updated firmware that can be installed from userspace, without requiring a kernel patch.

      I hope you mean from the root user - giving normal users the ability to update the firmware would scare the helloutame...

  • Firmware is not "linked" with the kernel driver. Why would it be a problem for the kernel driver to load it?

    Sorry, but I think this is a bad decision. Yes, it would be nice to have sources for more firmware available, but that doesn't strike me as a battle worth fighting right now and it doesn't strike me as something that the GPL requires. And Debian hardware support is iffy enough as it is relative to other distributions.
    • Comment removed based on user account deletion
      • If it's not linked with the kernel driver, then explain how it ends up in the kernel?

        The purpose of linking is to enable functions to call each other across compilation boundaries. The firmware cannot be called before linking and it cannot be called after linking. Hence, it didn't get linked. It simply is data that happens to be in a kernel module.

        There is nothing in the GPL about how it's ok to withhold source if a part of the program gets uploaded somewhere and run on a different box.

        The GPL does
  • I think Debian has done a good job handling issues like this in the past. For example, when using apt you have the CHOICE to include non-free software if you choose, and it is just as simple as including free software, if they are able to make it as easy to use as they have for the free/non-free choice this will essentially be a non-issue.

    It reminds me a bit of how Gentoo operates with Java, when you install it, emerge (apt for Gentoo) tells you to go and grab this file and put it here. That way you can e
    • I kid you not, the Debian Weekly News has several times included discussions about dropping "non-free" entirely.

      This is something I personally consider a bad idea, as a long time Debian user. As dcocos says, just make it available explicitly as non-free the same way the nvidia drivers are now.

      Bob-
      • In fact the Debian developers held a vote on this very topic (dropping non-free). The vote would have needed a two-thirds majority to pass.

        It didn't even garner a simple majority [debianplanet.org].

        Even if the vote passed you still would have been able to install non-free software on your debian machine, you just wouldn't be able to install it from debian or a debian mirror. Kind of like the blackdown java packages right now.

    • Keep in mind that those firmwares violate the GPL and not just the Debian Free Software Guidelines. Thus, they cannot even be distributed in non-free, unfortunately.

      Michael

  • what drivers will be affected by this?

    If it is a few hardware devices then it wont be a huge issue to debian users. But if suddently all wireless devices stop working ( probably overkill ) then what will be left? Replace wireless devices with your favorite hardware device that may stop working. I hope he puts out a list of all things that will stop working or will require users to do more in their configs.

  • Although the sentiment is good... (Score:3, Insightful)

    by getnuked ( 595037 ) on Wednesday April 21, 2004 @02:24PM (#8931756)
    ... this will only hurt debian in the long run.

    How does RMS expect us to compile a kernel for our architecture and for every architecture which we need embedded firmware for? We could end up being required to have dozens of different compilers (think ARM7, i960, MIPS...), not to mention libraries and other tools installed. Many of these are closed source, or are restricted from distributing the source. A good example is the DSP I am using at an optical controller company - the silicon vendor is the only source of the compiler which costs $4000 U.S., not to mention that many of the libraries we use are not available in source form.

    Trust me, the embedded market is a completely different picture than the desktop when it comes to development. Even if the firmware source was released it would do you no good.

  • thank debian for taking up the issue (Score:4, Interesting)

    by Splork ( 13498 ) on Wednesday April 21, 2004 @02:28PM (#8931808) Homepage
    while we may all be fine and happy with drivers that work using vendor supplied binary-only bits of firmware inside an otherwise open driver, those vendors are not guaranteed to continue supplying that firmware or keep it free forever (as if buying their hardware isn't enough!).

    keeping that out of the kernel and as something to be loaded by hotplug is the best that can be done for devices that the vendor won't (and often can't) provide full source for.

    the messier issue is where do you draw the line at what is allowed and what is not? is a sequence of 20-odd magic values written to proprietary chipset registers any different than 800 bytes stored in a string and sent to the device on startup? both are equally obfuscated but only one is likely "code" in any sense due to its size.

    less and less devices will bother to have any rom and firmware on them in the future as a flash rom takes space and costs money and is not needed when the OS can load it for you. tackle this now!
    • I don't understand your last point:

      > less and less devices will bother to have any rom
      > and firmware on them in the future as a flash rom
      > takes space and costs money and is not needed when
      > the OS can load it for you. tackle this now!

      ROM (not flash) is the cheapest kind of memory. RAM requires its own controller, and you can't boot from the device, obviously.
    • while we may all be fine and happy with drivers that work using vendor supplied binary-only bits of firmware inside an otherwise open driver, those vendors are not guaranteed to continue supplying that firmware or keep it free forever

      While I can understand the fuss about binary-only drivers, I think embedding firmware code should be allowed. It should be seen as data needed to initialize the device in a workable state. I think there's no difference between only a few bytes written to some registers, or a
  • I see the reasoning for this, but is it practical?

    What happens if the card has an embedded controller that uses an architecture that isn't easily compiled by gcc or something?

    What do you do then?

    Obviously is keep it precompiled.

    This, while good intentioned, I can see breaking a lot of things which aren't really purposefully breaking a lot of things without easy solutions.
  • ...I want to shake them until they stop. When you come down to it, mainly Debian exists for one purpose: to provide a solid, completely Free operating system. If the license on a piece of software can be interpreted as not giving freedom to the end user, then Debian cannot include that software without violating it's formal constitution.

    Q: "But why don't they include the accelerated NVidia driver?!? That would be useful!"
    A: Because it's not Free.

    Q: "But why don't they include qmail?!? That would be useful!"
    A: Because it's not Free.

    Q: "But why don't they include pine?!? That would be useful!"
    A: Because it's not Free.

    Despite that, every time Debian removes (or refuses to add) a piece of non-Free software, the "pragmists" queue up to swear that Debian is irrelevant because they don't care about market share, or that they're a bunch of extremists.

    Understand this: Debian has a very explicit social contract with their users. If you continue to be surprised by their strict adherence, then either 1)you need to accept that they will always side with Freedom over pragmatism, or 2)you have a seriously warped worldview that causes you to be mystified by integrity. Either way, find something else to gripe about.

    Debian is Free and increasingly popular among those of use who share that value. Every time they make a difficult decision like this, even at the expense of practicality, I respect them even more. Even if you hate Debian, you still benefit from their hard-line observation of their ideals every time you execute a bit of Free code that exists because they otherwise would have rejected it from their distributions.

    I just don't why some people are still surprised each and every time. A real news article would be "Debian includes Qmail in 'main'". Now that would be a reason to criticize them. This is not.

    • Understand this: Debian has a very explicit social contract with their users. If you continue to be surprised by their strict adherence, then either 1)you need to accept that they will always side with Freedom over pragmatism, or 2)you have a seriously warped worldview that causes you to be mystified by integrity. Either way, find something else to gripe about.

      The explicit social contract is the #1 reason why I stick with Debian. In the past, Debian had a number of unique features like apt and a sensi

  • News for nerds, stuff that matters

    Deciding just what is open source when it comes to the kernel gets stuck in developer section, but a rumor that Darth Vader may be setting some new fashion trends that's about 3 paragraphs long - stop the presses. :oP

  • Debian's done the right thing (Score:3, Interesting)

    by Anonymous Coward on Wednesday April 21, 2004 @10:35PM (#8935649)
    It's amazing how inconvenient it can be to stick to one's principles. In this case, we have binary globs being shipped in the kernel. The question isn't about whether you're allowed to use them as the end user. You are. The question isn't whether this is a GPL violation. It's not. [lkml.org]

    Normally we think of the kernel as being one package licensed under the GPL. Instead, if we take Torvalds' claim as gospel (and we can since it's estoppel [google.com]), the kernel is GPL'd but ships with non-GPL'd parts. This is no conflict; the firmware is not a derived work and need not be covered under the GPL. As long as Torvalds has the right to redistribute those binary blobs, under any license, then he can distribute them with his kernel.

    Debian, however, has a more difficult decision. The Debian Free Software Guidelines (DFSG [debian.org]) dictates that "The program must include source code..." and this clause applies as much to firmware as it does to the kernel core.

    It's easy to criticize Debian as being overly pedantic without due concern for their users, or to say that they aren't being pragmatic. Instead Debian alongside hardline Free software advocates such as Stallman himself are being very pragmatic; their efforts of refusing non-Free software promotes the continuing development of Free software. They are consistently working towards a world of Free software, and pragmatically, compromise is a step in the wrong directory.

    Maybe the code isn't shipped because we don't have compilers that will compile it. Obviously, the solution isn't to ship binary firmware with the kernel, the solution is to author a Free software compiler for this architecture! Or at least a GCC backend.

    The other reason for Debian to be extremely pedantic about legal issues which is commonly overlooked is their dependence on the goodwill of their ftpmasters. The ftpmasters are the group of ISPs donating storage and bandwidth to Debian. Debian offers these people a guarantee: debian-legal (and lawyers with parent company Software in the Public Interest (SPI [spi-inc.org]) are prepared to prove that the ftpmasters do indeed have the rights to redistribute all Debian software. Now, can you prove that with the kernel firmware? What license does it fall under, since it can't possibly be the GPL without source?
  • That Debian's decision even appears on anyone's radar is a testament to it's success in attracting a significant number of users who have chosen it in preference to many alternative distributions. People have to remember that proactive support of free software has always been the primary goal of Debian. The fact that reliance on software meeting relatively strict definitions of being free has also produced a distribution that many people have come to trust and rely on is appreciated, but popularity has neve
  • Given the names of products are copyright and those rights are not released can you even give the name of a product in a 100% free distro? E.g. if I cannot take a chunk of hardware specific uninterpreted/unexecuted data and include it in the distribution then how can I include a reference to a "Pentium TM" CPU?

    It certainly seems a reasonable (to me) limitation that I can't call my new CPU the "LinuxPentium" or "Pentium X". If however I got the name from a GPL product it is a restriction on the use of info

    • You need to learn about the various types of intellectual property recognized in law. Product names can be protected through trademarks, specific expressions of ideas can be protected through copyrights, and ideas themselves can only be protected through patents. Each type of intellectual property has its own set of laws and regulations which govern it. Issues involving the GPL fall under the category of copyrights.

      In your comment you use the word information, which by itself has no legal meaning. Assuming
      • Debian's position is that including software components in the kernel without making available their source code violates the GPL requirements of other components in the kernel.

        You miss my point. While pentium is a trademark, the graphic logo is copyrighted. Neither is free to modify and redistribute and thus a violation of 'free software'.

        Debian acknowleges this is a lesser problem than potential violation of the GLP. The question is what makes a blob of firmware a "software component" as you call i

        • It's hard to get what your point is when you consistently blur the real distinctions between the different types of intellectual property. You said "While pentium is a trademark, the graphic logo is copyrighted. Neither is free to modify and redistribute and thus a violation of 'free software' "

          For one thing, the word "Pentium" and the Intel graphic logo are both trademarks for Intel. No software license, especially the GPL, gives anyone the right to modify or use someone else's trademark. Also, there is

Slashdot Top Deals

Neutrinos have bad breadth.

Close