Slashdot Mirror


Intel Accused of Being an "Open Source Fraud"

Binary-Blob writes "Kernal Trap has an article up in which some key OpenBSD developers accuse Intel of being an open source fraud. The issue stems from the prevalence of firmware 'blobs' in open source projects, and OpenBSD's reluctance to use them unless they are distributed freely and without restrictions. Leading project creator Theo de Raadt offers that Intel should follow the example of other companies in the market: 'Intel must do this firmware grant in the same way that Adaptec, Atmel, Broadcom, Cirrus Logic, Cyclades, QLogic, Ralink, and LSI and lots of other companies have granted distribution firmware to be used by others.' He concluded by requesting that the open source community contact Intel to help get them to change their policies"

153 comments

  1. BSD confirms it by Anonymous Coward · · Score: 5, Funny

    Intel is lying...

  2. Dupe by Anonymous Coward · · Score: 0, Redundant

    Intel -- Only "Open" For Business

    Comment from previous story suggesting the kerneltrap article:
    Better article on the story

  3. help intel? by Anonymous Coward · · Score: 1, Funny
    He concluded by requesting that the open source community contact Intel to help get them to change their policies

    Yeah, Intel will just love that.

    1. Re:help intel? by j-pimp · · Score: 1

      Theo's goals are not to get love from intel, just firmware.

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
    2. Re:help intel? by geekoid · · Score: 1

      I wonder if he pisses off his wife and then asks for sex.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    3. Re:help intel? by j-pimp · · Score: 1

      I wonder if he pisses off his wife and then asks for sex. The angry Canadian is married?

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
  4. Nothing we haven't seen before... by Vexler · · Score: 1

    If you look at the supported hardware list, there are similar comments in there about Adaptec RAID controllers. Theo is definitely not one to be timid, and it shows even in innocuous places. That said, if a little boat-rocking can get Intel to listen to the OOPs, so much the better (contrast Intel's behavior with that of, say, IBM, or even SCO).

  5. Any relation to this article? by pembo13 · · Score: 2, Insightful
    --
    "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    1. Re:Any relation to this article? by Fred_A · · Score: 4, Funny

      Apparently, they've gone from being "not really open source" to being "an open source fraud". This can be viewed as a progress of sorts and therefore qualifies as news. Hence the new posting.

      At least that's my take on it. We"d have to consult with the /. staff shrink to know exactly what the real reasoning was.

      --

      May contain traces of nut.
      Made from the freshest electrons.
    2. Re:Any relation to this article? by sunwukong · · Score: 1

      Why so cynical? Slashdot is a paragon of the Open Source community.

      It's only reasonable and expected that they would (under appropriate license) distribute the original and the improvements together so everyone can benefit.

    3. Re:Any relation to this article? by Anonymous Coward · · Score: 0

      Why? Did Intel stop advertising on slashdot?

  6. The interface is the product by BadAnalogyGuy · · Score: 2, Insightful

    While it may seem backwards that Intel, a hardware company, would be loath to release the specs of their hardware so that third parties could develop drivers for it (essentially for free), you have to also assume that the specification itself provides significant insight into some "whiz-bang" hardware implementation that Intel doesn't want to be common knowledge. What seems strange is that de Raadt is calling for BSD-licensed "binary blobs". I can't imagine why he would want that in favor of BSD-licensed code, or better the hardware interface specs.

    It's a little bit frustrating that Intel, the de facto standard when it comes to PC hardware, would let its products flounder on certain platforms. Not that there's this huge market for OpenBSD users (it's dying, of course), but the effort involved in keeping the driver off the platform seems to be no greater than allowing the OpenBSD developers to have a crack at it.

    If I weren't a Windows user whose hardware is fully supported, I'd be right there with those guys. There's really no excuse for this sort of behavior.

    1. Re:The interface is the product by evilviper · · Score: 4, Informative
      What seems strange is that de Raadt is calling for BSD-licensed "binary blobs". I can't imagine why he would want that in favor of BSD-licensed code

      Because the source code for firmware is completely useless to all but 5 people on the planet. The firmware isn't the driver, the firmware is just a binary chunk that "SHOULD" be burned into eprom on the hardware.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    2. Re:The interface is the product by HornyBastard · · Score: 2, Informative

      "What seems strange is that de Raadt is calling for BSD-licensed "binary blobs". I can't imagine why he would want that in favor of BSD-licensed code, or better the hardware interface specs."

      In a case like this, it is the smart thing to do. Any company is more likely to give "binary blobs" instead of source code. de Raadt has more chance of getting what he asks for this way.

      --
      Death has been proven to be 99% fatal in lab rats.
    3. Re:The interface is the product by BadAnalogyGuy · · Score: 2, Insightful

      That doesn't make sense, as he specifically states that when the hardware doesn't work that the project is already in a "lose" state. From there, there is nothing more to lose. The only way to go is up, i.e. from hardware not working to hardware working.

      If that is his stance, then there doesn't seem to be any reason why he should settle from the outset for anything less than what his stated goals are. You can't negotiate upwards when you're losing.

      Strategically I see what you are saying, but ideologically and according to de Raadt's own email, that doesn't seem to be what is actually going on.

    4. Re:The interface is the product by IcePic · · Score: 4, Informative

      I think you're mixing stuff up.
      The "blob" part is like the Nvidia binary drivers for X11.
      What Theo is asking for is to be allowed to re-distribute the firmwares
      for the chips, so that you can use the network card for installs, for instance.
      If you are required to go through a webpage and click Yes before you can use
      your network card, then it's pretty much useless for installs unless you already
      had another network card in there already.

      Then, on top of this, he seems to want the specs for the API used to talk to
      this firmware-driven hardware, so that they can write a driver of their own.
      Big difference there.
      * Firmware - please allow us to redistribute verbatim copies of it.
      * API - docs in order to write free drivers.

      These are two things needed in order to get those intel cards going.
      Since the firmware in one way or another already is available on the
      net or on the CD in windows-format, there really shouldn't have to be
      such a problem to allow redistribution of it. For the API's, everyones
      guess as to why you'd need to keep them secret is as good as theirs.

      As he states somewhere, not getting these two parts makes the card
      unusable anyhow, so there's nothing to lose really.

      --
      -- I'm as unique as everyone else.
    5. Re:The interface is the product by Anonymous Coward · · Score: 3, Informative

      The "binary blob" in this case will not be executed on the PC side. It is firmware for the processor inside the device. This sort of firmware is traditionally closed-source - do you have the source code for your PC's BIOS, or the microcontroller in your keyboard? Theo just wants to be able to distribute device firmware with BSD. He doesn't care about the source code of the firmware.

    6. Re:The interface is the product by OeLeWaPpErKe · · Score: 1

      Why ? This makes the cards 2 or 3 times more expensive.

      Why not leave this on the legal fringes ?

    7. Re:The interface is the product by QuantumG · · Score: 2, Interesting

      The firmware could be useful to many people, we just have no idea what they could do with it because we're not given enough documentation for the device. There's either two possibilities, the firmware contains code, can contain bugs and can therefore be hacked to make the device work better or it is "just data" and is therefore not a "creative work" protected by copyright. If anyone had any balls these days we'd know which it was because they'd just distribute the damn binary blob anyway they liked and when Intel decided to sue they'd have to disclose what is in these binary blobs when they present their case in court. If it was just unimportant data the courts would throw it out. If it was code or otherwise "creative" data then their disclosure would be a good starting point for reverse engineering the blob, in which case we'd likely be free to create a clean room implementation of the blob and distribute that.

      --
      How we know is more important than what we know.
    8. Re:The interface is the product by Burz · · Score: 1

      Indeed.

      So where is Linux's ABI for driver-writers?

      Seems like Intel isn't the only one who is unwilling to make a committment here.

    9. Re:The interface is the product by Anonymous Coward · · Score: 0

      Want to write a new driver for Linux? Download everything you need, free, from http://www.kernel.org./ The "driver development kit", or "kernel" as it is more usually known, includes working source code for thousands of other drivers, which you can modify to make your new driver.

    10. Re:The interface is the product by Anonymous Coward · · Score: 0

      Interesting idea, but it's more a case of needing time / effort / money that isn't really justified to take it to court as opposed to "balls". Things could get much worse if they pressed for damages instead of just C+D. Granted, they probably wouldn't be that stupid, but ...

    11. Re:The interface is the product by Anonymous Coward · · Score: 0

      OP's (possibly troll) point is that the Linux ABI is *not* stable, therefore binary drivers require a kernel interface layer be recompiled whenever the kernel changes. This is DELIBERATE and done as an incentive to release open drivers, or at least docs for others to make them, which can be incorporated into the kernel thus avoiding this hassle. Also IIRC a stable ABI would force various kernel structures to be set in stone, reducing flexibilty / preventing later improvements. Possibly even compatibility problems if kernel internals HAD to be changed e.g. due to a vulnerability and the manufacturer didn't release a new driver.

    12. Re:The interface is the product by squiggleslash · · Score: 1

      Bear in mind what kind of "blobs" we're talking about. The blobs Theo is talking about aren't operating system drivers, it's not code that will be running under the computer's main CPU, these are firmware binaries for highly specific and specialized pieces of hardware.

      There's very little value in having the source code for that. The number of people who would even understand how the code would work would be small. Given the amount of stuff Intel feels needs to be put into "computerspace" (kernel + userland) in recent drivers such as that for the ipw3945 wireless cards, one can get a pretty good idea of how low level the firmware is. To put it bluntly: if you're expecting it to be as high level as 8080 assembler, you're probably expecting too much. The hardware that interprets the blob may not even be Turing complete.

      I'm not suggesting it wouldn't be good to have the source code, or even that Intel doesn't have a moral obligation - according to the morality of the Free Software philosophy - to provide it, but in real, practical, terms the source code is almost useless. What's more important is that the blob itself is available so that all operating systems, regardless of their licensing, can include the blob with their (fully Free Software) drivers.

      Getting Intel to release the source to the blob would be an uphill struggle for very little reward even if successful. Getting Intel to release the blob itself is much easier, and in practice is "good enough" to ensure Free Software can fully and freely interoperate with Intel hardware.

      --
      You are not alone. This is not normal. None of this is normal.
    13. Re:The interface is the product by QuantumG · · Score: 1

      The other alternative is to just reverse engineer the blobs, it really aint that hard.

      --
      How we know is more important than what we know.
    14. Re:The interface is the product by Achromatic1978 · · Score: 1

      Except it's cheaper to allow softcode firmware updates than continually reflash the hardware for every pointcode revision.

    15. Re:The interface is the product by gurumeditationerror · · Score: 1

      The other alternative is to just reverse engineer the blobs, it really aint that hard.

      Thanks for volunteering.

    16. Re:The interface is the product by Anonymous Coward · · Score: 0
      you have to also assume that the specification itself provides significant insight into some "whiz-bang" hardware implementation that Intel doesn't want to be common knowledge.


      What "whiz-bang" could there possibly be? It's a bloody radio! We're not talking about some super-new technology here, we're talking about a publicly available industry standard, that uses well-know techniques, that anyone can implement.

      There's no valid reason not to allow distribution of the binary blob. The OpenBSD crew are not even asking to open source the blob: they just want to be able to put it in their CVS and have it distributable on CDs, FTP, etc.

      If anything this would help Intel make more money as people would buy the hardware knowing that they could run open source hardware on it. I do not understand by what logic Intel is holding this back.
    17. Re:The interface is the product by Short+Circuit · · Score: 3, Informative

      No it doesn't...ATI's firmware is useless to NVidia, because their hardware is completely incompatible; NVidia can't make heads or tails of ATI's firmware. Thus, no secrets are lost, and no expense incurred.

    18. Re:The interface is the product by OeLeWaPpErKe · · Score: 1

      He's asking for the source, isn't he ?

    19. Re:The interface is the product by Dan+Ost · · Score: 1

      He's not asking for source to the blob.
      He's asking for the right to freely
      distribute the blob instead of requiring
      the user to click through a license
      agreement to download the blob.

      --

      *sigh* back to work...
    20. Re:The interface is the product by Anonymous Coward · · Score: 0

      Firmware blobs aren't a big security threat. They only interact with the hardware. They don't have access to the rest of the OpenBSD kernal. Drivers are a different story. Closed binary driver blobs present a real serious security risk. That's why OpenBSD is opposed to binary blob drivers, but not so much to closed firmware. They just want the right to freely redistribute the firmware.

    21. Re:The interface is the product by Short+Circuit · · Score: 1

      No, he's asking for permission to redistribute binary firmware under the BSD license.

    22. Re:The interface is the product by Anonymous Coward · · Score: 0

      The loadable microcode updates for Intel's CPUs may also contain bugs. I'm not sure what's the situation with those - there's a linux kernel API to installa them but does any Linux distribution supply any of those updates?

    23. Re:The interface is the product by squiggleslash · · Score: 1

      Er, yeah, that's what I just said.

      --
      You are not alone. This is not normal. None of this is normal.
    24. Re:The interface is the product by grahamm · · Score: 1

      Do not forget that IBM published the source code for the BIOS in the orginal IBM PC technical manual.

    25. Re:The interface is the product by Intron · · Score: 1

      In US courts, Intel would present sealed evidence so there would be no public disclosure of what's in the blobs. Anyway, I can tell you. The blob contains code which runs on the internal processor core in the chip. Incorporated in there is not just the chip interface, but also licensed IP, bug workarounds and hacks for slightly better performance. Some of the source they can't make public, or don't want to. Their choice.

      Not clear to me why they care about distribution of the binary. Maybe they just don't want the support calls.

      --
      Intron: the portion of DNA which expresses nothing useful.
    26. Re:The interface is the product by vertinox · · Score: 1

      you have to also assume that the specification itself provides significant insight into some "whiz-bang" hardware implementation that Intel doesn't want to be common knowledge

      Shouldn't a patent be enough to cover this?

      --
      "I am the king of the Romans, and am superior to rules of grammar!"
      -Sigismund, Holy Roman Emperor (1368-1437)
    27. Re:The interface is the product by bombshelter13 · · Score: 1

      What, patent something they're doing in the microcode? The microcode is software! I thought we were against software patents?

    28. Re:The interface is the product by LWATCDR · · Score: 1

      The problem not any type of wiz bang feature.
      It is the FCC.
      This is about wifi cards.
      Intel and some other manufactures use soft radios for their wifi cards. They use soft radios because it is cheap and very flexible. If you want to sell that product in a different market you just change some values in a register and you are transmitting on a different frequency an or with a different power setting.
      Just like every other none licenced radio transmitter these must not be "easily tunable". Ie they can not have a dial that you twist that makes them transmit out of band.
      Here is the rub. It seems that Intel's lawyers and of the FCC believes that releasing the hardware specs of the card would make them to easy to modify.
      The key word is easy. Just like it is possible to take your microwave apart and make it into an illegal transmitter it is possible to disassemble and reverse engineer a driver to tweak the power and frequency settings of a wifi card. The difference is that to the FCC telling people which register to tweak is like putting a knob on the radio. It makes it too easy.
      Notice that Intel is actually very good at releasing information on every other interface chip they sell. Graphics, USB, wired networking, and CPU info flows very freely. It is only when you are dealing with things that the FCC regulates that they don't give out specs.

      Again we have good old Theo shooting off his mouth and calling people names because they don't do what he wants them to.
      Binary blob drivers are a problem. They will only work on one type of cpu so if you are running anything but x86 your up a creek. The problem isn't Intel as much as the FCC. Soft radios are great from a developers point of view. They are cheaper and more flexible than using a fixed hardware solution. The problem is dealing with the FCC.
      Maybe if the FSF can get the FCC to rule that Intel can release the specs with out fear of losing certification then they would. Until then stop calling Intel names and use a totally free card like the Orinoco.
      Oh and one little detail...
      "If I weren't a Windows user whose hardware is fully supported, I'd be right there with those guys. There's really no excuse for this sort of behavior."
      You are getting EXACTLY the same level of support as "those guys" you have a binary blob driver buddy just like Intel offers for Linux and I believe BSD.
      Not one bit different.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    29. Re:The interface is the product by HiThere · · Score: 1

      No, sorry. I *don't* have to "assume that the specification itself provides significant insight into some "whiz-bang" hardware implementation". It could be true, but it's NOT something I feel any desire or obligation to assume...or even believe. I'm open to proof, but somehow I doubt that will be forthcoming.

      What I really presume is that most of these decisions are made by managers who don't know what's important, so they are practicing CYA. I see no reason to look for a deeper explanation. Amd if you want me to believe a deeper explanation, a simple assertion won't suffice. I'll need, if not proof, at least something that makes a plausible case.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    30. Re:The interface is the product by udippel · · Score: 1

      Hmm. Insightful. From the outer perspective, maybe.

      Actually, the Grandparent was better. Code doesn't deliver much; sorry to say and sorry to disappoint.
      If you don't know what is going on in the black box, some magic numbers combined with structures don't really help. It might work, but it might as well break one day or another.

      Plus, you need to make a distinction between interface documentation (that would become the driver), which OpenBSD has been asking continuously for; and the firmware, that - for cost reason - is loaded instead of burnt into the black box on some type of PROM. The latter is vastly uninteresting and mainly to make the black box work.

      What Theo wants, is the binary firmware as redistributable (would make everyone's life much easier); plus the specs of the hardware interface for writing a proper driver. Most of the vendor-supplied drivers are plain crap.

      That firmware isn't much of a 'blob', since it has nothing to do with the OS.
      Imagine, if it was burnt into the box on a PROM, you wouldn't consider it as blob, neither, would you. It is just the piece of code that makes the dead hardware do what the meaning of the box is supposed to be.

    31. Re:The interface is the product by Secret+Rabbit · · Score: 1

      """
      it's dying, of course
      """

      You seem rather certain of this. What makes you think it? B/c from what I've seen, OBSD is at least on the perimeter of many many many companies/intitutions/universities/etc networks. Kinda makes sense given its track record with regards to security.

      Or are you only considering users as in desktop users (which is quite narrow minded IMO)? Or are you confusing OBSD with NetBSD?

    32. Re:The interface is the product by evilviper · · Score: 1
      The firmware could be useful to many people, we just have no idea what they could do with it because we're not given enough documentation for the device.

      I've never bought into the philosophy of "we can't guess until we try."

      in which case we'd likely be free to create a clean room implementation of the blob and distribute that.

      You already are. You can skip the step of going to court and spending huge ammounts of money...
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    33. Re:The interface is the product by Anonymous Coward · · Score: 0

      What seems strange is that de Raadt is calling for BSD-licensed "binary blobs". I can't imagine why he would want that in favor of BSD-licensed code, or better the hardware interface specs.

      Dullard. He's requesting the right to re-distribute without restriction the firmware that has to be loaded when the device is initialised. This is not the device driver.

      In addition he wants hardware specifications so that he can write BSD-licensed drivers. That is a separate issue.

    34. Re:The interface is the product by Burz · · Score: 1

      This is DELIBERATE and done as an incentive to release open drivers, or at least docs for others to make them, which can be incorporated into the kernel thus avoiding this hassle.

      I kindof doubt that. Their attitude toward DRM shows they are willing to live with closed hardware and firmware, without any intentional thwarting of closed-system developers. I think the Linux gang are simply not willing to make interface committments.

      Also IIRC a stable ABI would force various kernel structures to be set in stone, reducing flexibilty / preventing later improvements.

      Only between major revisions, which might come every 5-7 years. That's primarily what major revisions are for: they are a special event for changing the interfaces, to the point where compatability breaks.

  7. I can't see this working by RLiegh · · Score: 0, Flamebait

    Seriously, look at who we're talking about. "Shaming" Intel into doing anything is about on a par with "shaming" MS into doing anything. Simply because the numbers don't add up. This is how I see this going:

    The OpenBSD Userbase: Give us the hardware specifications or we'll take our business elsewhere!
    Intel: There's two hundred of you, tops. Fuck off.

    This is especially true since --correct me if I'm wrong-- these cards already work in Linux.

    Of course, it's also obvious that Theo's "unique" brand of diplomacy does nothing to advance his case.

    He has no real leverage to speak of (not when it comes to anything the siez of Intel, at least!); I realistically think he has a chance of pulling this off.

    1. Re:I can't see this working by RLiegh · · Score: 1

      ,s/I realistically think/I don't realistically think/g

    2. Re:I can't see this working by Anonymous Coward · · Score: 5, Insightful

      This is especially true since --correct me if I'm wrong-- these cards already work in Linux.

      Why is it that this is one of the most popular arguments against Theo? I mean, sure it works under Linux, but Theo develops OpenBSD.

      Next time I hear some Linux user going off about how some device isn't supported I'll just argue that "--correct me if I'm wrong-- this device already works in Windows."
    3. Re:I can't see this working by ettlz · · Score: 2, Insightful

      OK, so although the GPL means BSD can't lift code directly from the Linux base (and there's no reason why that should work anyway), surely it has to be easier developing a driver by studying this code rather than reverse-engineering Windows binaries?

    4. Re:I can't see this working by RLiegh · · Score: 2, Interesting

      The difference is that Linux is an open-source OS, windows is a closed source one. So, when someone argues that Intel doesn't support OSS, they can point to the fact that a good deal (most?) of their cards do -in fact- run on Linux.

      It's not an argument "against theo", it's an argument against expecting Intel to give a shit about what is (in its' eyes) a fringe OS. From Intel's point of view, there simply isn't enough demand to justify changing what they're already doing -- particularly since they're already providing support for Linux.

    5. Re:I can't see this working by Anonymous Coward · · Score: 0

      Reverse engineering is ok per DMCA. Looking at GPL code is legal, but the virality of the GPL taints anyone who does so.

    6. Re:I can't see this working by Anonymous Coward · · Score: 0

      The argument against binary blobs is just as valid for Linux as OpenBSD. The problem has always been one of auditing. It's just that security is OpenBSD's primary focus.

      Another disadvantage of binary blobs is that with them Linux doesn't really support the hardware, so you can't expect the hardware to work on all platforms that Linux works on.

      Then there's the issue of vendor support - we all know that nVidia would never ever drop support for older cards from their driver. Oh, wait. they did.

    7. Re:I can't see this working by ettlz · · Score: 1

      But surely the GPL only covers the code itself, not what it does or how it does it?

    8. Re:I can't see this working by anpe · · Score: 2, Insightful

      Looking at GPL code is legal, but the virality of the GPL taints anyone who does so.

      Clean room design can help you circumvent this:
      http://en.wikipedia.org/wiki/Clean_room_design

    9. Re:I can't see this working by gwk · · Score: 2, Insightful

      Sigh the driver does work in OpenBSD but not well. Damien who works on the IPW driver in OpenBSD but which IIRC is also used by Net, Free and OpenSolaris! has been trying to get documentation so he can write a proper OPEN SOURCE driver
      i.e.
      From: http://damien.bergamini.free.fr/ipw/
      "I've started to work on a driver for Intel® PRO/Wireless 3945ABG network adapters, as found in recent Centrino(TM) laptops. Needless to say, this driver won't require any binary-only user-space daemon to operate, contrary to the Linux driver provided by Intel®. Such daemons that must execute as root and have complete access to the hardware are unacceptable for this project."

      They are also asking people who use ANY OPEN SOURCE OPERATING SYSTEM to complain so perhaps intel will change their policy regarding firmware licensing, right now a few of the sell out commercial linux distros can distribute the firmware because they have signed restricitve agreements, however the terms are completly unacceptable to many.

    10. Re:I can't see this working by QuadPro · · Score: 4, Insightful
      This is especially true since --correct me if I'm wrong-- these cards already work in Linux.

      The cards won't run without the firmware, not in Linux, not in BSD, not anywhere. Intel forbids distributing the firmware without agreeing to
      a restrictive contract. Some Linux distributions happily agree to that contract, and restrict their users by doing this. OpenBSD does not
      want to restrict their users, so they don't agree to the Intel contract. They want Intel to give permission to freely distribute the firmware files.

    11. Re:I can't see this working by Schraegstrichpunkt · · Score: 2, Interesting

      Technically-speaking, do you even need need clean room reverse engineering? As long as you don't copy code (i.e. you don't do anything that's prohibited by copyright statute), I would think you're legally in the clear. In that case, the benefit to doing it clean-room-style is that if the code you wrote happened to be very similar to the code you took apart, you would have documentation that shows that you couldn't have lifted code verbatim, because the person who wrote the code never saw the original.

      As far as I know, no such "tainting" exists in law, but your boss's lawyer will advise him to have you do things clean-room anyway, so that your laziness doesn't end up adversely affecting the organization.

    12. Re:I can't see this working by Pharmboy · · Score: 3, Insightful

      I think that would legally be called a "derovative product". Clean rooming is making something new that works like something old. Using the existing code to make code that works on a different platform is not the same. Since one runs on Linux and the new would run on BSD, you would have to change a chunk of the code anyway. The only way you can make a "similar" program/driver legally is that whoever is doing the coding is ignorant of the contents of the original piece.

      If Microsoft took Apache, then viewed the source and then rewrote it to replace IIS without a clean room method and used their own license, the open source community would go nuts. This is no different. Just because you LIKE the people who are writting the code, that doesn't make it legal or right.

      --
      Tequila: It's not just for breakfast anymore!
    13. Re:I can't see this working by LizardKing · · Score: 2, Informative

      correct me if I'm wrong-- these cards already work in Linux.

      IIRC they require a binary only blob that runs in userspace, and it's x86 only. Even if it was open source, I can understand why they'd want to do it in userspace given that the Linux driver ABI is such a moving target.

    14. Re:I can't see this working by ichigo+2.0 · · Score: 1

      If Microsoft took Apache, then viewed the source and then rewrote it to replace IIS without a clean room method and used their own license, the open source community would go nuts. This is no different. Just because you LIKE the people who are writting the code, that doesn't make it legal or right.

      But if they view the source code to figure out how the HTTP works, and then write their IIS replacement, is that really a violation of the GPL? Wouldn't that pretty much mean that viewing any GPL code makes it impossible to write closed source software, i.e. if I have hacked around the Quake 2 source, I am now unable to make a closed source OpenGL engine? That sounds strange, and I must have misunderstood.

    15. Re:I can't see this working by Anonymous Coward · · Score: 0
      I think that would legally be called a "derovative product"

      Funny, I couldn't find any dictionary definition for the word "derovative", so I somehow doubt it.

      And if you meant derivative, then it's pretty evident that you're not a lawyer.

      Here's what my dictionary says about derivative works:

      a work that is based on, or modifies, one or more preexisting works. A copyright owner has the exclusive right to prepare or authorize the preparation of a derivative work based on the copyrighted work. If a derivative work, considered as a whole, represents an original work of authorship, it may be separately copyrightable. However, the copyright covers only original portions of the derivative work.


      Clean rooming is making something new that works like something old. Using the existing code to make code that works on a different platform is not the same.

      No, the clean room technique is merely absolute proof that you didn't violate copyright. Not doing a clean room implementation doesn't automatically mean that you did.

      The only way you can make a "similar" program/driver legally is that whoever is doing the coding is ignorant of the contents of the original piece.

      Complete bullshit.

      If Microsoft took Apache, then viewed the source and then rewrote it to replace IIS without a clean room method and used their own license, the open source community would go nuts.

      Some people might, if they ever saw it (just as a matter of curiosity, how do you know that MS didn't do that?) However, just because some people might be upset that MS copied some functionality from an OSS project, doesn't mean that it would be legally wrong for them to do so. You're alleging that "X is illegal" by analogizing "some zealots don't like X, so therefore X is illegal", which is doesn't follow.

      Before you comment on this further, you should do some reading about the abstraction, comparison, filtration test. A good place to start (but not finish - by any means) might be here.
    16. Re:I can't see this working by squiggleslash · · Score: 5, Informative

      Can I interject here and point out that none of you are actually on-topic?

      This discussion is not about device drivers, it's about the "blobs" that contain things like firmware and the distribution licenses that come with them.

      For the most part, OpenBSD is doing pretty well creating device drivers. Indeed, it does better than Linux in many respects: OpenBSD's ipw3945 driver, for instance, is fully self contained and doesn't require the ugly hacks involving user-space daemons that the Linux version does. The author of the OpenBSD driver reverse engineered the Linux driver, and did so in a way that wouldn't taint anything (he hacked the driver to write information about what was being sent to what registers and when, recorded this information, and then wrote his driver. His driver is 99% based upon the actions of source code he's never seen.)

      The issue isn't writing device drivers. Most of the devices Theo is complaining about already work under OpenBSD. However, the only way to obtain some critical components, such as the firmware, is to navigate to a website, agree to a license, and download them.

      This especially a PITA if you're trying to get a network device to work. You can't access the network without the blob, and you can't obtain the blob unless your network is up. Not impossible to solve, but an added cause of frustration for anyone who's been in this situation.

      --
      You are not alone. This is not normal. None of this is normal.
    17. Re:I can't see this working by squiggleslash · · Score: 1

      The purpose of clean rooming is actually just to prove that your product is not a derivative, not because looking at source code automatically taints anything you write afterwards.

      If Microsoft took Apache, viewed the source, and then wrote, from scratch, a web server, would the Open Source community go nuts? No idea. The conspiracy theorists might, I guess. After all, some are still convinced that Windows is based upon VMS, because the guy who wrote the kernel once worked on VMS. The two operating systems are barely comparable, having only in common what modern operating systems generally do. Linux has far, far, more in common with the Unix kernel than the Windows kernel has in common with the VMS equivalent. But you're right, people will claim that copyright infringement has to have occurred because, like, the programs have the same function, and the guy saw both, so...

      But here's the thing: If Microsoft took Apache, viewed the source, and then wrote, from scratch, a web browser, would the Open Source community go nuts? Definitely not. Yet both products are as likely as not to be "tainted" by the fact the authors looked at the source code for Apache.

      The truth is that every time you look at source code, there's the possibility that someone will complain, at some point in the future, that you might have copied from them, regardless of what you work on. If we were to be 100% paranoid at this point, we couldn't get anything done or written at all. The reality is that we take a pragmatic view and "clean room" when we think someone might complain. Clean rooming is not about avoiding taint. All code written from scratch is equally tainted. Clean rooming is about avoiding copyright holders with a grudge from alleging specific instances of taint.

      --
      You are not alone. This is not normal. None of this is normal.
    18. Re:I can't see this working by Anonymous Coward · · Score: 0

      That's incorrect, it's a kernel driver and the "binary blob" in question is the wireless chip firmware and has nothing to do with x86 or not. Besides, the ipw driver in question is already in the kernel sources so the ABI is a non-issue.

    19. Re:I can't see this working by Anonymous Coward · · Score: 1, Informative

      Looking at GPL code is legal, but the virality of the GPL taints anyone who does so.

      You need to stop inventing your own clauses for the GPL.

      - Looking at GPL code does not engage the GPL. The GPL is a copyright license, so something has to be copied before copyright becomes relevant.

      - Writing new code after having read GPL code does not engage the GPL either, unless part of the GPL code has been copied into the new code.

      The new code doesn't even need to be developed under clean room conditions, so long as there has been no overt nor covert copying.

      And finally, using information contained in the GPL code when writing the new code is perfectly acceptable. "Copying" has absolutely nothing to do with "extracting information from" --- copyright law is perfectly clear on that.

    20. Re:I can't see this working by Pharmboy · · Score: 2, Interesting

      If MS did NOT cleanroom their implimentation, then yes, they would be open to lawsuits. With a cleanroom system, ONE groups will look at the code, and how it works, describe it to a 2nd group who hasn't seen the code but will write the 'new' code based on what the 1st group learned. That way the group coding has never seen the original sourcecode and not likely to be able to violate any copyright law when writing. Patent law is another issue.

      You CAN view source code and write your own version of the software, but if any code matches (and because some functions WILL match, out of the fact that there is sometimes only one logical way to do a task) then you get to explain to the judge how "Yes, I looked at the code, but I didn't copy it. No, really.". This is why most places will cleanroom software instead.

      --
      Tequila: It's not just for breakfast anymore!
    21. Re:I can't see this working by Aladrin · · Score: 1

      His example is slightly flawed verbage-wise, but you got the gist of what he was saying.

      The answer is different, though. It's not a violation of GPL, it's a violation of copyright. You were given no rights to peek into the application and use the logic within for another non-GPL purpose. The GPL is the only thing granting you rights to that code and it's structure/logic. Technically, you can't 'violate' the GPL. You violate copyright laws. The GPL is just legal permission to use the work in certain ways.

      So this really has nothing to do with the GPL... That's a red herring.

      Look at it this way: If you peek at the Windows source, then write something like WINE... Would MS sue you? Yes, because you violated their copyrights. It doesn't matter what license MS used to allow you to look at the source, there was no permission given to use that knowledge to create a competing product.

      That's why this needs a clean room. You could have 2 teams do this. 1 would pick apart Apache and write details specs on what it does, and the other uses those specs to create a product. This guarantees no code contamination and has been proven completely legal. (I think it's also nearly useless at this point for software... It's too massively complicated to cleanroom things when you could just write it from scratch in the same amount of time and have a unique (and hopefully better) product just by having some idea what the application does and how it could be better.

      --
      "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
    22. Re:I can't see this working by Tim+C · · Score: 1

      The problem is if you read the GPL code, and someone sues you, it's very much harder to prove that you didn't lift sections of it - especially if there are similarities between the two sets of source code.

    23. Re:I can't see this working by nebulous_afterthough · · Score: 0

      Your so short sighted. Your pegging this as an OpenBSD specific problem/skirmish/whatever.

      What Theo is really after is changing the way these companies work with the Open Source community. Linux/FreeBSD/NetBSD/etc/etc all have a stake in this. If you don't help champion this, things will only get worse for ALL users.

      But lets assume your right. I'm one of those two hundred Intel just told to "fuck off". In doing so, you've just alienated me and left me feeling quite jaded. Unfortunately for you, I'm an IT pointy haired boss weilding a $30mm budget for $2 billion dollar company. Your casual brush off just influenced my future purchasing decisions. Does that really mean something? Well, let me draw a comparison. I was caught up in the Adaptec RAID controller versus OpenBSD fiasco. Ask me how many Adaptec RAID controllers I've purchased since then. The answer is: LSI really likes me and my 400+ servers.

      Additionally, I've taken every opportunity to recommend LSI and discourage Adaptec purchases on mailing list and in conversations with other managers at other companies. It's surprising all the places and roles you find OpenBSD used. Obscure, yes. Widely used, yes.

      You have to be careful when you make a decision to alienate someone(s)... You postulate Theo has no leverage. I beg to differ.

    24. Re:I can't see this working by Anonymous Coward · · Score: 0

      You realistically think he has a chance to pull this off but all your arguments point to why he should be ignored? Strange.

      This has nothing to do with Theo except that Theo is rightly using his position as a "lightning rod," but what BSD users are familiar with being treated to over the years with the pseudo-Open Source "friends." The "Linux has it, ignore everyone else" attitude quickly tires after you get over the Linux wonderment.

      "Intel: There's two hundred of you, tops. Fuck off."

      If so, Intel is making a mistake if they think this. There are certainly more than 200 users (I know you said the above partly in jest) but there are many other users who watch what Intel does, as the /. comments prior about Intel being a fraud or only open source for business easily suggest.

      I have ignored Intel hardware for years, buying AMD and even Via chips and all of them use motherboards with non-Intel North and South bridges. I also own many personal computers, and make purchasing decisions for my businesses. I'm talking probably $15,000 a year, $10,000 or so directly related to products Intel sells that do not got to Intel, and I've been doing this since 2001. (It's also why I stopped buying Apple machines recently, although we only bought one every year and half or so.)

      Not much money to a billions of dollars a year industry, but if there are more like me, that so-called long tail economics seems to apply (see Soekris).

      It's not that AMD or Via is actually or necessarily better, just that I HATE the attitude that if they/Intel will *only* listen to the majority users to the exclusion of all others, esp. when they CAN and SHOULD accomodate both/all parties (i.e. the majority of users like or use willingly DVD or Apple or Windows DRM; does that make the MPAA, Apple, and Microsoft "right" because the majority bend over a take it?). This is such a case; because the Linux camp is served (for now), does it mean they are doing the right thing to the exclusion of others even though it counteracts the philosophy that has made Linux what it is today?

      I was rather excited when Intel "sort of" released open sourced drivers for their latest video hardware, and they've finally offer a decent motherboard/chip combo with their integrated graphics motherboard and Core Duo 2 processors. This puts a damper on things.

    25. Re:I can't see this working by Pharmboy · · Score: 1

      (I think it's also nearly useless at this point for software... It's too massively complicated to cleanroom things when you could just write it from scratch in the same amount of time and have a unique (and hopefully better) product just by having some idea what the application does and how it could be better.

      For big apps, yes, but for drivers and stuff like audio and video codecs or document types (*.doc, *.wave, etc.), it would still be the best way to create a infringement free product. Most of the "big ideas", like MS Office, are too big to begin with. I don't think I would want to create a copy of that, and take OO's approach, starting from scratch and just reverse engineering the doc types, as you stated.

      --
      Tequila: It's not just for breakfast anymore!
    26. Re:I can't see this working by stuuf · · Score: 1

      The kernel driver is open source, as is the userspace regulatory daemon. They're probably x86-only at the moment, only because the cards have only had significant use on x86 (although upcoming core 2 popularity might bring an x86_64 port). The binary blob is the firmware or microcode that runs on the chip inside the card; it's not one of those "shims" that ATI/nVidia do to keep the actual driver code secret. The firmware source is probably only useful to you if you're one of Intel's hadware engineers. Personally I don't think it's a huge deal that this isn't open, since the sources for it are only useful for symbolic, and maybe research purposes, and the restrictive redistribution license didn't seem to affect me (then again, Gentoo often bypasses these types of licenses).

      --

      Everyone is born right-handed; only the greatest overcome it

    27. Re:I can't see this working by Schraegstrichpunkt · · Score: 1

      I understand this view, but my understanding is that it's an urban myth. Do you have any statute and/or case law to back up your claims?

  8. Where do you draw the line?? by EmbeddedJanitor · · Score: 5, Interesting
    I'm not an Intel fanboy by any measure, but I wonder where you draw the line as to where you just accept specs and where you start demanding more detail.

    "Just download this firmware blob" is one level, then "just load this microcode". If you're using a Xilinx FPGA running a downloadable CPU core, should that be treated as yet another CPU (ie a sealed blob) or should the downloadable core be considered firmware/microcode? As we get more and more interesting hardware, the boundaries are only going to get more blurred.

    Even regular CPUs have an interface (the instruction set etc) and their inner workings are sealed from the software developers.

    --
    Engineering is the art of compromise.
    1. Re:Where do you draw the line?? by wild_berry · · Score: 1

      Is Java bytecode interpreter or JIT compiler a binary blob?

    2. Re:Where do you draw the line?? by Short+Circuit · · Score: 1

      Your analogy doesn't work...A Java interpreter is equivalent to the FPGA, not the program loaded on it.

    3. Re:Where do you draw the line?? by asuffield · · Score: 1
      Even regular CPUs have an interface (the instruction set etc) and their inner workings are sealed from the software developers.


      The inner workings are usually published in great detail, because they are critical to writing efficient code and compilers for the processor. Once you know the full details of how to optimise code for a CPU, you know more or less what it's operational schematic is. Any academic researcher in chip design could sketch out the architecture of the Athlon64 based on the manuals provided by AMD. Nobody considers that information to be secret.

      What you don't know is the actual layout of the circuitry on the chip, which is what you'd need in order to manufacture more chips. You probably don't care much, either. In the case of Athlon/Pentium processors, you're not going to care, because unless you are a chip-making giant you do not own a fabrication plant capable of building those processors and aren't ever going to own one (they cost billions) - and if you are a chip-making giant, you own a collection of analysis equipment which includes a scanning electron microscope, and have already scanned the chips of all your competitors to see how they are put together. It really makes no odds whether they publish that data or not; the only people who could use it have no need for it.
    4. Re:Where do you draw the line?? by networkBoy · · Score: 1

      "What you don't know is the actual layout of the circuitry on the chip"

      You also don't know:
      What signal paths operate under which micro-ops
      any "skeletons in the closet" being worked around with microcode

      Same goes for the binary driver blobs. I'm somewhere between with Intel and with Theo on this.
      Binary drivers allow you to hide tweaks that are needed to ensure operation but that you don't want as general public knowledge.

      -nB

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    5. Re:Where do you draw the line?? by HiThere · · Score: 1

      You may have notices that MANY refuse to accept the Sun Java terms. gcj and Apachy Harmony come to mind. Of course this is partially because the terms under which Java is offered are onerous (not in all circumstances, but in some circumstances).

      Don't use Java as an argument for accepting Intel's actions. Sun's actions are also, at best, dubious. Yes, they are to the short term advantage of many people...but the long term benefit appears distinctly dubious. (Personally I switched to Python as soon as it was feasible, and haven't regretted it. Whenever I think of using Java I wonder how the Harmony project is progressing. [Well, I have a history of flitting between programming languages. But I haven't seriously been back to Java since I dropped it a few years ago...I've even been back to Ada more recently.])

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    6. Re:Where do you draw the line?? by raddan · · Score: 1

      I think you can draw the line when a bug in the blob can result in an attacker exploiting the system.

      That's a legitmate gripe, but I think Theo's main concern here is that the BSDs can't even freely distribute the blob-- a blob which only works with one piece of hardware, and which does not reveal any trade secrets (since it's in binary form). Yet these very same vendors go to OSS conferences and preach about their "openness". That's when it becomes apparent that their real goal is getting cheap, if not free, labor. Intel's presentation slides that Theo mentions in his email to misc@ all but come out and say this.

    7. Re:Where do you draw the line?? by wild_berry · · Score: 1

      Don't use Java as an argument for accepting Intel's actions.

      I wasn't. It's just an idea to propel discussion about what is free.

    8. Re:Where do you draw the line?? by sjames · · Score: 1

      That's exactly the problem. While in an ideal world, absolutely everything is laid bare for examination, in our less than ideal world, a reasonable compromise might be that the firmware for the device can be a binary blob if it must be, but the API for the device functionality should be open. After all, that blob could as easily be stuck in a ROM on the board or even burned into one of the ASICs. The only reason it isn't is cost cutting.

      The problem comes when a company (such as intel) CLAIMS that they are free and open but then refuse to allow free re-distribution of that blob. Instead, they insist that the end user download it from their site and install it themselves. Of course, that raises the bar for the end user, adds inconvieniance, possibly prevents successful installation (what happens if your net connection is down and you REALLY need to complete the install?), and of course, we have no assurance whatsoever that after all the time and effort of developing the driver, Intel won't just stop allowing the download and render it all useless.

      An important aspect of Free software (be it BSD or GPL) is that once it's "out there" the author can't take it back.

      As for where to draw the line, my thought is if it runs on the host, it needs to have source. If it runs ONLY on the device and the host just acts as storage for it (a sort of software implemented ROM if you will), it may be a blob so long as the driver developer may include it freely in the driver's source package.

      My reasoning is simple. If it runs on the host CPU, it can open a security hole, crash the machine, or unreasonably constrain the structure of the OS and/or the driver for that OS.

  9. The problem, the answer, and the other problem by Anonymous Coward · · Score: 0

    The problem is that much of the smarts in these devices is actually implemented in the software driver, and so the driver is part of intels "value proposition" and to give that away whould be a big gift to the Chinese low-cost copycat manufacturers - otoh not that useful to users, who get the driver if they buy the device and don't need it otherwise.

    The answer is for Intel to define a "dumb" driver that just drives the hardware and doesn't include any smarts. They can document this and open it up with impunity since it won't reveal enough for the copycats to use. The open source community can then implement their own version of the smarts under the open development model, which is exactly how they do all their oither software.

    The other problem with the above is that by documenting the low-level interface, Intel would be sanctioning the open driver effort. And if the open driver is unreliable for example while in beta, it might look bad for Intel. They would need to manage customer expectation carefully.

    In general I find devices that need substantial help from the CPU to be flaky and slow. In the long run I think we will come full circle and return to all devices having their own smarts internally and very simple standardised interfaces to the CPU just like the original IBM PC.

  10. RSS by Anonymous Coward · · Score: 0

    The RSS for this story includes an AMD ad. Seems wrong to me.

  11. OpenBSD and the UN by OeLeWaPpErKe · · Score: 2, Funny

    do !

    Or we'll call you really, really, really dirty names.

    There, however, seems to be a small hole in the plan

  12. As good a time as any to revisit UDI. by Burz · · Score: 2, Insightful

    From 1998, this article describes how Intel was eager to have Linux support UDI, the Uniform Driver Interface.

    A lot of water has gone under the bridge since then, but UDI seemed to get submerged.

    1. Re:As good a time as any to revisit UDI. by Wesley+Felter · · Score: 2, Interesting

      Linux developers will never allow UDI because it is a stable driver ABI. OpenBSD developers will probably not allow UDI because it supports binary drivers, which they don't want. Probably the only major OSes that would potentially benefit from UDI are OS X and Solaris.

    2. Re:As good a time as any to revisit UDI. by kimvette · · Score: 1

      It's possible interest in UDI went down with the Itanic (following your submerged theme). Since the Xeon and Core 2 (and other x86 derivatives) are by and large fairly low-margin products, it's no surprise that vendors have shown little interest in supporting such an effort.

      However, with Microsoft's gradually losing market share -- even if it's a slight loss now, I expect it to grow exponentially when Vista hits the streets and Microsoft moves increasingly to the software-by-subscription model -- it is in vendors' best interest to support Linux. Preferably, by open sourcing drivers, but worst case, they can at least document the interface for open source developers.

      After all, how much is really revealed by Intel saying "bit 4 at register 0xfe72 will enable US frequencies" or by ATI saying "to change channels up by one in the All-in-Wonder x872072, place value 0x01 in register c7347"

      I mean, really! What *BLEEPING* competitive advantage is lost to AMD or to Nvidia (respectively) by publishing this information?

      If you can't figure it out, let me tell you: None Whatsoever. Especially since their competitors already have Softice (or equivalents) in-house, huge engineering staffs where they can afford to cleanly reverse engineer their products, and electron microsopes which they can use to reverse engineer the circuitry itself. The ONLY ones they are ultimately hurting is themselves as their bedbuddies at Microsoft gradually alienate customers more and more and they seek Linux or BSD or OSX to escape the vendor lock situation.

      --
      The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
  13. The article URL by Burz · · Score: 1

    http://lwn.net/1998/0924/

    Sorry, I didn't quote the URL in the parent post (so slashdot removed it).

  14. Open drivers are good for the manufacturer by _eb0la_reston_ · · Score: 1

    Sorry, I don't get it: OPEN drivers are good for manufacturers.

    Their products get good support, and good drivers written by others; and they also get more sales without spending money in marketing (unless your product is a mess; if that's your case, you've got a different problem ;-).

    --
    mootion.com - Never underestimate VCs stock options (was: Web 2.0)
    1. Re:Open drivers are good for the manufacturer by Sancho · · Score: 1

      If the driver/specification reveals trade secrets about your hardware, it also gives your competition an edge. And it does so in order to target that 3% that doesn't use Windows or OS X (assuming the company write Apple drivers.)

      Yes, all of your friends run Linux. In the real world, not that many people really do. The number gets reduced even more significantly when start discounting servers, which still need drivers, but a much smaller subset of them (no one sane runs a server over 802.11, and servers have no need for advanced graphics capabilities).

    2. Re:Open drivers are good for the manufacturer by _eb0la_reston_ · · Score: 1

      Sancho, OpenBSD (as this is the case) is a great software for embedded systems / appliance hardware.

      Selling stuff (all kind) to the embedded systems community (much bigger than the 3% non-windows consumer electronics you mention) is hard since they *must* have excellent hardware (=driver) suport.

      You cannot get hardware running with confidence on embedded systems if you have to load a blob and cross your fingers hoping that blob/firmware code won't have (many) bugs inside you won't be able to fix, and the manufacturer won't fix for me since they have other people source code to blame... ... and *please* don't ask me to use XP Embedded, QNX, Neutrino, etc... embedded systems are expensive enough *just* running Net/OpenBSD.

      --
      mootion.com - Never underestimate VCs stock options (was: Web 2.0)
    3. Re:Open drivers are good for the manufacturer by Sancho · · Score: 1

      What embedded products are you referring to? I wasn't aware that OpenBSD was the basis for many.

      As far as that goes, though, you can often license specs from hardware companies in these cases. You'll be forced to sign an NDA, meaning that you can't release the source or specs, but it would mean you can fix problems.

  15. Re:News at 6 !!! Film at 11 !!! by smittyoneeach · · Score: 1

    Disagree. TdR is acting as prosecutor in the court of public opinion.
    Conviction at the cash register could positively affect other notorious outfits like ATI and nVidia.
    I rather prefer TdR's "don't be a jerk" campaign to RMS's "your thinking is false: I shake my fist at you and call you 'unethical'" approach.
    Possibly more a stylistic difference than anything else, but technical folks seem to make screechy evangelists, and do better to cleave to the pragmatic angle.

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  16. RTFA, etc... by Schraegstrichpunkt · · Score: 4, Informative

    There are two pieces of software here: the driver (which runs on the host), and firmware (which runs on the card). Theo wants freely redistributable firmware (which can be binary-only for all he cares), and documentation to write a free driver (which definitely must NOT be binary-only). Try not to get confused: He's not asking for free (as in freedom) firmware (though it would be nice), and he's not tolerating binary blobs that run on the host.

  17. Speaking of pulling things off by Rogerborg · · Score: 2, Funny

    As a user of Alyson Hannigan's film products, I demand that she must give me open access to her networking wetware. I represent thousands of nerd, all of whom want this access, and I am prepared to act as a gatekeeper and distributor, conditional only on being given first access rights. I expect this demand to have every bit as much success as Theo's.

    --
    If you were blocking sigs, you wouldn't have to read this.
    1. Re:Speaking of pulling things off by Anonymous Coward · · Score: 0

      Well if you're such a fan, at least spell her name right.

  18. Tasty kernels by Orp · · Score: 1, Funny

    A new slashdot record - the *first word* of an article summary is misspelled! Congratulations!

    --
    A squid eating dough in a polyethylene bag is fast and bulbous, got me?
    1. Re:Tasty kernels by AlXtreme · · Score: 1

      You must be new here! Welcome!

      --
      This sig is intentionally left blank
  19. Security by AB3A · · Score: 1

    The danger of blobs is that they may contain a bug which could affect security. Worse, it might even contain spyware. Security being one of the chief concerns of the BSD crowd, why wouldn't TdR want to be upfront, honest, and open about what's in the blob?

    --
    Nearly fifty percent of all graduates come from the bottom half of the class!
    1. Re:Security by LurkerXXX · · Score: 2, Interesting

      Firmware blobs run only on the chips they are for. They don't run on the central CPU, and they don't run in kernal space, therefore, they aren't a security risk. Drivers blobs are an entirely different matter. Drivers blobs are a security risk and need to be open.

      Security is not just one of the chief concerns of the BSD crowd, it is one of Theo's chief concerns. If he's not asking for open blobs, it's because they aren't a security concern.

    2. Re:Security by Anonymous Coward · · Score: 0

      Firmware blobs run only on the chips they are for. They don't run on the central CPU, and they don't run in kernal space, therefore, they aren't a security risk. Drivers blobs are an entirely different matter. Drivers blobs are a security risk and need to be open.

      If the device has a DMA engine, then it may very well pose a huge risk. A risk which no OS can prevent. A device which runs independantly of the system CPU, but which has read and write access to system memory, is pretty damn dangerous. It can read and write system memory without the OS even knowing about it.

  20. Intel is being unreasonable by Anonymous Coward · · Score: 2, Insightful

    OpenBSD want to distribute firmware along with the OS under an acceptable license. They are not asking for the source
    code of the firmware. Intel are instractible here, so owners of Intel wireless devices needs to personally accept a license
    before downloading the firmware. As an example: http://ipw2100.sourceforge.net/firmware.php

    As for open source drivers: OpenBSD wants hardware documentation, not a Linux driver, so that they can write their own drivers.
    Intel claims that they are open source friendly and gives out documentation, but the last is clearly a lie since OpenBSD had to reverse
    engineer several Intel wireless chipsets.

    Giving the appearance of beeing friendly to open source, while not beeing so, is the latest fad in business. Intel is an example
    of this fad.

  21. Of course not. by Morrigu · · Score: 0, Redundant

    If it was, it'd be a DUPE.

    And we all know there are no dupes on Slashdot. :)

    --
    "We can categorically state that we have not released man-eating badgers into the area." - Major Mike Shearer, UK
  22. what a surprise by Anonymous Coward · · Score: 0

    Theo de Rat has issue with $VENDOR. In other news: sky blue, sun hot, rain wet.

    Didn't he try this sort of crap with Sun and USIII a few years ago?

  23. Theo.... by Capt+James+McCarthy · · Score: 1

    Sadly, Theo's pissed off so many people that even if he asked nicly, companies would tell him to get bent just because of his history.

    My server does love OpenBSD though.

    --
    There are no loopholes. It's either legal or it's not.
  24. Newsflash by tomstdenis · · Score: 1

    Most sufficiently large "OSS Friendly" companies are MSFT users at heart. They cling to the OSS side of things usually just to drum up business. That Intel does this [???, they do? my ipw2200 driver works fine without clickthroughs...] is no big surprise really.

    Tom

    --
    Someday, I'll have a real sig.
  25. SRAM vs. flash memory by tepples · · Score: 1
    Except it's cheaper to allow softcode firmware updates than continually reflash the hardware for every pointcode revision.

    Is SRAM to hold the microcode really that much cheaper than flash memory to hold the microcode, even when you figure in lost sales and tarnishment of the brand to users of alternative operating systems?

    1. Re:SRAM vs. flash memory by Anonymous Coward · · Score: 0

      The firmware has to be loaded into SRAM anyway to speed up its execution. Flash to store it on the card would only add to the cost, without any benefit (for the hardware manufacturer at least).

    2. Re:SRAM vs. flash memory by tepples · · Score: 1
      Flash to store it on the card would only add to the cost, without any benefit (for the hardware manufacturer at least).

      No benefit at all? Not even increased sales by marketing to customers who demand hardware that is compatible with minority operating systems? If Intel managers have made the decision to ignore this market by refusing to distribute the microcode in nonvolatile form on the card and refusing to license the microcode for distribution with minority operating systems, then Intel deserves the lost sales.

  26. And from the tin-foil-hat dept. by Anonymous Coward · · Score: 0

    Downloading is dangerous to Man-in-the-Middle and Firefox-exploit attacks. That means that by downloading each time, it is easier to get malware firmware, depending on who you are according to google's database. And rumors have it that those cards have an entire CPU and their firmware can act as a computer inside the computer, steal data, etc.

    Linux should stand by this.

  27. Ha-Ha morons by unity100 · · Score: 1, Funny

    Yea intel people, i mean YOU.

    You are fighting AGAINST the people you know ?

    And this "the people" is not "people" in like "some and the others" or a socialist, communist obscure concept of "people".

    This is THE PEOPLE, like in the declaration of independence, like in french revolution, like in WE ALL.

    WE are the people. You are fighting against us.

    Please mention a few names of persons or organisations that have fought against the people and won, from any point in history.

    Silence ? you got my point i believe.

    1. Re:Ha-Ha morons by Macthorpe · · Score: 1

      "Please mention a few names of persons or organisations that have fought against the people and won, from any point in history.

      Silence ? you got my point i believe."

      You know, leaving a gap in the text there doesn't mean they can reply within it.

      --
      "It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
  28. Re:Intel's response by Anonymous Coward · · Score: 0

    That about sums it up nicely.

  29. Re:News at 6 !!! Film at 11 !!! by russotto · · Score: 3, Funny

    For Theo de Raat to have a "don't be a jerk" campaign is like RMS having a "shave every day" campaign.

  30. Parent severely underrated at +3 by Mateo_LeFou · · Score: 1

    POTD IMO

    --
    My turnips listen for the soft cry of your love
  31. /. Shrink by Mateo_LeFou · · Score: 1

    I'm pretty sure they just use the one built into emacs

    --
    My turnips listen for the soft cry of your love
  32. Theo abuses the slashdot community by Anonymous Coward · · Score: 0

    by calling us names and telling us to fuck off, then every 6 months or so he sends a plea for help to /.

    Well, Theo, please FUCK OFF

  33. Intel Open Source: Never gonna happen by Theovon · · Score: 1

    It's amazing to me how many people think bullying and mass-emailing is going to get a krufty old-school company like Intel to do ANYTHING. Even IBM isn't much of an exception, because they keep their proprietary and open source stuff carefully separated, and Sun's OpenSparc was already an open standard before they release the source code. These companies have markets much larger than open source users that don't care at all about open source!

    In my opinion, the only way we're ever going to have truly open hardware is for us to develop it ourselves. In case you weren't paying attention, the Open Graphics Project already has hardware!!!

    Yes, it's an early step in the process, but when volunteer open source development meets up with expensive hardware production, things tend to go a bit slowly. But engineering samples are currently undergoing tests, and the project members are working on test benches for it.

    I want to slap anyone who even bothers to call Intel. It's a total waste of energy that they could be spending on a real organization that is really producing open source hardware, with schematics and source code online. Oh, and we're not talking about just releasing documentation on how their hardware works. Their entire hardware development process is out in the open and open source. Not only can you read about how this stuff works, but you can look at every level of detail, down to how the hardware is wired.

    The only way we're ever going to get good graphics hardware for open source is to make it ourselves!

  34. Re:News at 6 !!! Film at 11 !!! by Golthur · · Score: 1

    Oh, how I wish I had mod points. Well done. You got coffee up my nose on this one.

    --
    Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
  35. If released as open-source... by TheSHAD0W · · Score: 1

    ...does this mean a firmware blob can be decompiled and redistributed that way?

  36. You forgot SCO unix by Anonymous Coward · · Score: 0

    ...oops, sorry, you also said "major." Nevermind... ;-)

  37. No Blobs? by Hamoohead · · Score: 1

    How long before they declare a moratorium on The Mummy?

    --
    "If your parents never had children, chances are you wonât either." -Dick Cavett
  38. Light's out, Pard. by Anonymous Coward · · Score: 0
    Somewhere in a lonely hospital room, BSD is dying.

    Lights out . . . Pard.

  39. Intel is not a monolith by dbc · · Score: 1

    People think of Intel as some big, monolithic, organization, when it is far from that. Decisions are pushed down to a fairly low level. Ranting at "Intel" because of some perceived "policy" like this only points out that the ranter has done less than zero to understand how Intel is organized. Lobbying at "the company" will do no good. These decisions are ratified by dozens of general managers around the world, separately, without consulting each other or some non-existant corporate policy. That is, if it rises to the GM's attention.

    Got a beef about a particular part? Identify the unit that makes that part. Identify the people that advise the GM of that unit. Lobby them.

    Saying "Intel doesn't support open source" is like saying that "the person who makes global policy decisions for all distribtutions of Linux world-wide clubs baby seals".

    In fact, Intel has released a lot of various stuff under BSD, and contributes to FOSS software under various licenses all the time. But, every project decides what is in their own best interest. Sometimes, they even get it right.

  40. Re:Intel Open Source: Never gonna happen by Anonymous Coward · · Score: 0

    That's nice and all, but it's not the graphics hardware that remains closed...

  41. kernAl trap? by Anonymous Coward · · Score: 0

    What the heck is kernal trap?

  42. Arguments against Theo by LWATCDR · · Score: 1

    How about this argument against Theo.
    He is the FOX news of FOSS.
    He is presenting this in the MOST inflammatory way possible and offering only one side of the discussion.
    Here is a more balanced view of the problem.
    Intel and many other manufactures of wifi cards use soft-radios. This allows Intel a great deal of flexibility in what frequencies and how much power the radios can use to transmit. If the FCC opens up a different band or if Intel wants to sell the card in a different country with different regs all they have to do is change some values loaded in the driver and your set.
    The problem is that by changing some settings in the driver the device can be set to transmit in an illegal manner.
    Just like the walkie talkies you buy at BestBuy can not have a knob that you can set so that it transmits on the police band wifi cards can not have a knob that you can set so that it transmits with too much power or on the wrong channel.
    Intel's lawyers and or the FCC see giving out the hardware specs as putting a knob on those cards.
    So Intel offers binary blobs to the FOSS community so that they can us Intel's wifi cards but not bring down the wrath of the FCC.

    It isn't a perfect solution. The biggest issue is that the drivers only work for the X86.
    The key here that in all likelihood Intel isn't trying to just be a jerk and or keep secrets from the FOSS community. There are legal issues involved.
    However Theo loves attention and seems to like to "Stick it to the man" even when "the man" did nothing wrong.

    Of course being reasonable and understanding doesn't get you on the front page of slashdot twice for the same story.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    1. Re:Arguments against Theo by IcePic · · Score: 1

      The windows drivers I've seen on laptops ask their users to enter what country they are in,
      meaning it is extremly simple to choose a "better" country for you broadcasting rules if the
      current one doesn't allow what you like. How come the FCC dont raid those manufactorers?

      --
      -- I'm as unique as everyone else.
    2. Re:Arguments against Theo by LWATCDR · · Score: 1

      Maybe all those countries happen to be in band as far as the FCC is concerned. The actual chips tend to have the ability to transmit a lot more power then is safe or legal. You will probably melt the WiFi adaptor in short order at some of the settings unless you upgrade the heat sinks.
      Why would Intel allow such high power outputs? Well there are licensed wireless networks. They are allowed to use different frequencies and more power than unlicensed. This allows Intel to use the same chip set for both customers.
      But the truth is that Intel isn't just being a big meanie that will not share. There are some real risks involved to Intel if they go against the FCC's wishes. Imagine if the FCC demanded all Centrino notebooks recalled. Or refused the next Intel WiFi chip-set? Those are both worst case but they are possible.
      Intel has gone out of it's way to provide free as in beer drivers for their wifi cards as well as providing the specs for it's graphics cards, wired network adapters, cpus, and goodness knows what else.
      In this case Theo is generating a lot more heat than light which I would say is pretty typical of him. But then nothing I write would ever make the front page of Slashdot twice. I tend to be too reasonable and writing really isn't a talent of mine.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  43. defeatist attitude by iggymanz · · Score: 2, Insightful

    What OpenBSD is doing has worked with other companies. Until someone has hundreds of millions to put into your open source hardware, the OpenBSD's approach has much more likelihood for success useful to other people.

  44. Re:Intel 'Must'??? by Anonymous Coward · · Score: 0

    Intel 'must' do whatever it thinks is best for it's business and shareholders, not what some pissante developers demand it to do.

    Wrong. Intel (or any other company) must do what it can to make more money for the CEO, as long as it is not illegal, or if it is, they don't get caught, or if they do get caught, the penalties are not greater than the rewards. Also, they need to maintain the appearance of maximizing shareholder value. Hope this helps.

  45. Re:Intel Open Source: Never gonna happen by micromuncher · · Score: 1

    Theo the Rat couldn't have written it better!

    But what a pipe dream eh? Sure a bunch of hobbiests in their sheds can come up with some pretty cool designs, and even build some toys, but there is something they cannot do: mass production. Why? Well, take plastic moulding for example. It costs about $500,000 just to set up a non-specialized injection company just to make something as simple as a casing for plug.

    Supply and demand. "The American Dream." All these things would stomp out open source hardware.

    I know of several design tools btw, open source projects, that failed because - hmm - people didn't contribute to them - hmm - because they're so vertical they're effectively useless to the masses - hmm - and that's why open source initiatives - so noble and good willed - will fail because without a broad developer base and even broader consumer base its like putting lipstick on a chicken. [Pointless.]

    --
    /\/\icro/\/\uncher
  46. Re:News at 6 !!! Film at 11 !!! by Anonymous Coward · · Score: 0
    Here's a little gem of diplomacy he posted on the FreeBSD security mailing list a day or so ago.

    Bullshit. Where did anyone say this?

    Why don't you put people in charge who can READ CODE, and SEE THAT
    THIS IS ABSOLUTE BULLSHIT.


    Apparently, he was wrong too, but that's irrelevant (people get things wrong all the time) to his uber-abrasive approach (most people don't behave like arseholes on the list).
  47. Re:News at 6 !!! Film at 11 !!! by Anonymous Coward · · Score: 0

    So Theo is an abrasive cocksucker who is probably only in Open Source because he is unemployable? Well, that could explain his anger issues I guess.

  48. I've never been so insulted in all my life by Rogerborg · · Score: 1

    Well, I have, but not on Slashdot.

    --
    If you were blocking sigs, you wouldn't have to read this.
  49. Re:Theo de blah by Nimrangul · · Score: 1

    Oh, there's a big suprise, the fucktard at Genesi doesn't like OpenBSD? Maybe next time the company could skip being idiots and liers and just give the documentation needed to make OpenBSD run on their hardware, and pay the man who does the work you guys hire him for. One would almost think that Genesi doesn't like OpenBSD for all the bad press there was about the company being run by idiots who hire OpenBSD developers to port to their hardware and then refuse to pay them. But no, that would be stupid, it was their own damned fault.

    Genesi: 8'(

    --
    I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
  50. Re:News at 6 !!! Film at 11 !!! by ThePhilips · · Score: 1

    Conviction at the cash register could positively affect other notorious outfits like ATI and nVidia.

    At least former have stated why they can't go Open Source. And even releasing specs (which are incomplete) would help little: DirectX 7/8/9 which requires special special software from Microsoft in driver.

    Intel on other side always try to push aside Open efforts. Against Open BIOS supported amongst many vendors AMD - it has released EFI. EFI theoretically is also Open Source, but primirily designed to load binary modules from other (e.g. motherboard, BIOS, OEM) vendors. Feel the difference: open source BIOS v. open source stub to load BIOS of binary modules.

    Unlike for CPUs, Intel didn't released a single spec for its networking products: wireless are just hot now, but wired adapters have the same fate. It's just Intel did released open source drivers people consult instead of spec. But again, e100/e1000 are rather exception. Intel also didn't release specs for their on-board graphics and ATA/IDE controllers - some people under NDA updated older open source drivers.

    What I'm trying to say is that wireless drivers are not exception - Intel cares only about big customers (namely servers) and good publicity (namely benchmarks). Small fry (like F/LOSS vendors) is very low priority - ranting on Slashdot are even more down the list.

    --
    All hope abandon ye who enter here.
  51. Re:Theo de blah by NekoXP · · Score: 1

    Nothing wrong with OpenBSD itself. Nice OS.

    Just the guy in charge likes to piss on everything more than anything in the world.

    There is nothing you can do right for Theo, be you Genesi or Jesus himself.

  52. Re:Theo de blah by Anonymous Coward · · Score: 0

    You misunderstand.
    The OpenBSD group expects damn near perfection -- or at least the very best (that's all you can really expect, your best). Theo has his opinions and has probably learned that being nice about him got him NO WHERE. Everyone quickly forgets what OpenBSD does for the FOSS field. They get embarrassed.
    I'm going to direct the next statement at the general FOSS crowd, not your specifically:
    Fucking pussies because you get embarrassed. If you want instable machines, that's your perogative. I, personally, prefer my servers to be rock solid and not have weird shit happen because of blobs or some coder decided to half ass something.

    The difference between Linux and OpenBSD is that Linux wants the popularity of Windows but stay free and have some cool apps. OpenBSD wants to be rock solid and never crash. Sometimes these goals are mutually exclusive. Sometimes they aren't. You choose your life, I'll choose mine. The _only_ time I use Linux is when I'm running something that isn't mission critical. Even then, I go LFS or Gentoo -- Slackware if I want to install it quick.

  53. Re:Theo de blah by NekoXP · · Score: 1

    If I had a choice I'd go NetBSD, not Linux :)

  54. Re:Intel Open Source: Never gonna happen by Penguinoflight · · Score: 1

    You should look into the MegaSquirt (And Spark) independent engine management system. It is basically open source hardware; there are distributors who will sell you a prebuilt system for about $400, or you can get a set of electronics and instructions for about $250. It's a lot of money for a simple computer (and some not so simple sensors), but it's a bargain for an Engine Management system.

    --
    "And we have seen and do testify that the Father sent the Son to be the Savior of the World"
    1 John 4:14
  55. Re:News at 6 !!! Film at 11 !!! by Anonymous Coward · · Score: 0

    Theo is a "jerk" because dotcom being a jerks first. Jerks against consumers and OpenSource-community!