Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Intel Accused of Being an "Open Source Fraud" 153

Posted by ScuttleMonkey from the you-bought-it-now-you-can't-use-it dept.
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"
This discussion has been archived. No new comments can be posted.

Intel Accused of Being an "Open Source Fraud" More

Intel Accused of Being an "Open Source Fraud"

Comments Filter:

  • BSD confirms it (Score:5, Funny)

    by Anonymous Coward on Tuesday October 03, 2006 @05:22AM (#16289165)
    Intel is lying...

  • help intel? (Score:1, Funny)

    by Anonymous Coward
    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.

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

    • Where do you draw the line?? (Score:5, Interesting)

      by EmbeddedJanitor ( 597831 ) on Tuesday October 03, 2006 @05:42AM (#16289243)
      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.

      • Is Java bytecode interpreter or JIT compiler a binary blob?
        • Your analogy doesn't work...A Java interpreter is equivalent to the FPGA, not the program loaded on it.

        • Re: (Score:2)

          by HiThere ( 15173 ) *
          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

      • 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

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

      • Re: (Score:2)

        by raddan ( 519638 )
        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 no

        • Re: (Score:2)

          by sjames ( 1099 )

          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

    • Re:The interface is the product (Score:5, Informative)

      by evilviper ( 135110 ) on Tuesday October 03, 2006 @05:43AM (#16289247) Journal
      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.

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

        Why not leave this on the legal fringes ?

        • Re: (Score:3, Informative)

          by Short Circuit ( 52384 ) *
          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.

      • Re: (Score:3, Interesting)

        by QuantumG ( 50515 )
        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 wh

        • Re: (Score:2)

          by Intron ( 870560 )
          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 do
        • 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...
      • Except it's cheaper to allow softcode firmware updates than continually reflash the hardware for every pointcode revision.
        • 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?

    • Re: (Score:2, Informative)

      by HornyBastard ( 666805 )
      "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.

      • Re: (Score:2, Insightful)

        by BadAnalogyGuy ( 945258 )
        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 a

        • Re: (Score:2)

          by udippel ( 562132 )
          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

    • Re:The interface is the product (Score:5, Informative)

      by IcePic ( 23761 ) on Tuesday October 03, 2006 @05:52AM (#16289307) Homepage
      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.

    • Re: (Score:3, Informative)

      by Anonymous Coward
      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.

      • Re: (Score:2)

        by grahamm ( 8844 )
        Do not forget that IBM published the source code for the BIOS in the orginal IBM PC technical manual.

    • Re: (Score:2)

      by Burz ( 138833 )
      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.
    • Comment removed based on user account deletion

      • Re: (Score:2)

        by Dan Ost ( 415913 )
        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.
    • 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?

    • Re: (Score:2)

      by LWATCDR ( 28044 )
      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

    • Re: (Score:2)

      by HiThere ( 15173 ) *
      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

  • OpenBSD and the UN (Score:3, Funny)

    by OeLeWaPpErKe ( 412765 ) on Tuesday October 03, 2006 @06:28AM (#16289463) Homepage
    do !

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

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

  • As good a time as any to revisit UDI. (Score:3, Insightful)

    by Burz ( 138833 ) on Tuesday October 03, 2006 @06:32AM (#16289491) Homepage Journal
    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.
    • http://lwn.net/1998/0924/ [lwn.net]

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

    • Re: (Score:3, Interesting)

      by Wesley Felter ( 138342 )
      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.
    • 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 v
  • 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 ;-).

    • Re: (Score:2)

      by Sancho ( 17056 )
      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 h

  • RTFA, etc... (Score:5, Informative)

    by Schraegstrichpunkt ( 931443 ) on Tuesday October 03, 2006 @06:56AM (#16289605) Homepage
    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.

  • Tasty kernels (Score:2, Funny)

    by Orp ( 6583 )
    A new slashdot record - the *first word* of an article summary is misspelled! Congratulations!
  • 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?

    • Re: (Score:3, Interesting)

      by LurkerXXX ( 667952 )
      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.

  • Intel is being unreasonable (Score:2, Insightful)

    by Anonymous Coward
    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 [sourceforge.net]

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

  • 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

  • Ha-Ha morons (Score:2, Funny)

    by unity100 ( 970058 )
    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

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

    • defeatist attitude (Score:3, Insightful)

      by iggymanz ( 596061 )
      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.
    • 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
      • 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.
  • ...does this mean a firmware blob can be decompiled and redistributed that way?
  • 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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close