Should embedded Linux devices be "sealed" or "hackable"? One reader says the developer or manufacturer "needs to be able to control" products. The following is a response by Sean Lamont to Seth Schoen's letter suggesting that the customer should have control over embedded Linux devices. Seth's letter itself is in response to a letter from Sean that ran in the January/February 2002 issue of ELJ.

Perhaps the tone of my message was misrepresented; I'm not an advocate of closed systems per se, I'm an advocate of individual rights; I fully support the goals of the GPL and have for well over ten years. As a manufacturer, however (my company is working on a limited-market product), I'd like to both be in a position to support the GPLed product space and community and be able to protect my company's privacy rights. It's similar to my view on MP3 sharing technology; MP3s should be shared freely, cheaply and easily up to and including free distribution, so long as the author (not necessarily the copyright holder) has both knowledge of, and grants permission for, that distribution to occur.

Mr. Schoen is incorrect on a number of points. When consumers buy a product, they are bound by the usage guidelines of the licensing agreement of that product. In practicality, this means if I buy Windows XP, I do not have rights to duplicate it, run it on multiple machines or sell it; when I buy an embedded application, this usually means that I can't rip apart the box, hack the OS, add additional features, etc., unless the manufacturer has given me explicit or implicit permission to do so (such is the case with TiVo, who seems to have green-lighted such modification). Most hardware manufacturers explicitly prohibit reverse engineering.

While I agree in principle at the impossibility of obfuscating computer programs, there are certainly points of diminishing returns. If I'm running a piece of code on, for example, a PIC 16F84 processor with built-in MD5 encoding and tamper-resistance protection, this offers a much larger degree of intellectual property protection than an embedded Linux kernel where any attempts to modify the filesystem for this purpose must be explicitly made available under the GPL.

Like it or not, this last point is what is going to be of concern to manufacturers; the ROI has a strong perceived relation to the "freeness" of the entire code base of the product. If there's a perception, however incorrect, that an MD5-enhance 16f84 will give stronger IP protections than an embedded Linux solution, embedded Linux loses. And this is a bad situation all around because every product that utilizes a free operating system as its core both legitimizes the system and adds to its development. Most substantial Linux/*BSD product development efforts end up contributing back to the community through open-source code enhancements, etc.

I feel like my overall point was slightly misrepresented; not that you should hack it or seal it, but that a developer or manufacturer needs to be able to control in an appropriate way the flow of their own creations. If it's an open one, so be it, and all the better. If it's a closed one, which I believe is necessary in some segments of the business world (despite RMS's claims to the contrary), then why not have Linux be the best at that, too.

Sean T Lamont Innovative Communications