What to do about USB VID and PID?

[dpgeorge]

As @chrismas9 pointed out to me, there are a few options, none of which are optimal:

1. Buy your own VID from USB-IF for $US5000.
2. Request free PIDs from Openmoko http://wiki.openmoko.org/wiki/USB_Product_IDs
3. Buy PIDs from MCS Electronics for EUR9.95. Their VID has been revoked so they are only selling a guarantee that no one else will have the same PID.
4. Use VID=0xf055; see http://hackaday.com/2013/10/22/usb-implementers-forum-says-no-to-open-source/

[skgsergio]

From that options... the more reasonable for me is 2 and seems that there are many FOSS projects using it. It's like 3 but for FOSS.

4 may collide with other devices and probably wont be accepted in the linux VID:PID list (3 also may be not accepted, not sure).

[pfalcon]

5. Just use STM32 default vid/pid. STM does have that, right? Then, if using standard USB device classes (CDC, MassStore, ...), then specific vid/pid is not important. Having good USB description string and unique USB serial may even with more advanced cases. (Disclaimer: worth checking STM license regarding use of default vid/pid).

[chrismas9]

It appears that ST may sub license their VID. See this thread:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2Fquestion%20for%20STOne%20or%20anyone%20from%20ST%20(about%20USB%20and%20allocating%20PIDs) https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2Fquestion%20for%20STOne%20or%20anyone%20from%20ST%20(about%20USB%20and%20allocating%20PIDs)&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1981 &FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1981

However it is not a published policy like Microchip, Atmel and FTDI. Although they may sublicense to Damien for his production I doubt they would condone other parties using the open source files to manufacture clones or derivatives. I think when Atmel and Microchip sublicense VIDs and PIDs they have to register the sublicense with USB-IF and wait for approval.

I favour obtaining an Openmko VID/PID set to include in the open source code. That doesn’t stop Damien using an ST sublicense or USB-IF purchased VID for his production.

From: Paul Sokolovsky [mailto:notifications@github.com]
Sent: Saturday, 4 January 2014 3:17 AM
To: micropython/micropython
Cc: Chris Mason
Subject: Re: [micropython] What to do about USB VID and PID? (#47)

1. Just use STM32 default vid/pid. STM does have that, right? Then, if using standard USB device classes (CDC, MassStore, ...), then specific vid/pid is not important. Having good USB description string and unique USB serial may even with more advanced cases. (Disclaimer: worth checking STM license regarding use of default vid/pid).

—
Reply to this email directly or view it on GitHub #47 (comment) . https://github.com/notifications/beacon/6243558__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNDI5ODYzMywiZGF0YSI6eyJpZCI6MjI4Nzc2MTB9fQ==--5a0391c0daafa3d78eda504aff11be41caeb0169.gif

[skgsergio]

As far as I know Microchip, Atmel and FTDI only gives PIDs to products derived from their hardware.

[meski]

On Sat, Jan 4, 2014 at 10:46 AM, Sergio Conde Gómez <
notifications@github.com> wrote:

As far as I know Microchip, Atmel and FTDI only gives PIDs to products
derived from their hardware.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-31564996
.

Is it a money issue to get the PID, and how much?

Meski

http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

[chrismas9]

No, it’s not just a money issue. Under the current USB-IF license you cannot sublicense PIDs. Damien can buy a VID for the boards he manufactures, but I think publishing it in the open source code would be a violation of the USB-IF license. The MIT license allows you to use the Micro Python software for any purpose and would in effect be a free sublicense of the embedded VID and PIDs in the source code.

The early USB-IF licenses were not restrictive and that’s why Openmoko and the semiconductor manufacturers with early licenses can sub license.

I am not a legal expert but I have not found any patent or other restriction on using a pair of 16 bit numbers to let your thing talk to a computer over 4 wires. The legal restrictions come if you want to claim to be USB compatible or certified and then you must buy a VID and comply with the license. The problem is finding a pair of 16 bit numbers that won’t conflict with already assigned numbers.

USB-IF have been active in preventing small users getting a VID and PIDs, including revoking VIDs and cease and desist letters. However they have not taken any action against Openmoko

From: mike smith [mailto:notifications@github.com]
Sent: Saturday, 4 January 2014 12:25 PM
To: micropython/micropython
Cc: Chris Mason
Subject: Re: [micropython] What to do about USB VID and PID? (#47)

On Sat, Jan 4, 2014 at 10:46 AM, Sergio Conde Gómez <
notifications@github.com mailto:notifications@github.com > wrote:

As far as I know Microchip, Atmel and FTDI only gives PIDs to products
derived from their hardware.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-31564996
.

Is it a money issue to get the PID, and how much?

Meski

http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

—
Reply to this email directly or view it on GitHub #47 (comment) . https://github.com/notifications/beacon/6243558__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNDMzMTUxOSwiZGF0YSI6eyJpZCI6MjI4Nzc2MTB9fQ==--10162013fc807f1f0e1f2f9747ed77849a740271.gif

[mikaeleiman]

IMHO each hardware device should have a "proper" VID/PID. So @dpgeorge would get a VID for the board he's making, and if someone else uses the micropython code in some other hardware, they'd have to arrange their own VID. Having the VID present in the code should be irrelevant; it's quite easy to just use someone else's anyway if you want to. Maybe make it a #define that's set in the hardware/board-dependent parts of the code.

Now, the problem is that the cost of a VID has risen; we "only" paid $2k for ours a couple of years ago and now it's $5k. Paying that much for a single product seems a bit insane. It's one thing for a company that expects to make several products over a number of years to invest in this, but I guess it's up to @dpgeorge to decide if that's a wise thing to do, or if using an sub-rented PID is a better choice.

[dpgeorge]

Since the USB descriptor now used in the stmhal port is not a standard one provided by ST (notably, it's now a composite device with CDC and MSC, or CDC and HID), we can no longer use the ST VID/PID (because then the device clashes and doesn't work with any existing (Windows) drivers that specifically recognise the ST VID/PID).

[chrismas9]

For the open source Micro Python, one off and low volume builders I think PIDs from Openmoko are worth considering. For commercial volumes each manufacturer should use a different VID/PID - either pay up the $5k or get their own VID/PID from one of the alternatives. Each different product should identify itself by name or brand and that need a unique inf file and VID/PID. Openmoko have an early USB-IF license that does not prohibit sub-licencing. Their terms require either the hardware or firmware to be open source, so they should grant a licence for low volume commercial products running Micro Python. Other Kickstarter projects have gone this way.

[dpgeorge]

Would I need a separate PID for the different configuration classes of the device? At the moment there is CDC+MSC and CDC+HID. The MSC and HID components work fine without drivers, it's just the CDC part that is the problem. But, the PID is applied device-wide, and so refers to the whole composite device. Thus, I guess I would need a PID for each configuration.

[lurch]

Dunno if this is helpful or not, but maybe you could take a look at LUFA as IIRC there's a lot of code in there that presents composite USB devices to the host.

I dunno much about USB but I assume the PyBoard can't appear to the host as a USB hub with separately-attached CDC and MSC peripherals?

[nadrimajstor]

For the posterity sake, if a device contains Linux inside, ask Greg Kroah-Hartman for one from Linux Foundation
Now (April 2015.) our favorite snake have another option: This is a place for all of those "tiny" devices to get a valid pid.

[dpgeorge]

Yes, pid.codes looks like a good option (we've been using 0xf055 as a VID so far).