Straddling the Boundary of Free and Proprietary Software

Cardinal Peak is currently developing an embedded product for a customer whose business is innovative lighting products. We have chosen to base the embedded system on Linux because it includes a wealth of infrastructure, it is open source and royalty free, and we have substantial experience with it. The embedded system is configured with an app that runs on both Android and iOS-based mobile devices. The app and embedded system communicate over TCP/IP or Bluetooth. So far, talking to Android has been a piece of cake. Talking to iOS, not so much.

Communicating with an iOS device over “Classic” Bluetooth — as opposed to Bluetooth Low Energy — requires that our embedded system includes an Apple-designed authentication chip. We gained access to these chips only after we acquired a license from Apple’s “Made for iPod/iPhone/iPad” (MFi) program. The license also provides a lengthy technical manual setting out the rules for interacting with iOS over various media, including Bluetooth. The first page of the manual makes it very clear that publicly revealing any of its contents is a violation of the MFi license.

Here’s the rub: The Linux kernel and many of its components are licensed under the well-known GNU General Public License (GPL). Among other things, the GPL specifies that any modification of its source code must be made public. So if we are required to make any changes to the Linux kernel or other GPL’ed components to allow our product to work with iOS, we’re required to divulge them. The MFi license, however, forbids us from revealing anything we learned in confidence from Apple. This potential conflict is apparently well known to Apple, judging from a mild caution I received in an email exchange with our Apple MFi representative in which I mentioned that we are developing a Linux-based product.

What’s a developer to do, forgo using a GPL’ed platform? Given the complexity of Bluetooth and other underlying technologies required for this product, developing it all from scratch was never an option. The other alternative is to pay royalties to build on a proprietary OS from a vendor who is also MFi-licensed. In addition to limiting the number of possible OS vendors, this would have been a tough sell to a customer who is sensitive to the cost of the product.

Here’s hoping we don’t have to modify some GPL’ed Linux code!