This guest editorial by Jim March is based on the statement that he read at the annual meeting of the Embedded Linux Consortium (ELC) in San Francisco, CA on April 9, 2001. In it, March expresses his concerns relative to using GPL software in embedded system applications, and urges the ELC to propose a revision to the GPL in order to mitigate those concerns. March writes . . .

---

Interpreting the GPL for Embedded Linux

Let it be known that I am speaking for myself, and not as a voice for 3Com Corporation. That's the lawyer-speak? Even though Linux is only 10 years old, I'll take the liberty of saying it's in its “adolescent” years — it has developed somewhat faster than your average homegrown OS. But, like any teenager, it needs some guidance by some of the adults in its family — even if it doesn't think so.

Who are those “adults”? Are they the dozens, to hundreds of talented, but unpaid programmers around the world? Or, are they the professional programmers who have lived and died by their skills across the years? I would feel safe in estimating that among the people in this room, we exceed 25 years of professional programming per attendee. Most of us would count ourselves among that collection of “adults”.

As developers of product software, in particular, embedded software, we all face the necessity of choosing the environment for the next product's application. In the past, we wrote our application programs to link directly with the underlying hardware interface code, again of our own creation. This gave rise to an entire new industry, where some very smart professional programmers built proprietary Operating Systems, specifically for the embedded software environment, and sold licenses to the application developers.

This paradigm has worked for many years, and continues to work today for many applications. However, there are some growing concerns with this business model in today's market. First, when the license fees begin to exceed the cost of our development teams, our bean-counters start getting nervous. Second, when the proprietary Operating System comes without source, or with source at high expense, it frequently makes it difficult for the developers to debug esoteric code dependencies. Third, when discrepancies between OS code and application code are determined, the product developers are at the mercy of the OS supplier to track them down. Given that the supplier may be supporting dozens of customers, the elapsed time to resolve discrepancies may be measured in weeks — instead of hours or days, when source code is available.

But I'm preaching to the choir. You know all of this. So now, we come to the “biggie”. Intellectual Property. IP. We never like to divulge IP outside of our companies – even when protected by NDA's. That reluctance makes it very difficult to interface with OS suppliers when a discrepancy occurs between some of our IP, and their OS.

The answer, as we all know, has presented itself in the form of Linux. There are no license fees. Source code is available without any additional fees. When application/OS discrepancies appear, delays are solely determined by the skill of our own engineering staff. And we never have to share our IP with the OS developers? Or do we??

3Com, my employer, is currently investing large dollars per year just in basic support efforts for Linux, and Linux-based projects. This does not even include the expense in Linux-based product software. I am not real comfortable comparing 3Com to a goose, but the dollars constitute quite a golden egg. And, I'm sure we are not alone in this effort.

I, and my team, greatly respect the concepts and the value and the power of Open Source. I, personally, encourage both my support team and the product development teams we work with, to place the software they develop back into the Open Source community.

However, there are times when there is a clear competitive advantage to being able to withhold some IP from public scrutiny. If there is no reliable method of performing that censorship, then there is significantly less incentive to use that environment. And if the use of the environment is curtailed, then the need for capital investment (remember that Golden Egg?) and the talents of the professional programmers it buys, also disappears. The result? Lose-lose! The company loses access to a good platform, the Linux community loses access to professionally developed code that would otherwise be freely placed into Open Source.

Now, the GPL clearly states the conditions upon which additionally provided code must be declared GPL. I won't belabor the details with you. It also, sort of, declares the conditions upon which provided code may be declared non-GPL in a desktop environment; for instance, independently written, compiled, linked and saved loadable modules that are independent of the loaded kernel.

Most of us have extended that definition, in our own minds, to mean that if a module is designed to be dynamically loaded, post-boot, and satisfies the other independence criteria, then we have the option to declare it GPL or non-GPL. Therefore, if we have IP that we wish to protect, we can place it into such a module and declare the entire module non-GPL.

The problem, of course, is that in the embedded world the distinction of dynamically loaded code, as opposed to bootable code, becomes a bit fuzzy; particularly if there is no separate media from which to load the code in question. Why is it fuzzy? Because the GPL does not specifically address this problem. And, by not addressing the problem, it leaves the entire question, potentially, in the hands of litigating attorneys. And we all know what Shakespeare said about attorneys.

How do we fix this problem? How do we maintain the corporate motivation to continue investment in the development of this “teenager”? The simplest answer would be a revision to the GPL that specifically addresses the issue of embedded Linux, and clearly states how software may be maintained as non-GPL, providing a clear mechanism by which IP may be preserved.

Let's not kill the goose that's laying the golden eggs. Particularly since the eggs have only recently begun to appear. Let's encourage, and work with the Free Software Foundation to update the GPL in a manner that allows for IP protection when needed.

---

Author's bio: Jim March worked for the MIT Lincoln Laboratory in the late 1960's as a System's Programmer. While there, he began a 20+ year career in OS development for what became IBM's VM/370 Operating System. Positions ranged from a founding member of Interactive Data Corp. to president of March, Inc., a Silicon Valley consulting company. He has been the president of the San Francisco chapter of the Independent Computer Consultants Association (ICCA), and was the founding member of the Silicon Valley ICCA chapter. While consulting to 3Com Corporation, he accepted a position as a Sr. Software Engineer in their Network Systems Division in 1995. In 2000, March proposed to 3Com management the future consolidated use of Linux as the embedded OS of choice, and the creation of an internal Linux Support Center to assist the product teams in the best use of Linux. Today, March is the manager of the 3Com Linux Support Center, located in Grass Valley, CA. In this guest editorial, March speaks for himself, not 3Com.

---

 
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.