# Do I need to pay royalties to the SD card people if my device "just happens" to be compatible with SD cards? [closed]

I'm designing something which will use an SD card. The device will be able to read and write the cards, using publicly available specifications. Do I need to pay the SD card people?

• Your "just happens" comment is highly unlikely. It would mean that you just happened to figure out something with out doing any reverse engineering or research on another groups intellectual property. Oct 25 '10 at 20:37
• Well, the SD card standard has been reverse engineered in a clean room manner and it is well known how to use an SD card. So it "just happens" that my microcontroller works with it without me having to actually read the standards. Oct 25 '10 at 20:42
• Don't claim that it "just happens" to work. The fact that it has been reverse engineered without the standard is different from the claim that it "just happens" to work. See en.wikipedia.org/wiki/SD_card#Openness_of_standards Oct 25 '10 at 21:07
• The root of the question is: Are you violating any of their patents? If so, are those patents valid, and if they aren't, are you willing to fight them in court? Oct 25 '10 at 21:46
• What about MMC cards? I'm a bit n00bish in this area, but I remember that some routers running under GNU/Linux could read SD cards using MMC drivers, and MMC appears to be more or less open standard. Oct 26 '10 at 7:29

I had the same concern just a few days ago. I am planning on using a microSD card internally inside a device for extra storage. I will only be accessing it via the SPI interface and not using any proprietary features. The end user will not even be aware there is a microSD card buried inside the device, so there is no need (or desire) to put a SD logo on the product.

I sent an inquiry to helpdesk@sd.org. Their reply was "If your client's product will be interoperable with SD cards, they will need to sign the Host Ancillary Product License Agreement. SD Association membership is required in order to sign the HALA."

So it looks like we have to pay the piper to be completely legal. My understanding it is $3000 a year ($2000 for the membership, and \$1000 for the HALA).

• Ouch, I can't afford that. Oct 25 '10 at 20:07
• "I wonder if this applies only if you are selling many units?" there is no lower limit on the number of units, the SD group can set whatever requirements they want, they own the patents. You can of course take the gamble that your volume and marketing will be so low profile that they won't bother suing you, but that gamble is completely on your shoulders to take.
– Mark
Oct 25 '10 at 20:39
• The barber is the last person you should ask whether or not you need a haircut... Oct 25 '10 at 21:46
• @Sparr, frankly, I was expecting the answer I got, but it was a question I needed to ask, so I could pass it along to my client. There are only 1000 members in the SD Association, so there must be a lot of companies ignoring this (or unaware of it) -- sort of like the mess with the GIF patent a few years ago. Oct 25 '10 at 22:00
• If your card is internal and not user accessible, it could be argued that it is not "Interoperable with SD Cards", as the user has no access to the card. Sep 23 '11 at 23:29

No license is needed if you use SPI mode (as this doesn't involve any patented protocols) and you don't use the SD logo. They probably have some lame-ass patent on the multi-bit faster modes for which a license is needed

• thanks - but do you have any sources? Oct 25 '10 at 22:48
• @mikeselectricstuff -- This was exactly the scenario I described to sd.org -- I am only going to access the SD card using SPI mode, and there is no need for the SD logo (the SD card is hidden inside the unit and the end user is not aware of its existence), and they said my client would need to sign the HALA. Oct 25 '10 at 22:59
• Likely the company will tell you you always need to pay for a license because that = more money for them. Oct 26 '10 at 13:52
• Also SD has been around long enough that I think we would have heard about it by now if SD had actually persued anyone for this. Oct 28 '10 at 8:43
• @mikeselectricstuff, Can I cite you as legal advice? Nov 1 '10 at 1:54

Please, please: don't build a SD host: build a MMC Host! that way, you can read SD cards, using MMC mode! off course, in order to use microSD, you will need the microSD -> SD (MMC) adapter. I believe that in this way, you don't need to pay the royalties, but if I'm wrong, somebody tell me!

• I thought SD and MMC were not compatible command wise? Oct 31 '10 at 0:12
• Well... it actually depends on the SD card, but most (not all, but almost, it is hard to find one SD that doesn't support mmc mode) of the SD cards support MMC commands, which is good. Some info: freelabs.com/~whitis/sd_card and nxp.com/documents/application_note/AN10406.pdf Oct 31 '10 at 3:08
• Thomas: yes, the "SD commands" are different from (and require more pins to be connected) than "MMC commands". However, most companies that actually manufacture "SD card" design them such that the same card works with either command set. Nov 18 '10 at 2:06

Another issue to be aware of - having support for Microsoft's FAT filing system (on SD cards) in your device may infringe patents.

http://en.swpat.org/wiki/Microsoft%27s_FAT_patents

(I am not a lawyer) My understanding is that there's only a problem when using long filename support.

• Yeah, that's why I'm avoiding it. Microchip's memory disk drive has no support for long names. Oct 27 '10 at 15:40

Howzzabout just signing on so you do not have to put a disclaimer on what would predictably be an SD card socket? Clearly your strict answer on interoperability (which you tested adequately, we imagine) is No; and if you look at MSDN you can cite their nice definition of free (if you really do not want to block out a single file occupied completely with XFS) on the matter of recently used filesystems. However, you surely want the fastest card access available and can access an organization with a common desire for this sensibility? Before we even start groaning years hence that it's not teracomm holodiamond-readable?