Slashdot Mirror


OpenBSD Activism Shows Drivers Can Be Freed

grey writes "The Age has a story up about how the OpenBSD community has been contacting wireless chipset vendors to license their firmware binaries under terms that would allow for free redistribution. This is important, because even with existing GPL and BSD licensed drivers for these chipsets, the drivers don't function without first loading onerously licensed firmware binaries which can only be acquired from the vendor, not shipped by an OSS provider." (Read more, below.)

grey continues "This means that currently, these wireless NIC's don't work out of the box on OSS install or boot media. In just the first 4 days, hundreds of users wrote and called vendors, and already 2 vendors freed their firmware, and several others are in discussions with Theo de Raadt about taking similar steps.

We need your help! TI has still not responded at all. You can call or write to Bill Carney, - Director of Business Development of TI's WNBU to add to the approximately 400 well written messages the OpenBSD community has already sent to TI. We hope that you'll help, and if you do please keep messages polite and to the point. Please remember, we are not asking for the vendors to open source their firmware under the GPL or BSD licenses (though we wouldn't complain if they did). Instead, ask if they would simply email Theo to open discussions on licensing their firmware binaries under terms that allow for free redistribution. If changed, these firmware binaries would then be able to be included with OSS software and function with existing BSD and GPL licensed device drivers from the start.

You can find other contacts for target vendors here, here, here, and here, and it can't hurt to sign this petition. These changes aide all OSS efforts, not just OpenBSD. As you can see from the OpenBSD community's results already, contacting these vendors really does make a difference. We're sure that with the numbers of OSS minded readers in the Slashdot community you can really help with the heavy lifting where fewer numbers of BSD users have already begun to succeed, and all Open Source Software users will benefit."

55 of 213 comments (clear)

  1. If you love your driver by Anonymous Coward · · Score: 4, Funny

    You must set it free.

    1. Re:If you love your driver by mav[LAG] · · Score: 2, Insightful

      If it comes back to you, it's yours :)

      --
      --- Hot Shot City is particularly good.
  2. Bahh by Anonymous Coward · · Score: 2, Funny

    Bahh. What about when we have cases of driver hooks being yanked from the kernel simly because of inflated egos? (I.e. PWC/PWCX)

    1. Re:Bahh by erikharrison · · Score: 3, Insightful

      Then you have a seperate issue, with a seperate OS, with a seperate developer, with a different kind of hardware.

      PWC hooks in the Linux kernel were hooks that were removed as part of a standard kernel policy, after the driver had fallen under the radar for some time, and that hook was specifically designed to extend the capabilities of working hardware in a way which was legally fishy.

      This is the issue of going to a vendor for the licence to redistribute firmware which already has a generic kernel hook for being loaded and will not initialize with said firmware.

      Or are you just being crabby?

    2. Re:Bahh by ComputerSlicer23 · · Score: 4, Insightful
      Oddly enough, what this is doing, is precisely the way that the PWC/PWCX should be handled. He could have easily started shipping a module that was compiled out of tree, or as a patch, then no GPL violations happened (if you compile your own and don't distribute, there's literally nothing that is illegal you can do, it's only at the point that you distribute binaries that you get into trouble). He could have designed the other module to merely hook into it if it was loaded as opposed to designing it to require a function pointer. That was where it all went so badly wrong. If the binary only module was loaded inplace of the GPL'ed version it would have been fine. The problem was that the GPL'ed one was runtime linking to non-GPL'ed code. The code he was putting into the binary only version was clearly developed independently of Linux in the same fashion that the NVidia driver was (it was used in a different OS first, and it used essetially the same interface to the kernel as userspace does, thus passing Linus's criteria for not being a derived work).

      The problem was that there was a hook there that had the sole purpose of explicitly violating the GPL. Here, the firmware isn't linking with the GPL'ed code. So it's all good. This is uploading firmware from userspace via the kernel. Requiring it to be GPL'ed is like requiring that the files I read and write be GPL'ed because they passed thru the kernel.

      The firmware loading is there to resolve several pseudo GPL violations (I believe Adaptec has long strings of stuff that is a binary code that gets loaded into the firmware that people claim "we should have the source"). I've always held the believe that that code is not linking with the GPL'ed code, it is merely data as far as the kernel is concerned (you don't have to GPL the constants you use in drivers). While the firmware is intersting and it's plausible that OSS could improve it, it just saves the costs of burning a ROM in case there are bugs that have to be fixed.

      This all came up not that long ago and was a possibly blocking problem with the next debian release, but they choose to overlook the problem. The firmware loading is clever because it solves several problems, and is more flexible, and moves the problem outside of the kernel, and turns it into a data problem, not a code problem.

      Kirby

    3. Re:Bahh by DragonHawk · · Score: 2, Funny

      "Requiring it to be GPL'ed is like requiring that the files I read and write be GPL'ed because they passed thru the kernel."

      Don't give RMS any ideas.

      (I'm kidding, I'm kidding. I actually think the concept of copyleft is a Good Thing. But I take the shot when I see it.)

      --

      dragonhawk@iname.microsoft.com
      I do not like Microsoft. Remove them from my email address.
    4. Re:Bahh by CoolVibe · · Score: 2, Interesting
      A little bit offtopic to this thread, but I feel I need to say it anyway:

      I have to say that the NVIDIA guys are way more relaxed than say intel or broadcom. I'll give you an example: I contribute to the DragonFlyBSD project. NVIDIA found out that I have been porting the FreeBSD X11 NVIDIA driver to DFBSD. They contacted me, and after some pleasant communication, they sent me a prerelease driver for me to port. But that just started things rolling, because I passed on the contact details to Joerg Sonneberger, and he managed to get the nvidia ethernet binary object relicensed so it could be included in our base install.

      This just shows that it can be done.

  3. Why NOT? by TexasDex · · Score: 5, Insightful
    Really. I never understood the reason for such restrictive licenses on drivers. I could distribute the drivers far and wide, but without buying the company's hardware (read: paying them money) they are really really useless.

    So why do companies have a problem with free driver distribution?

    --
    The Cheese Stands Alone.
    1. Re:Why NOT? by MBCook · · Score: 2, Insightful
      Here is my guess, as always, IANALBIPOOSD (IANAL but I play one on /.).

      Legal stuff always tries to reserve as many rights as possible for the company, so when they came up with the license for the drivers they came up with a license that gave almost no rights to people (as licenses usually seem to do). And that's the way it's been for a long time because, untill now, no one needed that ability. I mean other than with OSS (IE in the Windows, DOS, or Mac worlds) what reasons would anyone have for wanting to be able to distribute a tiny part of a driver (the firmware) without the rest of the driver for free? The only times I ever saw drivers given out (other than with hardware) was on CDs that game with magazines (so you could get the lastest that way) but then they include the full driver anyway.

      Basically, no one cared before now, so there was no reason to give it to people. Now people want it, and I see no reason why there shouldn't give it up (it's not like we're asking to have it open sourced or the rights to dissassemble it or anything).

      --
      Comment forecast: Bits of genius surrounded by a sea of mediocrity.
    2. Re:Why NOT? by Coneasfast · · Score: 4, Insightful

      They don't want you getting a driver from some shady site that put a virus in it, and thus giving their company a bad name (at least for dumb-computer-users).

      1) most people should know to download drivers from the computer manufacturer / device manufacturer. and if someone wanted to do that, they could without having the source code, just have to put a virus in the installer or reverse engineer the code.

      2) i don't think this is the issue here, look how many drivers are in the BSD/linux source code, has this really become a problem? no. will it ever? probably not.

      --
      Marge, get me your address book, 4 beers, and my conversation hat.
    3. Re:Why NOT? by cmowire · · Score: 5, Insightful
      A variety of reasons, and there's probably a bunch more that I'm not aware of:
      • Legal counsel decides it's a bad idea because it could expose them to liability
      • It really does expose them to liability. For example, you could exceed FCC restrictions on the ISM bands by programming your card to emit more power than it should on frequencies it's not allowed in the US to be in.
      • They are selling the same hardware as three different products with only the drivers different.
      • You could make a linux-based device cheaper than their stand-alone equivelent.
      • There are bits of licensed code in the driver that aren't theirs to give out.
      • They are using a reference design and the driver contains features unique to their product. If they let the driver out, people will be able to buy the cheaper implementation of the same reference design and get those features.
    4. Re:Why NOT? by networkBoy · · Score: 2, Insightful

      I think the real concern of the companies is that often drivers contain lots of information about the architecture of the hardware, that if it were to fall into "enemy hands" would compromise valuable IP assets that are likely trade secrete rather than patented.
      I know this to be the case where I work.
      -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:Why NOT? by LiquidCoooled · · Score: 3, Informative

      But thats the whole point. By including the drivers in the operating system distrobution, you can ensure hardware is at least usable at plug in time WITHOUT having to go onto some dodgy site.

      --
      liqbase :: faster than paper
    6. Re:Why NOT? by SydShamino · · Score: 5, Insightful

      Dude, note that this is for FIRMWARE, not drivers. Big difference.

      Hardware used to do things using discrete transistors, resistors, diodes, etc. These days most of that (and more) can be done better in high-density logic devices. But the "top of the line" high density logic, ASICs, still have too great a startup cost for many companies. Plus, they cannot be field upgraded.

      The next best logic, FPGAs, are not hard-coded with the firmware. Instead, they load it from a memory source on the hardware - or they load it from the operating system on boot or plug-in. The advantage of the latter is that you don't have to pay for the EEPROM or flash to store the firmware on board, and updating the firmware is as simple as downloading a new binary to your computer. (Overwriting EEPROM or flash firmware on hardware can be dangerous, as a failure could prevent the hardware from being recognized to try again.)

      So, firmware (i.e. code for the hardware) ships with the software driver, but is separate from it. Your next question will be: Why don't they open-source their firmware, too?

      And the answer here is simple. They have to pay someone to design that firmware, lay out the PCB, spec in parts and materials, and then provide hardware to build those units. If their firmware is available to all, then someone else can take that code, copy their PCB, and produce the exact same board except with no overhead of R&D. Heck, they could even provide (under the table) vendor and device information so that it looked exactly like the primary company's product, would work with their driver, etc.

      Why would any company want to do that? One of the early competitors of my company, 15 years or so ago when we used TTL parts, copied the entire product exactly. Reverse engineered the PCB. Then ran advertisements showing the two boards side-by-side, explaining how they were identical except that theirs cost less because they have no research overhead.

      So, of course, my company leveraged its research "overhead" to produce a better, faster product that also happened to not be so easily copied. This resulted in our first ASIC. There is no way that we or most other existing hardware companies would return to the days where anyone can copy their products.

      --
      It doesn't hurt to be nice.
    7. Re:Why NOT? by technoid_ · · Score: 3, Insightful

      Because we all know the competition could never go out and buy the product and get the driver from the included CD, or just download it from the manufacturer's site.

      The consumer might as well be considered enemy hands.

      --
      Two wrongs don't make a right, but 3 lefts do - Lew of GO magazine
    8. Re:Why NOT? by lawpoop · · Score: 2, Insightful
      Also:
      • They are using unlicensed code, i.e. code that they shouldn't.
      --
      Computers are useless. They can only give you answers.
      -- Pablo Picasso
    9. Re:Why NOT? by amorsen · · Score: 3, Informative

      This article isn't about drivers. It is about firmware.

      --
      Finally! A year of moderation! Ready for 2019?
    10. Re:Why NOT? by PitaBred · · Score: 3, Informative

      I agreed with this until the 4th paragraph. NVidia can't open their drivers because they have code in it licensed from other people whose IP they use. It's that simple. The actual architecture for the driver is relatively easy to discern if you look at their distribution, the only thing that's hidden is the code that actually talks to the board.

      These other drivers are hidden because companies have just always done it that way. Why should they change things? It's always worked before. They don't realize that the community will help them greatly if they open things up a bit. It's old-world versus new-world, and it's just taking some time to get old-world to come around.

    11. Re:Why NOT? by Anonymous Coward · · Score: 2, Interesting
      1) most people should know to download drivers from the computer manufacturer / device manufacturer. and if someone wanted to do that, they could without having the source code, just have to put a virus in the installer or reverse engineer the code.

      I'm not disagreeing with things here, but that's not always the way people do it, at least with Windows.

      I have seen this first hand. The not-very-enlightened of the Windows world, when they "need a driver" (even if the hardware is already working) go to google and usually type "driver [hardware name]" or "find my driver for my sound card".

      This then gives them a wonderful list of web sites which are NOT the manufacturer, and have drivers that undoubtedly are of questionable origin. I've even seen them install software (spyware) which even said it wasn't the driver, but if they installed it *it* would find the driver for them. Spyware makers are some sneaky pricks.

    12. Re:Why NOT? by Anonymous Coward · · Score: 5, Insightful

      Dude, this article is about -licensing- the firmware in such a way that it can be shipped by OSS vendors - NOT about Open Sourcing it (quote: "Please remember, we are not asking for the vendors to open source their firmware under the GPL or BSD licenses"). Stop trying to answer a question no one was asking, you're either making yourself look foolish or intentionally misleading people when you do such things.

      Anyone who wanted to reverse engineer the firmware would have just as tough a time doing it _now_ as they would if the firmware was able to be shipped on a knoppix or OpenBSD CD instead of downloading it from a website with an Intel licensing splash page.

      You have some worthwhile points and you explain the distinction between drivers and firmware well, but your argument and company's experience is not relevant in this instance. Getting companies like TI and Intel to license their firmware in a way that allows for other vendors to provide it out of the box is just going to help users - other companies which might be helped or hindered by open sourced firmware will be completely unaffected, because the challenge will remain the same as it is now.

      Let's take that intellect and argumentative skills and point it at contacts for TI and intel instead of veering off course.

    13. Re:Why NOT? by Bastian · · Score: 4, Insightful

      While I agree that most of those are good reasons, I must say that I think that something is terribly wrong with the legal system if the vendor can be liable for my intentional misuse of their product.

      I envision a similar situation in which Detroit gets sued because they are liable for a person's speeding ticket. Only the person had to override some sort of speed limiter device in order to do it.

    14. Re:Why NOT? by RedLeg · · Score: 5, Informative
      So why do companies have a problem with free driver distribution?

      A: In the case of wireless, the FCC plays a part.

      An 802.11 Wireless Card is a software controlled radio, and must be licensed per FCC regs (in the USA, your country's rules might be different). Since the 802.11 PHY operates over several channels within the specified band, it must be able to select and switch between these channels via software, and to adjust its transmit power for optimum performance based on the changes in temperature of the transmitter, and changes in the frequency, among other things.

      But different regulatory domains (countries) allow different channels within the bands, meaning a card in the US may be able to operate on a channel in the B band which is not licensed for another country, or vice versa. This is particularly true in the A band, where a whole middle "chunk" is not legal for use in the US.

      Bottom line is that in order for the producer to get a license for the radio (and trust me, you do NOT want it to be the case that you, the operator, have to secure that license), he is NOT ALLOWED to expose the controls for power, et al, to the end user.

      Now, if the driver / firmware (distinction / similarity discussed elsewhere in the thread) is open source, then by definition the controls in question are exposed to the end user. There would be nothing to prevent an end user from operating his card at a higher than legal power, or outside the legal freqs for the local regulatory domain.

      NOW, all that being said, that is not to say that SOME hardware manufacturers haven't tried to do the right thing, and strike a compromise.

      The MAD-WiFi Project http://sourceforge.net/projects/madwifi, (FAQ here) produces an open driver for the cards with Atheros chipsets. The bulk of the code is open, and under a good license. To meet the FCC requirements, they implement the "required to be secret" controls in a binary-only Hardware Abstraction Layer (HAL), but the rest of the code is open, free for you to read and modify.

      And it works. I'm typing this through a Netgear card, running the MAD-WiFi driver (with TKIP encryption, IEEE 802.11i 4-way handshake and authentication handled by wpa_supplicant) on Gentoo Linux.

      Credit is due to Sam Lefler and most importantly to Greg Chesson (of Atheros). Yes, it's that Greg Chesson, the same one mentioned of late by Rob Pike in his recent ./ interview.

      Note that, AFAICT, all of this happened without Theo de Raadt pimping around or making an ass of himself, as he is want to do. Disclaimer: I lost patience with Theo and TheoBSD a long time ago.

    15. Re:Why NOT? by Chandon+Seldon · · Score: 4, Informative

      Remember:

      Bittorrent is no different than, say, HTTP when it comes to this sort of thing.

      If you're bittorrenting down a ISO from, say, the Knoppix official tracker - You know it's fine - same as if you downloaded it by HTTP from the same site.

      Now if you're randomly downloading stuff from Hack-My-Computer.com, that's a different issue.

      --
      -- The act of censorship is always worse than whatever is being censored. Always.
    16. Re:Why NOT? by metlin · · Score: 2, Insightful

      Excellent point.

      But that's why you have checksums and digital signatures.

    17. Re:Why NOT? by ciph3rBSD · · Score: 2, Informative

      OpenBSD has just imported a FREE driver for Atheros card reverse engineered without the HAL stuff ;)

    18. Re:Why NOT? by ciph3rBSD · · Score: 2, Informative

      OpenBSD has just imported a FREE driver for Atheros card reverse engineered without the HAL stuff ;) ------- CVSROOT: /cvs Module name: src Changes by: reyk@cvs.openbsd.org 2004/11/01 20:01:16 Added files: sys/dev/ic : ar5xxx.c ar5xxx.h ar5210.c ar5210reg.h ar5210var.h Log message: import of a free hal part for the ath driver as a replacement for the binary-only hal module found in FreeBSD and NetBSD. OpenBSD's approach is based on reverse engineering because it is _not_ possible to include a non-free and binary-only piece of software in a 100% free operating system. it still lacks some features found in the "official" hal module but this will be done very soon with a help by a lot of contributors - because it's free. ok deraadt@

    19. Re:Why NOT? by codguy · · Score: 3, Informative

      [radio static on]Hello RedLeg, are you there??? Come in, Redleg...[radio static off]

      OpenBSD (and others) simply want to be able to freely distribute the firmware with OpenBSD (or other OSS) freely.

      The request is *not* to open up the firmware like your message suggests. Again, since you missed it the first time, the request is *not* to open up the firmware like your message suggests.

      Maybe the average slashdot reader does not have a long enough attention span to follow such logic through, but this is honestly important not to just OpenBSD, but all OSS in general.

      --codguy

    20. Re:Why NOT? by halligas · · Score: 2, Insightful

      Legal counsel decides it's a bad idea because it could expose them to liability
      Not true, they are already giving this firmware out with the cards, it is just on a cd and can only be installed from Windows. OBSD is merely asking for the ability to package the firmware with their distro.

      It really does expose them to liability. For example, you could exceed FCC restrictions on the ISM bands by programming your card to emit more power than it should on frequencies it's not allowed in the US to be in.
      Not true, FCC regs do not apply to the manufacturer, they apply to the user.

      There are bits of licensed code in the driver that aren't theirs to give out.
      OBSD is not asking for the source to be opened. Read the article again. The binary firmware blob, which is already on the CD (but with a onerous re-distribution license) is what is being discussed here. No one cares what the code in the firmware looks like, we just want to be free to give the blob away.

      They are using a reference design and the driver contains features unique to their product. If they let the driver out, people will be able to buy the cheaper implementation of the same reference design and get those features.
      Again, read the article, the drivers already exist in OSS. The drivers are no good if you can't load the firmware binary.

      No one is asking anyone here to open source any code. We just want these vendors to remove restrictions on redistribution of the BINARY firmware (that they themselves already give away).

  4. Salient point: by Sheetrock · · Score: 2, Interesting
    Why settle for binary only?

    Particularly where OpenBSD is concerned, where every inch of the code has been scrutinized for security holes, encouraging the use and distribution of binary-only drivers sounds like a quick way to lose the status of never having a security hole in the installation. There's got to be a hardware manufacturer that's willing to release source (though the hardware might cost a little more).

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




    1. Re:Salient point: by gl4ss · · Score: 4, Insightful

      *Why settle for binary only?*

      because it's doable and reasonable, and most importantly something that the vendors could agree to.

      (they don't really lose anything if they allow the binary versions to be distributed along the os's, all they lose is that people won't dl the files from them directly)

      --
      world was created 5 seconds before this post as it is.
    2. Re:Salient point: by downbad · · Score: 3, Informative

      firmware, not drivers. :)

  5. Comment removed by account_deleted · · Score: 3, Insightful

    Comment removed based on user account deletion

  6. Free distribution = Free by jmulvey · · Score: 3, Interesting

    Until an open source hardware manufacturer is sprouted, I can't understand why any for-profit company would license the most difficult part of their design for "free distribution".

    I mean, if they licensed it for free distribution, what would prevent some half-baked Chinese knock off from mass producing the wireless chipset reference design, burning the for-profit's "free" firmware, and selling for a huge profit?

    Please sir, if you'd only give me the keys to the kingdom.

  7. Theo by CaptainPinko · · Score: 4, Interesting
    People have criticised Theo for being agressive and less than baby-ass smooth --hell he got booted from NetBSD for it-- but he's gotten results first with the quality of OpenBSD and now with this. I think he has earned the right be hostile if he wants to- it works.

    I wonder if Linus could do something similar to get ATI and NVidia to open up...

    --
    Your CPU is not doing anything else, at least do something.
    1. Re:Theo by __aaahtg7394 · · Score: 2, Informative

      ATI and NVidia are, by the twisted logic you're using, already more open than this! They ship full drivers with source code for ABI compatibility layers. Theo didn't get them to open up at all, all he got was a license for free redistribution of a chunk of data they hadn't previously allowed distributed.

  8. what's with 'related links' ? by ch-chuck · · Score: 4, Funny

    comparison shop for 'your rights online' ? wtf???

    That's like the old Lycos at one time put in this automated advertising thing, so you search for libstdc++-devel-3.2.2-5 and it comes back with "Find bargains on libstdc++-devel-3.2.2-5 at Amazon.com!", "See what people are saying about libstdc++-devel-3.2.2-5 on movietalk.com!"

    --
    try { do() || do_not(); } catch (JediException err) { yoda(err); }
    1. Re:what's with 'related links' ? by Anonymous Coward · · Score: 2, Funny

      it was even worse when you tried some not-ver-politicaly-correct-isms.

      Find great bargains on black people at amazon.com!

      Read reviews from people who bought black people at cnet.com!

      Automation is a good thing.. it reminds us (daily) why people should not and can not be replaced by computers.

  9. firmware are not the crown jewels by Anonymous Coward · · Score: 5, Informative

    The hardware -design- is the "keys to the kingdom" not the firmware, and they're not even asking for the firmware binaries to be open sourced - merely licensed so that they can be distributed freely by OSS vendors. Feels like I'm just quoting the article here, so I guess you might need to reread it more carefully.

    If you've dealt with traditional firmware it's called "firm" because it's usually written to a flash memory of some sort on the device (be it CD Burner, NIC, etc.) in this case these vendors are cheaping out on an inexpensive piece of flash memory, and instead designing the 'firmware' to be loaded by the driver, thus unless the driver loads it each time the computer is turned on, then it disappears, it is not static. As such, it makes the hardware utterly useless unless you not only have a device driver, but also this firmware binary loaded. If they had spend a few cents extra and invested in a flash chip that moved with the hardware, this wouldn't be an issue. Instead, they've turned a hardware design issue into a software problem, and if they don't allow for that firmware blob to be redistributed with software drivers (be they proprietary or otherwise) from other vendors - the hardware is useless.

    Rather than making a strawman argument about this issue which you didn't take the time to fully understand despite the large amount of text and background links in the story, it would really help everyone if people would write the vendors in question and ask for them to make a minor change. No one is asking them to open their designs a la opencores.org, merely license their firmware blobs in such a way that the firmware can be shipped with other Operating systems that -already- have OSS drivers.

    (Going to write and call now instead of waste more breath on slashdot responses)

    1. Re:firmware are not the crown jewels by xsbellx · · Score: 2, Funny

      My God man, this is Slash Dot!

      We just cannot allow you to read the article, understand it AND post an eloquent, on-topic response. Please stop this nonsense!

      In all seriousness sir/madam, GREAT response!

      --
      If VISTA is the answer, you didn't understand the question
  10. is it just me.... by revery · · Score: 2, Informative

    or has BSD been getting a heck of a lot of stories on the main page lately

    It's like they haven't been listening to the trolls at all

    --

    I write stuff, but not that well and not that often...

  11. This is what I'm gonna do. by Anonymous Coward · · Score: 5, Interesting

    First; Write your letter to the hardware company.
    Second; Sign the above mentioned petition.
    Third; Only buy hardware from companies that are OSS friendly, that make good products for which they do not rely on disabling the expensive features in software.
    Forth; Send a(nother) letter to the hardware company that makes the devices that you would have preferred to buy, and tell them why you didn't buy it.

  12. Slashdot - force for harassment by gorim · · Score: 3, Insightful


    Its really nice that people who run slashdot themselves now encourage corporate harassment and activist measures by posting people's names and email addresses.

    Whats next ? Posting email addresses of likely Presidental voters to get them to switch to Slashdot's favored candidate ?

  13. What the hell were they thinking?! by FyRE666 · · Score: 5, Funny

    Honestly, why would someone submit this to Slashdot? I mean, they've managed to submit hundreds of "well written" messages to vendors, and now they're about to fuck it all up by encouraging the illiterate, and largely uninformed masses here to send in their own special brands of wisdom.... Then there's the goatse fans, tubgirl gang, "BSD is dying" trolls and other shining stars of the forum just waiting to get in on the fun... ... oh well, it could have worked ;-)

  14. More Companies Are Needed by ssimontis · · Score: 2, Interesting

    This is great. I hope several companies agree. It will be hard to get Linksys to agree, if they try. Linksys will not do anything about it. I have written to them three times about it, and gotten bullshit each time saying that they might be working on drivers for other OSes. The more companies we get the better. Wireless support is the only issue stopping me from using BSD or Linux.

    --
    Scott Simontis
  15. "You have 1,000,000 new messages" by IgD · · Score: 4, Funny

    Here is the reply I got when e-mailing him:

    "This is an automatic reply.
    I will be away from the office on business in Europe from 12n Monday 11/1 through Friday 11/5. During this time, there may be a delay responding to your email. /b"

    I wonder what his expression will be on Monday when he checks his e-mail...

  16. Firmware is not drivers by iabervon · · Score: 4, Informative

    This is about firmware, which is code which gets sent to the device and helps the device work. These are not drivers, which you run on your processor. Typically, firmware is written either for some weird variant of C, or for a completely non-sequential language (for FPGAs). You'd probably have a really hard time compiling it if you had the source. One set of firmware I know of only builds with a particular non-current version of a $10K/seat commercial compiler; this isn't unusual. Furthermore, they're often signed, if only to keep people from messing up their hardware by loading a broken version into it.

    In any case, these aren't programs for your computer, and it is merely a matter of convenience that they aren't sealed into the device at the factory (so you can update them without sending the device back). It doesn't make any more sense to want the source for the firmware for your NIC than it would be to ask for the source to the firmware for your microwave.

    Previously, the firmware was only available from the manufacturers directly, and licensed such that you weren't supposed to redistribute it. OpenBSD people complained that making people go online to update their NIC so that it works is a bit annoying, and that they'd like to be able to get it from OpenBSD, whose CD they would be getting and who would be happy to download the firmware for them.

    1. Re:Firmware is not drivers by drfreak · · Score: 2, Insightful

      These are not drivers, which you run on your processor.

      True, but the firmware is still needed in order for the driver to do it's job. The issue is not about the public having access to firmware source code, the issue is that these developers need to be able to re-distribute the firmware binaries in order for their drivers to work "out of the box." From what I can see in reading the emails, these licenses are too restrictive for the developers to feel safe in re-distributing them. One of the replies I read from Intel seemed like it was saying they do not mind redistribution, but interpreted the letter sent to them as a plea to change the binary license to be compatible with BSD. I think if there was more communication and less threats against the use of this hardware, a lot more might get done. For the above example, maybe just asking for clarification in writing about permission to re-distribute the firmare binaries would solve the problem?

      This reminds me of the majority of distributions that refuse to bundle proprietary video card drivers with their CDs because they do not think they can. Both NVidia and ATI have no problem with the re-distribution of their drivers. NVidia even gives the option of repackaging the driver already compiled for your own custom kernel, and gives a command-line option for their .run installer to do so.

      Is there not a happy medium we can reach here? Do we absolutely need to be balking at licenses that allow us to integrate these products in our distributions just because they do not allow us to make modifications?

    2. Re:Firmware is not drivers by iabervon · · Score: 2, Interesting

      There is some concern about the issues involved with turning the binary firmware blob into a string constant in a C file to be compiled into the kernel image so that it is accessible to the driver before there is a filesystem. Having a license to distribute a file is different from having a license to distribute a program that, without any input, outputs the file.

      Of course, you get into awkward circumstances here. What if your program messes up and fails to output the file exactly as it was supposed to? You now have a program that outputs a modified version of the file. Of course, you'd want to fix it so the device would work, but OSS developers don't want to be responsible for copyright violation if their code misbehaves.

      So they want to be legally permitted to distribute non-working modifications to the firmware (just in case), although they don't care about having any way of making useful modifications to the firmware as sent to the device.

      Probably the best thing is for the manufacturers to encrypt the firmware, and have the device decrypt and check it, and let people do whatever they want with the binary (because they won't be able to do anything useful other than send it to the device). Or, alternatively, let people mess with the firmware however they want, so long as they don't mind not having any source for it.

      Of course, I think the standard practice in Linux is to distribute the original file and a program to convert it into a C file to be compiled into the driver, steps which are no less legitimate than converting it into PCI bus transfers. Then it is simply embedded in the kernel binary in much the same way that it was embedded in the filesystem.

      I think Linux at some point included some C files of firmware, which were determined not to be properly licensed and were removed in favor of only distributing untranslated firmware files.

  17. Don't help distribute problems. by jbn-o · · Score: 2, Insightful

    They don't want you getting a driver from some shady site that put a virus in it, and thus giving their company a bad name (at least for dumb-computer-users).

    Licensing to disallow distribution of proprietary software doesn't prevent this from occurring, whether the software is "firmware" or an "operating system".

    All that is gained with this petition is the ability to help an proprietor more efficiently distribute their non-free software. Users still have no idea what that software will do in the future or how it works now. Users don't gain the ability to fix it when it breaks or improve it to make it do something better.

    The proponents of this petition and letter-writing drive are clear in their intent: they are stressing popularity over software freedom; their users are gaining the ability to help their neighbor more conveniently lose their software freedom. In a way, it is ironic that this plea to become proprietary software distributors is championed by those who criticize the strong copyleft in the GNU GPL (which the OpenBSD folks are known to do, putting in time to replacing GNU GPL-covered programs with new BSD-licensed replacements).

    It's no accident that this call for increased popularity and out-of-the-box utility is being done in the name of "open source". That movement pushes aside software freedom in pursuit of a message to make businesses feel more comfortable. For the open source movement, proprietary software is merely a less technically efficient way of speaking to businesses. Popularity, to them, is more valuable than software freedom. And that's a shame because history teaches that popularity won't get users freedom. Proprietors are chiefly looking to sell users software which denies users their freedom. Proprietors want to treat users as a market, not contribute to the free software community. The open source philosophy makes this more politically feasible.

    From the essay:

    The main argument for the term ``open source software'' is that ``free software'' makes some people uneasy. That's true: talking about freedom, about ethical issues, about responsibilities as well as convenience, is asking people to think about things they might rather ignore. This can trigger discomfort, and some people may reject the idea for that. It does not follow that society would be better off if we stop talking about these things.

    I realize that not being able to use the latest hardware is inconvenient. But one's software freedom should not take a back seat to convenience.

    1. Re:Don't help distribute problems. by Flower · · Score: 2, Informative
      The issue isn't the driver. The driver already exists. It's already open. If you had bothered to get an understanding of the issue you'd realize the problem is the firmware for the device. These companies, in an effort to save money, don't put the firmware directly on the card. They have the driver load it. If the vendor hadn't gone the cheap route this issue wouldn't exist because the firmware would be directly on the card and the free driver would just work.

      What Theo and the community want is the right to distribute the firmware with the driver so it works right out of the install. There isn't anything wrong with this.

      --
      I don't want knowledge. I want certainty. - Law, David Bowie
    2. Re:Don't help distribute problems. by ComputerSlicer23 · · Score: 4, Interesting
      More importantly, the location of the software and how it is installed in the device is a red herring

      Well, that's an interesting point. However, in this case, the firmware could effectively be in silicon. It's just easier to make it not be in silicon. Do you ask Intel for the rights to their Microcode? Intel/AMD CPU's (that's pretty much definitely hardware), have microcode patches.

      Do you demand Transmeta software. Their CPU is a big software translation engine, but they burn their software into a piece of silicon because it executes faster.

      Do you ask Intel for the plans to their CPU so you can use the Free Software concepts to fix up their CPU designs? They are nothing but big pieces of software that are turned into hardware by a very precise etch-a-sketch.

      The problem is that hardware is software, and software is hardware. Especially at the level of firmware. If it's programming an FPGA, that's literally hardware that is changeable. You are configuring a bunch of AND and OR gates. If it's running an ARM, you might have a development environment.

      However, if it's say the Adaptec SCSI firmware, you have a non-standard instruction set, with non-documented hardware. A non-existant tool chain. What do you want the source for? The only reason they do things in firmware, is so they can avoid soldering wires, flashing the PROM, or forcing you to physically pull the ROM and replace it if they find a problem. If they document it's behaviour and say "avoid that", it effectively becomes a hardware problem, the same as if they burned it to silicon.

      Open Source is a fairly practical solution to an Engineering problem. It's applying the age old solution of scientific peer review to the world of software. The freedom is incidental, but most of the original great science was fairly publicly available. At the level you are talking about, you are beginning to approach, "Well, is it a wave, or is a particle", when discussing "is it software, or is it hardware". I mean the CPU is flash upgradeable, and I'd say the CPU is about as hardware like as hardware gets.

      I agree that most of the time, all software should be open. However, in the case of the firmware, I think several different issues come up. Not the least of which are, you'll need the vendor to open the docs on the specifications of the hardware internals (this works at a lower layer then the driver does). You'll needs a tool chain for an assembler that might literally be a one-off designed in house by a hardware engineer. At some point, they'll be a layer of software, that until there is an open hardware maker that will be inheriently propritary (documenting the firmware properly essentially draws a blueprint for the hardware). The economics of the situation make no sense for the hardware makers to make it public knowledge. I'm not saying it's a good thing, but economics makes the computer world go around. The economics of hardware is what made writting software a possibility for so many of us. To blindly ignore them is naive. I wish that there was more open hardware that was actually made and sold as high quality equipment. I know I'd pay a premium for it to get hardware that was open all the way down to the traces on the board level.

      Kirby

    3. Re:Don't help distribute problems. by codguy · · Score: 2, Insightful

      However, in the case of the firmware, I think several different issues come up

      No, no, no--this whole argument is irrelevant because this is not what is being requested.

      They are only requesting the ability to freely distribute the firmware with OpenBSD and other OSS. They are not asking that the hard-/firm-/software be opened for use by OSS.

      Most hardware manufacturers allow Microsoft to freely distribute basic driver software for their products. Does it seem unreasonable that OSS should not be able to distribute they same type of stuff?

      Does Microsoft require that hardware manufacturers open the code to them in order for it to be included in Windows? No. And this is the same with OpenBSD's request efforts. They are not requesting that the code be opened, they simply want to be able to distribute it so when you load their distro (or any OSS distro) your hardware will be functional immediately instead of having to go to a website to download it.

      This would eliminate many chicken-or-the-egg first problems. For a user that only has wireless connectivity, how will they be able to get to a website to download software if their dumb wireless NIC is brain-dead on arrival because of this firmware load-on-the-fly technique? Yeah, of course there are many solutions, but the simplest one would be to have the firmware freely distributable so it could be included along with any distro.

      Loosely speaking, the firmware in question is already freely available--you just go to the website and download it. So the request to simply include it (no reverse engineering, no open source code, etc.) along with an OSS distro doesn't seem outlandish at least to me.

      For those who think this only affects OpenBSD, you have quite shallow foresight.

      --codguy

  18. Theo's rewriting history on this one. by kkkelley · · Score: 3, Interesting

    I worked for six months to get Atmel to release their firmware under a licence which allowed redistribution. That was for use with the Linux atmel_cs driver. And I collaborated with Manuel Estrada Sainz to add the hotplug firmware loading code to Linux, to avoid violating the GPL by linking Atmel's proprietary stuff with the kernel. And I built and distributed packages of the firmware. And all of this is a piss-poor alternative to just releasing the source!

  19. Re:FCC red herring by RedLeg · · Score: 3, Informative
    Here's one response to the FCC issue (basically, there's higher risk if OSS vendors try to write their own firmware instead of appropriately licensed vendor-supplied firmware binaries)
    This is probably true. It's also probably irrelevant. The issue, to a LAWYER, and let's not forget that they're the ones that matter in cases like this, is compliance with the law. Atheros' Lawyers care if they comply. If YOU reverse engineer the driver and in doing so, violate the FCC regs for power, frequency, etc., that's YOUR problem, not theirs. But they are legally not allowed to abet you (by giving you programatic access to these controls) in doing so.

    All your stuff about radio licenses, considering that we're talking about unlicensed spectrum is silly and uninformed (I used to work for a cell/ss7/tcpip vendor and we dealt with LICENSED spectrum). If you stay under certain dB/wattages (which the -hardware- will restrict you to.....
    This is just wrong. First of all, this is IEEE 802.11, not a cell phone. The radios in these chips will happily vary their power and frequencies if the driver tells them to because they are SOFTWARE CONTROLLED RADIOS, and the PHY (Physical Layer specification) for IEEE 802.11 REQUIRES them to operate this way, ie to vary their frequencies. The trick is that while the BAND is specified worldwide, the permitted frequencies within the band are specific to each country. Futher, the allowed radiated power can also vary locally.

    I am not making this crap up, nor am I quoting from some trade rag, journal or online posting. I've spent the last several years as an active, voting participant in IEEE 802.11, sitting in the room with the engineers who design these chipsets and radios. If only one of them, from one company, had explained things this way, it would be one thing. But the reality is that this is the story from all of the mainstream chipset / radio vendors, and it's validated by the other folks in the room who specialize in regulatory issues.

  20. Re:SDR FUD by African+Dyoung · · Score: 2, Informative

    (Here that is again, this time not anonymously. Anonymous comments seem to score really low.)

    It is not true that WiFi card makers are not allowed, under U.S. regulations, to expose the transmit power control, tuning, etc., to the user. People who say so, even people at Atheros who say so, are mistaken or lying. (As one FCC lawyer told me in the mealy-mouthed language of Washington, D.C., "it sounds to me like they are being less than forthright.")

    And yes, I am quite aware of the FCC's SDR rules. Why, I have even read them, which is more than virtually anybody else who is commenting has done! A maker certifies their product under the SDR rules *at their own option*, and then (and only then) do they accept certain strictures (they have to take measures to protect against tampering) in exchange for a streamlined re-certification process. AFAICT from the FCC certifications database, NO WIFI RADIO, least of all any Atheros-based radio, has been certified under the SDR rules. The rules simply *do not apply* in WiFi space.

    (Now, it is likely that the rules in Europe are stricter than in the United States. Still, Atheros will send you a copy of the U.S. SDR rules if you ask about the regulatory issue.)

    Incidentally, every single WiFi radio in existence is software-defined under the FCC's broad definition. Some of them nevertheless have open-source drivers that let you adjust the tuning and power control by getting directly at the hardware. See, for instance, the open-source ADMtek drivers for BSD and for Linux. I wrote the former driver, and I didn't have to break U.S. law to do it. And the manufacturer supports new development on the driver.

    Finally, I will just add that the FCC has traditionally not required even a modicum of tamper-proofing on Part 15 devices. Their long-standing position has been that a device need only protect consumers from *inadvertently* or *casually* tuning a channel they're not entitled to use, or setting an illegal power level, in order to qualify for certification. Furthermore, the FCC seems to be aware that determined radio hackers with malicious mis-use in mind will not be stopped. Hacking a wireless driver for illegal channels or transmit powers is not the "casual" or "inadvertent" consumer activity that the device certification process is designed to prevent.

    I think the real reason Atheros and other WiFi chipmakers are not opening things up is that they want to protect their intellectual property. Someone at Atheros has told me that is a key reason. I doubt that there are major innovations in the software interface (register set, descriptor ring format, blah blah) that give deserve protection because they give them a competitive advantage, but this wouldn't be the first time that a chipmaker saw it that way.

    You might ask, why does it matter whether the software interface concealed by the HAL is opened up? First, so that radio experimenters and open source developers can innovate with WiFi at their own pace and according to their own agenda. Second, because the HAL documentation is virtually non-existent, and nobody is going to write it. Third, (Theo will appreciate this) so we can audit the code (which runs w/ all the privileges on your Linux/BSD system!) for bugs. Fourth, so that we can fix the bugs---and there *are* bugs.

    --
    The African dyoung stays cool in its burrow during the daytime, coming out only at night to forage for food.