Why not just pick a VID and start using it? USB is so well understood at this point that there is no need for anyone to play ball with an "official" organization.
(Whoever gets "officially" issued that VID is going to whine when they notice it's already being used for hobbyist purposes anyway, which means that the technique of just picking one will guarantee uniqueness.)
I like this idea. If there's some benefactor to the Open Source community (or even if they pass along a collection) for the VID, that could even work. They just need to properly implement the standard and the VID can effectively be the Hoover or Kleenex of VIDs.
Edit: On second thought (after I actually read it), this bit...
Please immediately cease and desist raising funds to purchase a
unique USB VID for the purpose of transferring, reselling or
sublicensing PIDs and delete all references to the USB-IF, VIDs and
PIDs for transfer, resale or sublicense from your website and other
marketing materials.
...rubs me the wrong way on so many levels, I'm tempted to say, the hell with the forum.
An argument I would make if I we t to court fighting that is that such squatting dilutes the 'USB' brand.
Imagine a world where this 'open' approach gains market share. For the consumer, the net result easily could be that USB, which now is highly plug and play, becomes more like the way ISA cards used to be plug and play: you can plug in any device, but to make it work, you need to do some voodoo (oops, there's more than one device with that PID/VID. Please tell me what you plugged in: X, Y, Z, or something I haven't heard of?")
Exaggeration? Yes, but not completely untrue, and that's the argument I would make.
Whatever you do, you need some entity that prevents multiple manufacturers from using clashing identifiers. That is one of the things the owners of the standard will fight for to maintain, because it is one of the things required to make USB work as well as it does.
Yes, it would be nice if they sold individual VID/PID pairs to hobbyists. But I do not see a legal reason why they would have to do so. Anti-competitive? Maybe, but they will argue that there are thousands of individual vendors in the market.
> Imagine a world where this 'open' approach gains market share. For the consumer, the net result easily could be that USB, which now is highly plug and play, becomes more like the way ISA cards used to be plug and play: you can plug in any device, but to make it work, you need to do some voodoo (oops, there's more than one device with that PID/VID. Please tell me what you plugged in: X, Y, Z, or something I haven't heard of?")
For the record, this already is pretty common. Lots of keyboards mimic Apple's VID/PID, and tons of controllers use absolutely nonsense VIDs/PIDs (GameStop's mobile controller line, for example).
The fact that it's so important to prevent multiple manufacturers from using clashing IDs is exactly why it's in their interest to make registering an "official" ID as open and accessible as possible.
Read the article again. That's not the Forum, that's the VTM Group, which handles their marketing and legal concerns. The USB Implementers Forum itself didn't make a statement.
This idea did not sit well with VTM Group, the people serving as the
management, PR, legal, and membership and licensing department of the
USB Implementers Forum
The hands, the mouth and collector of thoughts cannot be separated from a thing and still be called a whole. Besides even the title says, "USB Implementers Forum Says No to Open Source"
The article is a second-hand source; the author could be trying to stir something up, or maybe just got a bit too excited. Who knows? The article also says the proposal, among others, "haven’t hit the desk of anyone at the USB Implementers Forum, the people who are actually in charge of designating USB VIDs and PIDs". Doesn't sound like the forum said no to me.
What is with this bizarre argument that paid legal representation doesn't legally represent their client? By definition, unless the USB Forum directs the VTM Group to retract the C&D, it represents the Forum's position.
As far as I can understand, as with every organization in the world, when the-entity-that-represents-the-marketing-and-legal-concerns of that organization writes a cease and desist, it kind of comes from that organization. The USB IF itself didn't make a statement because they don't make statements on these matters; that's why they hired VTM Group for.
Don't underestimate the USB Implementers Forum. Despite its name, it is not an organization of USB users (big and small). They have a direct interest in this matter because:
a) Like every organization, they need to have some source of income. Technically, they're a non-profit organization, but they're also the one who issue the VID, and a company giving out PIDs to whoever wants them is eating their "lack of profit".
b) Its members who have an interest in consumer devices/end products (i.e. companies that don't sell chips, but devices using chips) tend to be large and slow-moving. The Kickstarter crowd is pecking at their business options. (True story).
The way these things normally work is that you're only allowed to use the name and marks if you're an official licensee.
So if you put the USB logo on your marketing and claim to have a "USB Mini" connector in your specifications then you could be in trouble on two fronts: (1) the usb folks can sue you for using their IP and (2) purchasers can claim the product is not "as described" which may given them certain rights dependent upon the location.
Not using the official logo shouldn't be a problem in hobby market. Everyone will recognise the connector. Not being allowed to identify it as USB2 or USB3 or whatever, that could be a problem. I'm sure there are creative ways around it though.
One should be able to say "Compatible with USB2", in the similar way 3rd party companies made cartridges for the Nintendo.
And about squatting on a VID.. Well, they should have thought about pollution of their namespace on their anti-hobbiest policies. They frankly deserve it.
> One should be able to say "Compatible with USB2", in the similar way 3rd party companies made cartridges for the Nintendo.
The most prolific of those 3rd party companies was sued by Nintendo and lost.[1][2] Although that case is not directly applicable, and had different circumstances. I thought it was worth mentioning.
At this point, I doubt that certification matters for many applications, particularly in the consumer sector.
"Connects to your computer at speeds up to five gigabits per second using industry standard USB cable," probably covers everything short of a the edge cases such as government procurement contracts.
Anecdote: apparently going after Chinese knock-off companies is a gigantic PITA. I've worked with those who have tried going after them. File a complaint about company ACBD. A week later, company ABCD never existed, but company XYZ is operating at the same factory. Amazing!
Which could be said about so many such knockoffs; however, the issue of Chinese and other non-US counterfeiting is harder precisely because they're non-US, and operating in manners and areas where the legal system is not prone to caring about US regulations (for better or worse).
So whether you can safely ignore this depends largely on how easy it is for this body to successfully throw the book at you, and others' success in this area doesn't really mean anything unless you're able to operate in the same circumstances, which I doubt most of us are.
How about BSU? It could stand for a lot of things... but I like Bull Sh!t USB. Which I think is an appropriate eye-poke response to an annoying organization.
As far as I remember, only the logo is trademarked, not the phrase USB. So you could still state your product has USB, you just can't display the logo anywhere.
It's like if you want your CD to have the "compact disc- digital audio" label you have to comply with whatever colored book. People stopped caring about that long ago and won't care much for USB either as long as it works.
Maybe, if they're reserved as unassignable (due to being an inappropriate value for professional, business puposes), then perhaps it's open season on those.
An alternative would be to find one that has been assigned to a now defunct company. Then you'd only have to worry about historical devices and if you are lucky you could come up with a list of those PIDs and exclude them.
I think 0xF055 has circulated too much now (slashdot, hack a day, maker: etc.) So if we there should be squatting it better be on 0xF055. Let's just destroy the strict minimum to achieve our goal (having a unique VID+PID for our proprietary drivers to find the corresponding gadget on the bus).
You wouldn't even have to make use of the VID. If a sizeable group would just agree that "we're going to view this range as set aside for open source and start using it", no company would want to accept being assigned a VID in this range.
I think there's still a problem because that leaves still only 255 PID.
Maybe we should just squat the VID, and then do a PID+(another field in the descriptor) as the discriminator for people who need special protocols (I do).
For now I've stolen my MCU maker VID and used 255 as PID, because I couldn't even find an "experimental" PID/VID in the spec to use during development.
It's a bug and urgent problem, I'm perfectly ok to fudge the rules, but we have to agree on something that doesn't break people's drivers.
I know I saw 0xffff or something like that being used for development in some source code, but it turns out searching for "VID" is impossible because it gets interpreted as "video".
When I was doing some development for some USB devices, I remember there was a VID/PID designated for development-only use. I can't remember what it was, however, and the company I was doing work for registered their own before the devices shipped.
According to TFA, Openmoko/FIC is already giving out PIDs from their VID space to any FOSS projects who ask.
IIRC they're not the first, either. And there've also been organizations freely allocating unique ethernet addresses out of their OUI space.
The amount of trouble they receive from the USBIF/IEEE/whoever seems to vary a lot from case to case, though. I expect it depends on which individual person the situation comes to the attention of. In some cases the USBIF or IEEE has actually revoked the VID/OUI assignment, leaving everyone who tried to play by the rules effectively squatting on an unassigned ID anyway.
I'm not sure I fully understand the article. What does the following mean?
"Since other USB device vendors such as Microchip and FTDI give away USB PIDs for free"
Does that actually mean, they give them for free? If so, how can they do that? Why does VTM allow them to do it? And what is the actual problem at all if you can get them for free?
Microchip has paid USB Forum for its VID 04d8. If you build a USB peripheral with one of their microcontrollers, you can ask Microchip to allocate you a PID (since they have 64K of these), and let you use their VID:
Alternatively, a bunch of cooperating projects could share a VID:PID pair and agree amongst themselves and agree on an alternative way to identify devices. The VID:PID would cause the USB driver to load a "sub driver" that would implement the alternative scheme. For that matter, by using such an extension the whole open source community could exist under a single VID:PID.
Since a USB device gets paired with a driver through a VID/PID pair, buying a single VID allows you access to 65536 PIDs for that VID. They give out the PIDs for free but hold on to the VID for themselves.
FTDI own a bunch of VIDs which are associated with "FTDI" devices. If you ask FTDI they'll reserve a small block of PIDs for you to use for your own products that use the FTDI USB chips. 8 PIDs cut out of a 65536 block is not a significant cost.
I'm surprised that VTM still allows them to do it though, maybe it's a special case because you're using their IC.
The problem is that VTM maintains an "official" list of VID/PID owners, so that they can keep drivers on seperate IDs and prevent clashes for users. Most hobbyists just pick a random VID/PID for their personal projects and hope for the best, but for small scale hobby releases it's problematic since "technically" they are going against the terms of service for the USB protocol. Sometimes there will be clashes if people pick random numbers, and VTM hates that.
USB devices are supposed to be detected via the class (es) declared in the descriptor actually. This allows for e.g. a single HID driver to work with input devices from all manufacturers. Linux drivers almost all work this way, using the vid/pid for quirk detection only. The windows world tends to be less clean.
That's the humorous part of the whole discussion that the VTM group is trying to preserve revenue by ignoring the hobbyists and sticking with the people who think nothing of falsifying UL registry, falsifying FCC certifications, and violating patents, but I'm sure those guys would never turn against the VTM group and illegally use the USB trademark without permission, LOL.
Whereas the hobbyists, if you don't intentionally try to screw them over like they're trying to do, would probably be ridiculously loyal and obedient in comparison.
Fundamentally despite the "hate opensource" and "revenue generating middlemen" story, some of which probably is true, the fundamental problem is likely the lack of a point of contact. They probably like knowing there's a directory of real world contact information such that identification number 0x123456 is clearly a product of such and such for debugging purposes and interoperability and lack of duplicate IDs and the like.
Something similar happens with ethernet MAC addresses. Legendarily it was HP (or was it sun?) who shipped a whole batch of ethernet cards accidentally in the 90s with the same MAC address, boy was that a nightmare to figure out the hard way.
> Legendarily it was HP (or was it sun?) who shipped a whole batch of ethernet cards accidentally in the 90s with the same MAC address, boy was that a nightmare to figure out the hard way.
Android has an API to query a unique device ID, which is generated from a field that's supposed to be populated with a serial number by the manufacturer. It is (or was previously) used to identify you as a particular user in some games, as well as for ad tracking and analytics.
One line of phones (I forget which manufacturer) managed to NOT update that serial number correctly, and as a result the entire model of phone came up with the same "unique ID". This was not fun to debug, as lots of users were ending up with other users' saved games, and one particular "user" was showing up in analytics as having used dozens of apps thousands of times a day...
> Legendarily it was HP (or was it sun?) who shipped a whole batch of ethernet cards accidentally in the 90s with the same MAC address, boy was that a nightmare to figure out the hard way.
Sun used to use the same MAC address on each port of their QFE (quad fast Ethernet) cards. It was easy to fix with ifconfig, but always made me wonder two things: a) if I number these ports sequentially (:a, :b, ...) am I going to collide with some other QFE card from the same batch, possibly from this same order of a dozen cards? And b) who thought this was a good idea? Was Sun just conserving MAC addresses on the theory that most QFE cards are 75% underutilized??
That's because the MAC address is stored in system ROM on the motherboard, not in the NIC, iirc. The theory was 1) the ports would be used on different network segments, hence no problem and 2) storing the MAC in the motherboard meant you could swap NICs without updating all your DHCP/whatever config files.
We might be comparing Sun hw from different eras. The QFE cards I remember were in a very different address range from the onboard Ethernet (which was still 8:0:20:... I think). Seems like the QFE MAC must have been in PRAM on the NIC then, at least. And I am pretty sure I remember the MAC address following the card, too.
The problem I ran into was that when two same-MAC ports were connected to different segments/VLANs on the same layer 2 or 3 network device, that device wouldn't know what to do with the packets. Or it might send them down the wrong wire, which was a problem for me -- these were firewall boxes. :)
Eventually Sun added a boot param (or a kernel config? Set from OBP or from a shell) that would automatically number the QFE interfaces sequentially on boot. That fixed the problem for me.
Much later, they added the front-panel accessible smart cards that contained MAC, hostid, etc. I think that was the Netra series, intended for carrier grade RAIC installations.
I have a knock-off xbox controller that is an exact copy of the Xbox controller S, but claims USB ID ffff:ffff.
It turns out there is also some unrelated cheap IR receiver that does the same and if you are unlucky this driver gets loaded instead, leaving you wondering why the gamepad doesn't work.
From what I understand they clone existing VIDs because their functionality is exactly the same. If you have new functionality and need a new driver I don't think you can do that.
Yes. That's why people are saying the community should squat one that is still unused and then it will be ours by default, because no manufacturers will want it if its already used.
Why not use this cease and desist letter to file a RICO Act claim against them?
If they can't responsibly offer their product without revoking it for simply using it as intended, they are racketeers. The Open Source community has not broken any legal agreements in simply publicizing the idea of a shared VID. The USB Forum are completely in the wrong for their behavior.
MCS is in Holland, where both their jurisdiction and the fact that they licensed their VID from USB-IF a long time ago make it impossible to enforce the prohibition against reselling PIDs. For EU 10 each, it's worth it just to kick sand in the face of the asshats at USB-IF.
A proper ID makes it much easier for the consumers. By having a proper ID, the OS can search its database of drivers, and if that fails, try to download from a source such as Windows Update.
Also, a lot of this could very well be trying to avoid the pain of the Bad Old Days of pre-plug and play DOS, where you had to manually set things like interrupts and I/O ports, and hope and pray that your new device didn't conflict with something important. For example, many an oldschool game had dire warnings about not running the sound card autodetect if you had things like scsi cards, because the conflicts were near inevitable and pretty catastrophic.
Wow. If you tought a memory stick pretending that it's a keyboard was a serious enough problem, just wait untill somebody thinks loading random drivers from the device (or the web!) is a good idea.
It will happen, that's a near certainty. Some day, somebody will think that's a good idea, and since it's easy, the scheme will get widely used.
Perhaps the Linux kernel you already have installed, which presently has drivers for just about everything included and developed in a centralized, controlled fashion...
Whether this is actually better probably depends on your point of view. But loading (somehow OS-neutral?) drivers from a fixed store on the device seems like a great way to be stuck with out-of-date binary blobs forever.
Then again, there are cases where developers have and will release driver source out of tree so that new devices are supported on day one, or to avoid the politics of the linux kernel. Having a flash with a driver, even if it is an older one, could be a godsend for things like nics, where you can very easily end up in a catch-22 type situation.
That's why i proposed an URL, or an URL in the blob. Well, anything is better than the current situation.
Moreover, in my current forey into USB, I discovered that kernel device drivers are completely unnecessary. And a google chrome API (or the underlying libusb) is completely good enough for proprietary devices.
> Wow. If you tought a memory stick pretending that it's a keyboard was a serious enough problem, just wait untill somebody thinks loading random drivers from the device (or the web!) is a good idea.
Oh, come now. Any competently-designed USB penetrator will have your system owned seconds after you plug it in, with no further interaction from you. Running drivers from the device poses no additional risk beyond what you've already taken.
Many hobby things with USB ports are using the default VID/PID from the chip vendor (generally FTDI's USB-to-Serial converter chips, or the on-chip USB controller of Atmel/Microchip/etc's microcontrollers).
Using your own VID/PID allows you to write and distribute a driver that can be tied to your gadget rather than using a generic driver. Widely distributing products (even if they are "hobby stuff") that re-use the microcontroller's default VID/PID is also usually against the license agreement with the chip vendor and can lead to problems down the road.
Hopefully such a bullish and short sighted stance as this is just the thing to get some publicity and traction to boot these idiots out, or at least kick the money grubbing Luddites out and replace them with someone with some common sense. Grah
I presume there is a segment of VID that is marked as 'local' or 'for test purpose only'? Just like IP has local addresses for intranet/testing.
Also, if an open source is popular enough to the point a unique VID is needed for proper driver support, I will say this project will easily get fundings to go commercial (just like RedHat).
Heh, most such open source projects don't want to "go commercial", that's the exact point. And I'm not sure how RedHat is exactly "an open source project who went commercial" or rather a commercial company doing open source.
Nothing is stopping anyone from using any given VID for their own purposes of testing. If its in your own garage as the article mentions, you can use whatever you want. However, once it's out in the wild (even if it's just the few hundred devices), the USB-IF (and their lawyers) apparently can squash it.
The fee is $5k if I recall. As others have mentioned, if you are planning on making a real product, it's something you can roll into the cost. Although I completely understand the difficulty of someone just looking to sell ~100 devices.
I wonder if there's a way to allow a "Bring-your-own" VID? As in maybe switches or something to set the VID by the purchaser?
Technically, you could, but you don't want to stomp on other vendor's feet. It's a bit like mac addresses or IP addresses, you can do what you want but you probably want to behave in society (in the case of IP addresses, you'll need friends for routing).
And also, to find the device from the OS API, you sometimes have to submit the VID/PID of the device you are looking for. Example: http://developer.chrome.com/apps/usb.html#method-findDevices So changing it on the fly might be a problem (not sure, maybe once open they won't seek it again).
Following a link on the internet it look like they actually have a prototype VID/PID, but you have to contact the forum and sign some boilerplate (saying you won't release your product with the proto numbers) to get it.
(Whoever gets "officially" issued that VID is going to whine when they notice it's already being used for hobbyist purposes anyway, which means that the technique of just picking one will guarantee uniqueness.)