Slashdot Mirror

← Back to Stories (view on slashdot.org)

Debian Removes Binary-only Firmware From Kernel

Posted by timothy on 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?"

90 of 121 comments (clear)

  1. how other distros handle it by 7-Vodka · · Score: 3, Insightful

    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.

    --

    Liberty.

    1. Re:how other distros handle it by swillden · · Score: 5, Insightful

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

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:how other distros handle it by Anonymous Coward · · Score: 4, Insightful

      That's a damn good principle to stick to when you are based in the most litigious nation on Earth.

      Just think 'non-US' and you'll realize that one of Debian's policies has always been to make sure not only that it works, but that it actually works legally. It only takes one C&D letter (or, if you don't fold to those, one court order/FBI visit) to fuck everything up and undo the countless man-hours that have gone into Debian.

      For that matter, they are also trying to protect their end-users. IP law is a sketchy thing and we all have heard the SCO-babble about end-users being responsible for the IP within the software they use. If you remove legal issues before the software reaches the end-user... Well it's just good for everyone.

    3. Re:how other distros handle it by swillden · · Score: 4, Interesting

      Except in this case the principle their sticking to is rabid legalism.

      What? Debian's goal is to be a complete, *Free* operating system, where the definition of "Free" is the one put forward by RMS and the FSF, namely: Free to use, free to examine, free to modify and free to share. These binary-only firmware components are not Free. You may have freedom to use and share them, but you can't examine or modify them. Debian wants to be a Free operating system not Mostly Free, or Very Nearly Free.

      What's "rabid" or "legalistic" about that?

      It's pragmatism taken to an extreme.

      That sentence parses just fine (no misspellings, even!) but it makes no sense. What are you trying to say? How can such an impractical decision be "pragmatism taken to an extreme"? What would that phrase mean anyway? Extremes, by definition, are not pragmatic!

      It has nothing to do with FSF style "save the users from themselves" ideology.

      Now you've switched to a different target, choosing to mischaracterize the FSF's position. FYI, the FSF has no intention of saving users from anyone, the FSF just wants to make it possible for people who want to to create, use, read, modify and distribute Free Software, with the assurance that the original author's wishes (that it be Free) will continue to be honored as long as the copyrights are in force. If anything, it's about saving developers from having their work misappropriated, not about saving users from anything.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:how other distros handle it by Dwonis · · Score: 4, Insightful
      Not wanting to get sued is pragmatic. But their efforts to absolutely guarantee this move beyond pragmatism to absurdity.

      Yes, absurdity. It's not like anyone is ever going to accuse Linux developers of copyright infringement...

  2. This only hurts Debian. by mind21_98 · · Score: 1, Informative

    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.

    --
    US businesses that currently accept chip and PIN/signature
    1. Re:This only hurts Debian. by squiggleslash · · Score: 4, Insightful
      People simply expect their hardware to work, without having to jump through massive hoops.
      That presumably can be solved by making the user-space firmware loading process as painless as possible, maybe part of a larger infrastructure dealing with module-based device driver loading and configuring.

      In some ways this is what Linux needs. Darwin's system, where kernel extensions are packaged up with XML files that describe capabilities, requirements, etc, strikes me as a good model to follow.

      As far as Debian's choice with the kernel as-is, I honestly don't think they have much of a choice. There are licensing issues with including binary-only code in the kernel, I see nowhere in the GPL that gives a get-out if that binary is supposed to be run on a different CPU. Right now the practice is tolerated, but it probably shouldn't be.

      --
      You are not alone. This is not normal. None of this is normal.
    2. Re:This only hurts Debian. by JRIsidore · · Score: 2, Insightful

      I would guess that people who simply expect their hardware to work and those using Debian are (mostly) different groups.

      --
      :w!q
    3. Re:This only hurts Debian. by Deliveranc3 · · Score: 1

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

    4. Re:This only hurts Debian. by squiggleslash · · Score: 3, Informative
      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.
      Not really, you ONLY have to include source. You're not forbidden from including a binary (or "compiled version") in addition to the source, and indeed GCC, which uses a Bison generated grammar file, is one example of this - it comes with both source and post-Bisoned file so that you don't have problems should you not already have Bison.

      Debian would be happy with firmware updaters as long as the source to the firmware is available and code to compile the firmware and update the module's binary with that firmware is available. The problem, at the moment, is that rarely is the firmware available.

      --
      You are not alone. This is not normal. None of this is normal.
    5. Re:This only hurts Debian. by hummassa · · Score: 2, Informative

      Yeah, we Debianers usually screen our hardware before shopping...

      --
      It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
    6. Re:This only hurts Debian. by BlackHawk-666 · · Score: 1

      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.

      --
      All those moments will be lost in time, like tears in rain.
    7. Re:This only hurts Debian. by tiptone · · Score: 1

      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?

      --
      Please don't read my sig.
    8. Re:This only hurts Debian. by Admiral+Burrito · · Score: 1
      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 disk version incompatibility messiness.

      In this case, not releasing the source made the hardware much harder to get working.

      This is not a problem specific to Linux. There are quite a few winmodems out there that people bought in the Win98 days that don't work with W2K/XP. The driver is not compatible and the vendor doesn't want to support chipsets they aren't even selling anymore.

      Just a little reminder that Free (as in speech) can have real practical benefits too. That's how the ideological aspect was spawned in the first place.

    9. Re:This only hurts Debian. by Tukla · · Score: 1

      Fat lot of good that does you if Debian drops support for your "screened" hardware after you buy it.

  3. What if that's the "best" way by Marillion · · Score: 1
    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 to have bison installed.

    --
    This is a boring sig
    1. Re:What if that's the "best" way by Bronster · · Score: 2, Informative

      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 needs to be available so you can fix it.

    2. Re:What if that's the "best" way by squiggleslash · · Score: 3, Insightful

      Your comparison would be valid if the firmware files also included the source to that firmware, just as GCC comes with the Bison file and the file generated by Bison.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:What if that's the "best" way by Marillion · · Score: 5, Insightful
      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.

      --
      This is a boring sig
    4. Re:What if that's the "best" way by squiggleslash · · Score: 2, Interesting
      Please bear in mind this is a legal and technical issue, not a moral one - though the GPL is trying to remove one of the, what free software advocates consider to be, immoral practices.

      The difference between shipping with your firmware in the device itself and putting it in the kernel is the same as the difference between putting your firmware in a file and having a user-space utility upload it and putting it in the kernel. The difference is a legal one - in both these cases, the "putting it in the kernel" means you're bound by the GPL, and you must release source to that firmware if you choose to redistribute the kernel. In both of these cases, not making the firmware "part of" the kernel means the code is unencumbered and you can go ahead and be as mean, from a free software advocacy point of view, as you want.

      I agree it would be nice to have the source code for everything I have software for. But there are only certain areas where the absense of source code causes an actual problem. If you link with a GPL'd program, then it's an issue, because you've chosen to modify and redistribute that program directly that way.

      --
      You are not alone. This is not normal. None of this is normal.
    5. Re:What if that's the "best" way by TotalRebel · · Score: 2, Insightful

      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/translator. The Compiler/translator is not under the GPL, but if all Macros to generate the output are static loaded into the compiler/translator then the source of the firmware does not have to be delivered, nor the I/O sequences, as it is embeded in the tool. If all scripts, Makefiles, source for the module, and libraries used by the module are delivered, the the module is under the GPL. This satisifies the letter of the GPL, but not the spirit. But as the actual source of the tool used to generate a GPL module is not required, the source that is delivered does not have to give a view of whats under the hood, only a Macro view of the program flow. Therefore the source delivered is not as useful for modification, but the output could be linked into the kernel and still have a GPL kernel. This loophole could allow a vendor to provide a GPL driver for linux and still keep the actual interface closed, if they provide the Macro source for their compiler/translator and the support files to build a binary/module for linking into the kernel.

    6. Re:What if that's the "best" way by BlackHawk-666 · · Score: 1

      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.

      --
      All those moments will be lost in time, like tears in rain.
  4. tg3 Driver Affected by semaj · · Score: 5, Informative

    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 if anyone's interested.

    --
    Meep meep
    1. Re:tg3 Driver Affected by mbanck · · Score: 1
      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

    2. Re:tg3 Driver Affected by dobedobedew · · Score: 1

      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.

  5. Let me see if I've got this... by Anonymous Coward · · Score: 5, Insightful

    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?

    1. Re:Let me see if I've got this... by luferbu · · Score: 5, Informative

      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

    2. Re:Let me see if I've got this... by Cecil · · Score: 3, Insightful

      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.

      --
      Random and weird software I've written.
    3. Re:Let me see if I've got this... by Make · · Score: 4, Insightful

      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.

    4. Re:Let me see if I've got this... by squiggleslash · · Score: 3, Informative
      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.
      Erm, probably not.

      If you redistribute a GPL'd program that you yourself do not hold the rights to, you must release full source code. You can't say "Well, I never had source code to this module that I added, therefore I'm not releasing the source for that", it has to be everything.

      The reason I say "you yourself do not hold the rights to" is that a copyright holder, obviously, is not bound by their own license. But you and I and even Linus these days are bound by the GPL wrt Linux, because the copyright on Linux is shared amongst a large number of parties.

      Now, everything thus hinges on the redistribution part. If an end user grabs a module with a binary portion, inserts it into their kernel, and limits their use of it to that, then that's fine.

      If I find all the copyright holders to Linux, buy the rights, and then release Squigglix under the GPL, with a binary portion, then that's fine too, because I'm not bound by the GPL.

      If someone tries to redistribute Squigglix under the GPL (ie they're not asking me first, they're just looking at the COPYING file and agreeing to the conditions), then they're violating the GPL, because they're not releasing full source.

      If someone tries to redistribute Squigglix with my permission (ie they've asked me first, or there's a thing tacked on to the COPYING file allowing the source to be withheld for code I passed on to them in binary form only), then they're not violating the license, because the modified license allows them to do so.

      If someone tries to redistribute Squigglix under the GPL (ie they're not asking me first, they're just looking at the COPYING file and agreeing to the conditions), but before they do they remove the binary-only portion, then they're respecting the GPL, because they're not releasing full source.

      The GPL is very clear about this: If you redistribute and are doing so only because the GPL allows you to, you must include source. If you don't include source, even if you never had it you are violating that license.

      Linus's COPYING file does include a get-out in that user-land software does not have to be GPL'd, which is why Debian's saying it's ok to have a firmware binary that's loaded by a user-land program. But the kernel itself really is GPL, and it has to be distributed under the normal conditions of the GPL. Anyone currently shipping those drivers that include substantial binary-only source-unavailable portions, such as those with binary-only firmware code, is violating the license if they're shipping it with the rest of Linux.

      --
      You are not alone. This is not normal. None of this is normal.
    5. Re:Let me see if I've got this... by nkuttler · · Score: 2, Insightful

      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.

    6. Re:Let me see if I've got this... by squiggleslash · · Score: 1
      Your explaination doesn't hold water because nobody is claiming the the binary firmware is released under the GPL. (Although this could be more clearly explained in the readme.)
      No, and I'm not either, and I fail to see how you can read that into my message. Linux, however, is covered by the GPL, and any code incorporated into Linux is likewise covered by the GPL once it becomes a part.

      And no, Firmware isn't merely "data". Firmware is executable code. It may run on a different CPU, but it most certainly is code, and Linux + Firmware is software, not software + data.

      --
      You are not alone. This is not normal. None of this is normal.
    7. Re:Let me see if I've got this... by squiggleslash · · Score: 1
      Sez you, but others say differently.
      And they're wrong
      There's no legal requirement that the Linux tarball be 100% GPL, only to the extent that dervation requires it.
      Read the GPL.
      --
      You are not alone. This is not normal. None of this is normal.
    8. Re:Let me see if I've got this... by Experiment+626 · · Score: 1

      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.

    9. Re:Let me see if I've got this... by Wateshay · · Score: 2, Interesting

      Exactly. It seems to me that you could make a good argument that the firmware is not being linked to the kernel, and therefore is not required to be under the GPL. All the module is doing (if I understand things correctly) is taking a binary firmware file and uploading it to the device. Doesn't seem to me to be any different than using a GPL'd FTP client to upload a non-GPL'd binary to a fileserver, and I'm pretty sure even RMS wouldn't say that was a violation of the GPL.

      --

      "If English was good enough for Jesus, it's good enough for everyone else."

  6. Go Team Debian by darksmurf · · Score: 2, Insightful

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

  7. Re:Hmm.. by Slowping · · Score: 4, Interesting

    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.

    --
    (\(\
    (^.^)
    (")")
    *beware the cute-bunny virus
  8. Re:Hmm.. by Tonetheman · · Score: 3, Insightful

    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 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.
    Debian is doing nothing but causing problems just because they can.

  9. about time by mcelrath · · Score: 4, Insightful
    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

    --
    1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
    1. Re:about time by Brandybuck · · Score: 2, Insightful

      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.

      --
      Don't blame me, I didn't vote for either of them!
    2. Re:about time by mcelrath · · Score: 2, Insightful
      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 vendors to be kernel and distribution-neutral in their firmware support.

      In my experience, firmwares are usually taken from the windows installation CD that comes with the product, and firmware updates simply don't happen for linux.

      -- Bob

      --
      1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
    3. Re:about time by mOdQuArK! · · Score: 1
      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...

  10. Re:Hmm.. by Prior+Restraint · · Score: 1

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

  11. Re:Hmm.. by Ibix · · Score: 2, Insightful

    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 could sue one or more of the distros, and might get a restraining order on distribution of his code. What would your business do then? Move to Windows? Or Debian?

    I am not remotely implying that kernel developers are assholes - but think how much damage a smart and hostile person (or company, I'm looking at you, MS) could do by this method if they could get a "sleeper" into the kernel dev team.

    Yours paranoidly,

    I

  12. Re:Hmm.. by cbcbcb · · Score: 1

    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.

  13. that decision strikes me as bad... by hak1du · · Score: 1, Informative

    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.

    1. Re:that decision strikes me as bad... by squiggleslash · · Score: 1
      If it's not linked with the kernel driver, then explain how it ends up in the kernel?

      If you're going to put code inside other code, regardless of whether it gets executed directly or whether it's uploaded to another device to execute it, the overall package is one great big heap of code, and you need source for all of it if you're going to redistribute it relying upon rights the GPL has given you. 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 way around it is equally simple. Linus has given people a "get out" for user-land binaries. So you put your firmware in that, not in the kernel.

      Debian are being pragmatic here. They don't want to violate the law, and they're raising an issue that should have been raised a long time ago.

      --
      You are not alone. This is not normal. None of this is normal.
    2. Re:that decision strikes me as bad... by hak1du · · Score: 1
      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 doesn't talk about "big heaps of code", the GPL talks about "linking".

      Debian are being pragmatic here. They don't want to violate the law, and they're raising an issue that should have been raised a long time ago.

      Just be a bit more precise, please: the GPL is not a law, it's a license agreement. Violating it doesn't "break a law", it is a contractual violation.

      In any case, my point remains: something is going badly wrong here for open source because this is not a good outcome for Debian or OSS. I don't know exactly where the problem is, but here are some possibilities:
      • If Debian does this but other distributions don't, it's an overreaction from Debian.
      • If Linus demands this of Debian, then Linus is making a bad decision IMO.
      • If Linus didn't demand this but other people interpret the GPL as it is that way, then Linus should change the license on the Linux kernel; if he can't (because he didn't have copyright assigned to him and/or didn't have an "or later" clause in the kernel GPL), he made a mistake.

      Whatever the cause of the problem, saying "oh my, oh dear, we have to remove these drivers from the kernel" is not solving it.
  14. Legal acts by nuggz · · Score: 3, Interesting

    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.

    1. Re:Legal acts by nathanh · · Score: 2, Interesting
      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 arguments that overly familiar use of IPC could be enough to constitute a derivative (eg, passing a data structure over IPC).

      So we really need a legal eagle to decide on whether the firmware is a derived work of Linux, if the driver is a derived work of Linux, and if the bundle of Linux + driver + firmware is a derived work of Linux. Only then would we have a clearer understanding of whether this is a GPL violation.

      However as another astute person pointed out in an earlier comment, a possible GPL violation doesn't change what Debian has done. Debian has additional requirements; they have the DFSG and the social contract to adhere to. I think Debian was right in declaring these firmware bundles a violation of that social contract, even if their GPL status is unclear.

  15. Short Term Pain by dcocos · · Score: 1

    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 easily install, yet they stay true to their principles.

    1. Re:Short Term Pain by mbanck · · Score: 1
      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

  16. Re:Hmm.. by Bootsy+Collins · · Score: 1

    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 to say that they're "holier than thou" for deciding amongst themselves what to do with their project is like my calling you holier than thou for any principled stand you may take on any subject at all. It's just a personal choice, and you're allowed to make such choices about your life -- as are the Debian developers about their project.

  17. PLEASE MOD PARENT ALL THE WAY UP!!! by hummassa · · Score: 1

    this is the best summary of the question I have read... pls squiggleslash, post it to debian-legal!

    --
    It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
  18. Re:Hmm.. by Bootsy+Collins · · Score: 1

    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, should we "ban" those as well ?

    How is Debian distributing non-DSFG-compliant code in that case?

    Care to bring up any more red herrings?

  19. Debian developers discussing dropping non-free by Bob_Robertson · · Score: 1

    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-

    --
    The Ludwig von Mises Institute. The reasoning individuals economics
    1. Re:Debian developers discussing dropping non-free by tordia · · Score: 2, Informative
      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.

      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.

      --

      Frogs are primitive animals - so the occasional extra toe is not that unusual. But this is very unusual.

  20. more importantly is.. by josepha48 · · Score: 1
    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.

    --

    Only 'flamers' flame!
    Does slashdot hate my posts?

  21. Re:Hmm.. by Brandybuck · · Score: 1

    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.

    --
    Don't blame me, I didn't vote for either of them!
  22. Although the sentiment is good... by getnuked · · Score: 3, Insightful
    ... 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.

    1. Re:Although the sentiment is good... by tepples · · Score: 1

      "Hex strings inside a driver" are not the preferred form for modifying the firmware and are thus not "source code" under the GNU GPL. To solve this GPL incompatibility, have a userspace program (which is not considered linked to the kernel) upload the firmware to the device.

  23. thank debian for taking up the issue by Splork · · Score: 3, Interesting

    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!

    1. Re:thank debian for taking up the issue by HuguesT · · Score: 1

      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.

    2. Re:thank debian for taking up the issue by ByteSlicer · · Score: 2, Insightful

      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 whole firmware download. Including that firmware in the GPL code will allow others to use it in their modified drivers. The manufacturer could have put the firmware in an onboard ROM, but chose not to, so the firmware could be easily upgraded in case of bugs. Once the firmware code is stable, it will probably not change anymore anyway.

    3. Re:thank debian for taking up the issue by Splork · · Score: 1

      putting a rom of any sort on a device costs more than not having it at all. the device likely already has some ram for its microcontroller regardless, or it can use dma (depends on the nature of the device).

    4. Re:thank debian for taking up the issue by HuguesT · · Score: 1

      Then there needs to be some mechanism to transfer data from the PC bus to the RAM on the card, this doesn't come free from my experience (admitedly not up-to-date). Microcontroller usually have ROM too anyway.

  24. Non-archicture microcontrollers? by Silvers · · Score: 1

    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.

    1. Re:Non-archicture microcontrollers? by statusbar · · Score: 1

      Not only that, what if it isn't even firmware? Like an FPGA xilinx data file?

      --jeff++

      --
      ipv6 is my vpn
  25. Every time I hear someone whining about Debian... by Just+Some+Guy · · Score: 5, Insightful
    ...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.

    --
    Dewey, what part of this looks like authorities should be involved?
  26. That is absolutely wrong. WRONG! by Anonymous Coward · · Score: 1, Insightful

    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!

  27. This doesn't get front page by PetoskeyGuy · · Score: 2, Insightful

    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

  28. Re:Hmm.. by black+mariah · · Score: 1

    Under that definition, Communist China is community-run. Want to be less pedantic?

    --
    'Standards' in computing only impress those who are impressed by things like 'standards'.
  29. Re:Hmm.. by Brandybuck · · Score: 1

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

    --
    Don't blame me, I didn't vote for either of them!
  30. Re:Hmm.. by mbanck · · Score: 3, Insightful
    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

  31. Re:Hmm.. by mbanck · · Score: 1
    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

  32. Re:Hmm.. by Bootsy+Collins · · Score: 1

    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 community of color.

    3.
    a. Similarity or identity: a community of interests.
    b. Sharing, participation, and fellowship.

    4. Society as a whole; the public.

    5. Ecology.
    a. A group of plants and animals living and interacting with one another in a specific region under relatively similar environmental conditions.
    b. The region occupied by a group of interacting organisms.

    -----

    So I remain a bit puzzled by your comment. Given the number of Debian developers, and given that the principal barriers to entry are simply having some capability in something to do with the project, and wanting to contribute to it, I don't know how one wouldn't call it a community.

    HTH. HAND.

  33. Re:Every time I hear someone whining about Debian. by nathanh · · Score: 2, Insightful
    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 sensible filesystem layout. But other distros have caught up and Debian no longer has a lead in those areas. But Debian is still the "most free" of the Linux distributions. I can rest assured that everything in main has been argued to death over its actual freeness. This might not mean much to some people but it means a lot to me.

    If Debian ever reneged on its social contract and started compromising "free" for "convenient" then I'd have lost my last good reason to stick with Debian. I'd probably switch to Fedore Core because at least that's more like the systems I install for customers (typically RHEL). So I'm grateful that Debian has stuck to its charter on this one. We need at least one distro that gives freedom the highest priority.

    To be fair, RedHat seems to be as pedantic as Debian with regards to licensing. Look at the MP3 situation on RedHat. So perhaps RedHat can give Debian a serious run for the trophy in the "most free" category.

  34. Re:Bigger issue that you realize by m1a1 · · Score: 1

    Bullshit. He can shame you all he wants. I hate it when assholes like you cry about your fucking freedom. Nobody is imposing their will on you. Debian only taking software that the Debian team wants IS freedom. Freedom of choice. Just like you have the freedom to write whatever software you choose and license it under any legal license your bitchy, whiny little heart desires.

    Criticism does not curtail your freedom.

  35. Re:Hmm.. by Brandybuck · · Score: 1

    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 of thousands of users instead. Likewise, if you ask "who is the community of Midville", you will NOT be told "the city council of Midville".

    By saying Debian is community-developed, you are trying to impart to Debian a quality that does not exist. This is not a bad thing, and should not be inferred as such.

    --
    Don't blame me, I didn't vote for either of them!
  36. Linked and Derived work by nuggz · · Score: 1

    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.

  37. Re:Hmm.. by RdsArts · · Score: 1
    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 hardware vendor to respect the law and release their firmware under a GPL-compatable license which would allow for it's inclusion in the main kernels.
  38. Debian's done the right thing by Anonymous Coward · · Score: 3, Interesting

    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.

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

  39. Re:Hmm.. by forkazoo · · Score: 1

    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 violation if I don't include the GIMP multilayered file? The image is certainly part of the "source" that goes into building the final executable. The PPM embedded in a header file is certainly not the preferred editing format. How does this work?

    I'm not saying I outright disagree with the Debian decision. I'm just... mulling it over.

  40. Allow Debian to prove free softwares worth by Bystander · · Score: 2, Insightful

    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 never been the main impetus for Debian's developers. Some people seem to view Debian's current stance on binary-only firmware to be disrespectful of its users, who may be temporarily inconvenienced by lack of kernel drivers for some hardware. But people should respect the Debian developers and their wishes to produce the best system they possibly can using only truly free software. Debian cannot and should not be bound to placate people who want the quality and stability of Debian software, but who do not honor the primary reason for Debian's very existence.

    There are plenty of other distributions to choose from for users who find Debian's actions unacceptable. People who insist on pragmatism over principles should probably choose one of those alternatives. Debian should be left alone to pursue their software ideal, especially since they are one of the few to place such a high value on software freedom. Rather than chide them for not following the pack and refusing to compromise their principles, they should be encouraged in their efforts demonstrate what can be accomplished using clearly free software.

  41. To be that exacting... by emtechs · · Score: 1
    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 information in the distribution.

    If it is OK to restrict information...
    Is a chunk of hardware specific firmware information or code?
    Do we even know that it is the code and not the graphic logo to display at boot time for example?
    Do we need to?

    1. Re:To be that exacting... by Bystander · · Score: 2, Informative

      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 you intended to ask about the expression of a program through its code, or an artistic expression of a corporate logo, then the answer is that the redistribution of such expressions can be restricted through copyrights. The owner of the copyright gets to decide conditions under which their work may be distributed to others. If anyone fails to honor those conditions, they have no legal right to continue distributing the copyrighted material. The GPL establishes a simple set of conditions under which software covered by a GPL license may be distributed, and everyone has the option of either abiding by those conditions or not incorporating software covered by the GPL in their products.

      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. Given this interpretation, their only available options are to stop distributing the GPL parts of the kernel, or stop distributing the non-GPL-compliant components. Not surprisingly, Debian has decided to strictly adhere to GPL requirements with regards to the kernel it distributes.

    2. Re:To be that exacting... by emtechs · · Score: 1
      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 it when it is not executed by the "Program" as defined in the GPL while say a graphic is not. (And before you say the graphic is in source form I would venture it was not created in a bitmap editing program and there is a different source format.)

      Given the GPL states:

      However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
      There is a clear notation of the OS on which the program runs. It would be hard to claim the firmware is run on the Debian system.
    3. Re:To be that exacting... by Bystander · · Score: 2, Informative

      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 no restriction on redistribution of a trademark, so long as it is made clear who owns the trademark and there is no confusion elicited in viewers about what it is representing. Your example plainly does not show an example of a violation of the GPL.

      Second, there is no single definition of the term "free software" as you use it. There are only specific licenses, each of which has its own conditions, which fall under the wide umbrella of free and/or open source software. Before you can discuss a violation, you have to specify exactly which license you believe is being violated.

      Third, you ignore the plain difference between a binary file representing executable code (even if it runs only on an embedded processor within a device) and a binary file representing a static image. The binary executable represents a program, which during the course of its execution may effect the state of the computer system within which it runs. It will likely effect the state of the kernel which contains the driver which accesses the firmware. Without the natural expression of this firmware, its source code, it is difficult to really understand what those effects will be under all conditions. The static image file would have no indeterminate effects on the system. Contrary to your unsupported assertion otherwise, since the graphic image is fully described by the binary contents of the file, that file can be considered a definitive source format.

  42. Balls by Stevyn · · Score: 1

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

  43. Overstating the message, reach false conclusion. by jbn-o · · Score: 1

    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 software freedom, thus resulting in becoming dependant upon software that is not completely free.

    Nowhere in the article do I see Bitkeeper described as "evil" and nowhere in your summary do I see you justifying your inaccurate description of RMS' words. To me, it's telling that this article is over a year old and yet we're still seeing the same profound shortcoming--the most popular variant of the OS built to be free includes non-free software.

    --
    Digital Citizen