News Archive (1999-2012) | 2013-current at LinuxGizmos | Current Tech News Portal |    About   

Where are the open-source SD/SDIO stacks?

Nov 9, 2005 — by LinuxDevices Staff — from the LinuxDevices Archive — 133 views

Foreword: This intriguing guest editorial discusses the current legal landscape surrounding the SDIO and MMC specifications, and explains why no open source SDIO host controller drivers exist. It was written by Paul Lever, the president of Codetelligence, which markets a proprietary SDIO stack. Enjoy . . . !


Disclaimer: I'm not lawyer. I don't play a lawyer on TV. I don't give legal advice. The information in this document is worth no more than what you paid for it, and carries no warranty.

Now that we've gotten past the typical disclaimer surrounding the sticky Intellectual Property (IP) issues of committee- and group-owned technologies like Secure Digital (SD) memory and Secure Digital Input Output (SDIO) devices, we can take a look at what legal restrictions are actually in place. In this article we are going to focus on the IP issues and license requirements for SD and SDIO software stacks. We are focusing on the host side software stack that controls the host controller hardware, not the license and royalty issues of building memory or peripheral cards.

The IP needed to develop an SDIO stack is protected in multiple fashions: copyright, trade secret, patents, contractual license terms, and in some cases, royalties. The SD memory and SDIO specifications are maintained by the SD Card Association. There are currently in excess of 70 specification documents — including test specifications — available on the SD Card Association's members-only website. Wading through and understanding the committee-speak of these documents is the core job needed to understand how host stacks should behave and operate. There are simplified versions of the specifications available for downloading on the Association's website, but these lack required detail, and do not confer any rights for productization. To obtain the full specifications, you must become a member of the SD Card Association. When you fill out the membership application, you and your company will be required to agree to the IP Policy Agreement. This agreement is between you and the SD Card Association and their licensing arm, SD-3C, LLC. Paying for and obtaining these specifications only gives you limited rights to use them. Section 6 of the IP Policy Agreement allows you “to evaluate the Specifications internally for use in developing, designing, and/or manufacturing possible future products that are compliant with the Specifications (the 'Purpose').” This is clearly not a license to actually produce any products based on the specifications. Section 6 also extracts your agreement to maintain the confidentiality of the specifications.

So now that we've paid to look at the specifications, what do we actually need to do to obtain the licenses needed to ship a product? That brings us to the SD Host/Ancillary Product License, affectionately known as the HALA. The HALA is an agreement made between the software stack manufacturer (among others) and the SD-3C. It gives you the rights to use the Specification and Essential Patent Claims in your product, provided you meet the terms of the HALA. The HALA requires an annual payment to the SD-3C, and to the SD Card Association. In return for signing the HALA and depositing the much-appreciated fees, you get to use the SD Logo, and ship your products. The HALA requires that the product be compliant to the specifications, and allows for verification.

SD and SDIO card IP is protected via patents, trade secrets, and copyrights. If you follow the license terms, keep the IP confidential, and make your payments to the right parties, then you can legally ship an SD/SDIO stack.

We've looked at what hoops need to be jumped through for SD/SDIO cards, but what about MMC cards?

Why are there no open-source MMC stacks?

There are. The specification for MMC cards are managed by the MultiMediaCard Association. To obtain the specifications for MMC cards you must purchase them though the MMCA's website. If you are not a manufacturer of cards, then you agree to the NON-CARD MANUFACTURER LICENSE AGREEMENT. This gives you rights to a single copy and use of the specifications in “order to develop, have developed, test, manufacture, … sell, … distribute, … and import Products that are designed to be interoperable or compliant with Cards designed by third parties which are compliant with the Specifications.” In addition, you are specifically limited in the disclosure of the specification information: “without limitation, you shall not reproduce, modify, adapt, make derivative works of, sell, rent, sublicense, assign, transfer, or lease the Specifications (whether in whole or in part).” This would seem to cover the rights needed to develop an MMC software stack, but not make the content public. The MMCA does not seem to be actively enforcing these restrictions. Perhaps they are a little less closed and protective than the SD Card Association. The license does throw in one extra ringer. “The parties acknowledge and agree that licenses to certain third party intellectual property (the 'Third Party Intellectual Property') are required to use the Specifications to develop, … manufacture, … sell, have sold, … and import Products that are designed to be interoperable or compliant with Cards designed by third parties which are compliant with the Specifications.” The specific third party IP license needed and in what cases it is needed are not made clear. Open-source MMC stacks are commonly available, and as of yet don't seem to be getting any negative attention from the MMCA.

You really can't offer an SD or SDIO stack in open-source form and meet the licensing requirements currently in effect for these devices. Future licenses offered by the SD Card Association may be more amenable to open-source implementations.

Now, if you decide to go forward with your stack, open-source or not, it's time to pay for your own legal counsel.


About the author — Codetelligence co-founder and president Paul Lever previously co-founded BlueWater Systems, a Windows device driver, tools, and consulting company later acquired by Bsquare, where Paul served as chief technologist for products and director of platform technology, among other positions. Paul teaches a course on embedded and real-time operating systems at the University of Washington, and holds several patents related to embedded systems. He holds a BS degree in Systems Analysis from the University of Miami, and in his spare time, enjoys sailing his Jcruiser sailboat, Jeorgia (click photo at left for a look).


 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.



Comments are closed.