Workshop Video #37: USB and Open Source presentation 2012 first run through

This workshop video is an absolute first run-through of our USB & Open Source presentation for the Open Hardware Summit 2012. All comments are off the cuff. The final presentation needs to be just under 10 minutes.

Don’t worry, there will be many changes:

  • Explain the USB Implementers Forum with a line (via Twitter)
  • Slide explaining the Arduino FT232 to custom USB->serial chip change
  • More on the consequences of USB vendor IDs, include hackerspaces, schools, open source, etc
  • Maybe a conclusion, but we try to avoid those whenever possible (via the Forum)
  • Lots of illustrations

Ihsan, creator of the Little Wire, wants you to know that Adafruit licensed their USB ID for free. This appeared on a slide but was not mentioned due to time.

Comments, critiques, threats, etc are all welcome below.

Check out our other workshop videos here.

Join the Conversation


  1. Good job! Nice presentation, lots of info but easy to follow.

    I would encourage people to make use of the Open Moko IDs wether they are planning to sell their product or not. I think the more people we get on there the more difficult it will be for the USB Forum to take action against it as more people will band together if they do.

    Maybe you could mention that. Seems like a stronger call to action is needed in your presentation (rather than wait till the VIDs run out) and this seems like the most viable solution to me.

  2. I have steered away from using USB as much as possible do this very issue. Using Ethernet (where practical) has been a better option for me but its not without unnecessary cost.
    I wish I could fork out a small amount to reserve a few PIDs for myself.

    1. Ethernet also has MAC addresses with similar issues, except each individual device must be unique. You can get a EEPROM from Microchip with a unique MAC address in it, so they are a bit more accessible.

      1. All this only matters if you are doing public projects.
        The Ethernet MAC address situation has become the wild west of registered ID’s, especially in China where virtually all devices with MAC addresses are either invalid or ‘borrowed’ from some other manufacturer.
        I recently bought some very cheap USB to Ethernet convertors in Shenzhen on one of my shopping trips and the MAC’s belonged to apple!!. I think we can honestly say that MAC addresses are no longer the unique ID’s they used to be.

        Mind you……. in this day and age, is that actually a bad thing?

  3. Good presentation but I think you need to explain when a person would need a ID. For example if all the thing being plugged in to the PC wants is to look like a serial port, what is the benefit of having a unique ID? On the other hand it is a truly custom device, like a Microsoft Kennect, that needs special drivers installed then I understand the need for a unique ID since that is how the OS knows what driver to install.

    1. ID is too frugal, IMHO, in addition to being encumbered by USB Forum regulation. ID’s purpose is to let host find out if it already has installed necessary software for that device type. The obvious implication is that the gadget is not a complete working entity, it relies on something that should have been acquired elsewhere (from Internet or accompanying installation media) and put on host, before it can be of any use. That is so old school!

      It would be ideal if an open hardware gadget would carry its complete docs (and license), perhaps even a demo program for host to run, in portable interpreted language (e.g. python) on a flash inside, presenting that data to the host as a small block (mass storage) device, a thumb drive if you will, a standard device requiring no special driver.

      These docs should also contain a file with gadget’s name, individual identity (like serial number, but editable) and a short description. Then the host could identify the gadget from the data and even use it right away (if software is provided in device’s “trunk”), without prior installation. Having to read storage prior to accessing device could introduce startup lag, but I can’t imagine where that would be a critical problem.

      1. It is just bollocks and a get rich quick scheme, if it had been flexible then there would not be a renewable revenue stream.
        They could quite easily have allocated an ID to be used publicly, but on the understanding that the driver made a secondary request to identify the device. (possibly based on some hash key longer than 16 bits!!), or even make the first byte of the ID the LENGTH of the ID
        020507 meaning 0507
        0401080604 meaning 01080604
        At least that would have allowed for manufacturing ID keys upto 254 bytes and WAY more than would be needed and in a totally flexible expandable way.

        Instead they tie up the manufacturers ID, they allow a sub-allocation of identifiable devices, I mean have they learned NOTHING from the TCP/IP V4 fiasco.

  4. This was a good presentation of a significant issue to the community – good job.
    Just noticed a couple things:
    – Having the slide contents on your face is distracting – next time it’d be worth keying in the slides to your side separately.
    – One slide mentioned “Adafruit / Little Bits” – was there a solution there you should’ve mentioned?

    1. Sorry about the slides, I wanted to stand and it was the only space available.

      >>Ihsan, creator of the Little Wire, wants you to know that Adafruit licensed their USB ID for free. This appeared on a slide but was not mentioned due to time.

      This is on the menu of things to talk about, but with only 10 minutes there is too much background. Basically the Little Wire used an Adafruit USB ID, which isn’t allowed, but they formed some partnership on the project and now Ihsan uses the ID for free. Last I was involved in the discussion there was mention of a token royalty (thus the slide), but Ihsan was very clear this isn’t now the case.

      Now, is this a solution? I don’t have all the facts so I’m just going to drop it as a point for now. The USB-IF has only 2 exceptions to the no share rule, both require written permission from the USB-IF. I can’t explain to you, based on what I know, how they fit into either exception. I’m neither a lawyer or a legal novice though. I trust the Adafruit and Ihsan have a better understanding of the situation than me and have made the right decision for their project.

      I posted a copy of the USB IF sharing details here:

    2. Hi,

      As also Ian said and corrected, Adafruit kindly and generously let me use their ID/PID without any royalty fees.

      The process and the how it was progressed to this end has a very interesting story and i might write a blog post about it.

      And also “Little Wire” has no connections with the “Little Bits”. Two of them are completely separate projects. :)


  5. Good presentation on the USB ID problem :o)

    btw you don’t need to have projector light in your face :oP just projector screen a bit smaller and it will be fine :-)

  6. Very interresting, did not know that the USB IF was so strict, I have seen some notes about expensive usb code for some chips, but did not know the reason for now.

    Regarding Adafruit, do they have their own vendorid?, according to this:
    it looks like they are under some “multiple vendors” group, if that is the correct id of course:

    1781 Multiple Vendors
    083e MetaGeek Wi-Spy
    083f MetaGeek Wi-Spy 2.4x
    0938 Iguanaworks USB IR Transceiver
    0c30 Telldus TellStick
    0c31 Telldus TellStick Duo
    0c9f USBtiny

    And Saleae, looks like those also have hijacked id’s?
    0925 Lakeview Research
    0005 Gamtec.,Ltd SmartJoy PLUS Adapter
    8101 Phidgets, Inc., 1-Motor PhidgetServo v2.0
    8104 Phidgets, Inc., 4-Motor PhidgetServo v2.0
    8800 WiseGroup Ltd, MP-8800 Quad Joypad
    8866 WiseGroup Ltd, MP-8866 Dual Joypad
    Or are they called Lakeview Research?

    1. Oh, formatting got lost there, the subsequent id’s are products id’s for those two vendorid’s I listed..

  7. Glad to see a presentation on this subject, wish I could see Ian give it in person but I cant make it out to the summit this year. The first run looked great, cant wait for the final presentation!

    This is something I have had to deal with myself with the LeoPhi USB pH unit and was pleased when Open Moko released some PIDs for open source. This is a good stop gap but I completely agree with you that it could be a problem down the road. I would love to see a viable solution to this dilemma.

  8. Reserving IDs for standards is unfortunately not a workable solution. Because it’s so hard to get USB right there’s a ton of “class-compliant” devices that need custom drivers to work right. This is not at all helped by operating systems sometimes interpreting the standards very differently, so a device that works perfectly fine under one OS may even refuse to enumerate under another.

    I don’t know if it’s worth pointing out that you also cannot use the USB logo unless A) the device passes certification and B) you pay $2000 for a two-year licensing term (but it does come with a VID).

    And while I’m venting, up until not too long ago the cost of a VID was $1500. I very much doubt the inflation rate has been that steep for the past few years, the greedy bastards.

  9. When it comes to “friends of open source”, the USB-IF is quite the opposite. I tried communicating with the USB-IF concerning what it takes to get permission to sublicense vendor IDs – besides a very stern warning not to attempt to create an end-run for hobbyists and small-businesses – they refused to confirm what’s required to sublicense a driver ala V-USB (they only specifically mention hardware in their agreements).

    I’ve done a lot of thinking about this, wouldn’t it be better to create a community “OSHW” driver methodology. What I had in mind is this:

    * Construct an OSHW “Implementer’s Forum” – Maybe fund it via donations, or a kickstarter. This foundation purchases a dedicated VID.

    * The community then produces a cross-platform “OSHW” USB driver, possibly built on top of a library such as libusb) as a starting point. This library simply recognizes any device using a designated OSHW VID/PID as a type of OSHW device.

    * Each OSHW device must implement some additional descriptors to identify (ala WCID) itself. This includes a UUID that can then be used to identify the device and vendor, and install/bind a specific driver – Under windows, there are utilities/libraries such as libwdi that can be used to create this. (though, these utilities need to be done under OS X and linux, also, to be complete.) Maybe the PID could be used to specify a specific OSHW driver “class”

    * Perhaps “joining” the foundation as a supporter could grant access to device/logo testing, as an OSHW device. Although, technically, the “OSHW-IF” could (and should) have it’s own standards.

    This idea is only half-baked, as I originally wanted to have something to present to the OSHW summit someday. The main point is to create a framework where there are no barriers or gatekeepers. I’ve been working on several USB devices for sale, so this is something I need to tackle sooner than later, as this kind of framework could allow the community to establish signed WHQL drivers that are usable under windows x64, and other things that many individuals (such as myself) cannot practically accomplish.

    1. I think this is a good thought, but the goal of the USB-IF is ‘no resale’. Regardless of whether you follow their arcane set of rules to the letter, they’ll just change them to prohibit this. The new agreement for a USB ID has a ‘we’ll change it anytime without notice’ style agreement too.

      1. Yes, there are exclusive terms for original equipment manufacturers (no, you don’t become an OEM if you burn a firmware into a chip either…) who actually design and produce USB chips to sublicense them. I believe I mention this on a slide in the presentation.

        I posted the terms of this program in a PDF in the forum, sorry the link isn’t handy.

  10. The vendor ID problem is made far worse than it needs to be, by the common practice within the open hardware community of using the VID/PID pair.

    For example, if you use an Arduino Uno (on windows), you need to load Arduino INF file. Then you use a bus pirate, and load another INF file. It doesn’t need to be this way.

    If you have ever used my Teensy board, my INF matches against the protocol numbers, NOT the vendor ID. So if you then plug in any CDC-based Arduino, or any other CDC-ACM protocol device (which are so common among open hardware projects), that same INF file will load Microsoft’s driver.

    The USB-IF is probably not going to abandon their primary source of sustaining revenue. But the open hardware community can change its practices. I’d suggest 2 important things were missing from your presentation:

    1: Advocacy for designing devices to standards, and writing INF files (and drivers, in the rare cases where projects actually create a driver) to ignore vendor/product ID numbers and match to the class/subclass/protocol numbers.

    2: Recognition that much of USB’s value comes from the standardization process. Sadly, many people in this community will use offensive language like “greed bastards” (as seen in the comments above) and frame any issue in unconstructive “us vs them” terms. It’s all to easy to take good things for granted. Any responsible presentation on this issue should recognize the USB-IF’s important role in creating much of the value USB currently has.

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.