In March 2002 at the Embedded Systems Conference held in San Francisco, CA, the Embedded Linux Consortium (ELC) rolled out the requisite organizational infrastructure to allow it to begin developing embedded Linux standards. The ELC's primary effort will be to create what is being called the “ELC Platform Specification”, which will formally define a standardized core embedded Linux platform. Additional efforts are expected to focus on specific areas of system functionality, such as graphical interface, real-time functions, system boot processes, etc. In this interview, Mark Brown, Chair of the ELC's Core Platform Working Group, answers questions posed by LinuxDevices.com founder Rick Lehrbaum about the ELC's standardization process, and comments on the significance of the ELC's Core Platform spec . . .

---

Lehrbaum: Concerns have been expressed by individuals and analysts that insufficient progress toward a platform standard was made by the ELC between ESC San Francisco 2001, when the initiative was initially announced, to ESC San Francisco 2002, when the Intellectual Property Agreement was announced. Comments have been heard like: “If it takes the ELC a year to come up with a legal framework to do a standard, how long will it take the ELC to develop the standard itself?” Please comment.

Brown: We did not just produce a new legal agreement. We transformed the nature and scope of our organization. I believe that the hardest part is actually *behind* us. While it has taken some time to establish an organization, and ensure that members' business interests were properly represented, we can now proceed apace with the technical work of producing a specification. In the case of an embedded Linux platform specification, we of the Core Platform Working Group believe that rapid progress can be made because our maturing industry has evolved substantial de facto and formal standards that collectively form an ample basis for our effort. We have confidence in our ability to build a core specification by year's end. We've set an aggressive meeting schedule to facilitate this goal.

Regarding the evolution and creation of the Intellectual Property Agreement (IPA), this was managed by an Embedded Linux Consortium (ELC) Board with very broad interests — representing virtually all points of our long industry supply chain. This is relatively unique (most standards groups have a much narrower span), and when these interests are considered from the standpoint of complex open source and licensing legalities, critics could just as well have praised the ELC for achieving a consensus in that short a time!

Lehrbaum: The ELC's “IPA” is long and legalistic. Is there a simple document available so that members of the Embedded Linux *community* can understand what the IPA obligates them to, without them having to hire legal counsel to interpret it? Otherwise, it seems like the IPA could represent a barrier to entry for individual developers and smaller companies.

Brown: I (and others) agree that the IPA needs a set of Frequently Asked Questions and Answers to simplify understanding. The ELC is virtually an all-volunteer organization looking for some qualified individuals from our membership to help develop that set of FAQs. If no one steps up to the challenge, the ELC Board will have to find others ways to fill the gap.

Lehrbaum: Given the existence of POSIX APIs and the Linux Standard Base (LSB), why is there a need for an ELC Platform Specification in the first place?

Brown: This is an excellent question that acts as a springboard for the work of the Working Group. The simple answer is that vendors now “cherry-pick” API's and specification pieces from various certified and de facto standards. Also, the IEEE POSIX and Linux Standard Base (LSB) specifications do not cover some topics that embedded vendors are very interested in, so fragmentation is a real possibility. Each vendor acts alone, and the result is that vendors' claims about product compliance or compatibility are open to interpretation. It is not possible for this laissez faire approach to provide very good application or data portability, and the industry stands to lose customer confidence.

On the other hand, a core platform specification built by the negotiation and resolution process in a broad Working Group will result in a comprehensive standard, supported by a broad range of embedded systems vendors, so that marketplace confidence is bound to follow. The objective is simply to have “embedded Linux” mean exactly the same thing for any vendor's product that is found to be compliant with the specification. At the customer or user level, this means broad and growing interoperability.

Lehrbaum: Some have expressed a concern that an ELC Platform Spec could allow claims of 'compliance' by operating systems that are not actually derived from the base 'Linux' sources. Will this be possible? Since any kernel that is actually 'derived' from Linux would be subject to — and contain — Linux's GPL copyright, there seems to be an unambiguous way to know that a kernel is *not* Linux (i.e. if it does not contain the Linux copyright).

Brown: I believe that it is in the spirit of the Open and Free Source communities to “let the best source code win”, whether it is derived from Linus' code or not. Just as the IEEE POSIX standard does not require a UNIX source base, The Open Group UNIX specification does not require a System V base, and the LSB does not require a Linux source base, I do not believe the ELC Platform Specification (ELC PS) will or should require a specific source base.

The idea behind the ELC PS (and the LSB for that matter) is to allow for this “best source competition” to continue while at the same time giving the ISV and customer communities an assurance of portability and interoperability.

Any operating system environment that becomes *completely* conformant with our ELC Platform Specification enlarges the target population for middleware, development tools, and application software for fully conformant embedded Linux distributions as well. That is certainly in the best interest of ELC members, and for the embedded Linux community in general. History has shown that the larger the target population of systems, the richer the environment becomes. Consumers of embedded operating system environments will have complete freedom of action. They can choose the implementation that serves them best for each project. The ELC expects that they will choose a fully conformant embedded Linux distribution for most projects because of the well known advantages of working with that base.

Lehrbaum: Some Embedded Linux vendors might actually prefer that there NOT be an ELC Platform Spec, so that they can more easily differentiate their products. These companies might fear that the existence of an ELC Platform Spec would have a tendency to commoditize Embedded Linux and cramp their ability to compete based on their differentiation, making it appear that all Embedded Linux implementations that bear the ELC's 'stamp' of compliance are created equal. Has this attitude come up as an issue within (or outside of) the ELC to your knowledge?

Brown: If our industry has taught us anything, it is the lesson of limitations: an application vendor can afford to support only so many variations. A unified platform that enjoys exceptionally broad industry consensus is the best way to increase the richness of the application ecosystem.

There is also ample evidence that innovation enjoys its greatest success where a vendor's core competencies can be concentrated. System or Device vendors who have to devote engineering resources to operating system issues are not concentrating on their core competencies. Put another way, a unified ELC Platform Specification will stimulate rather than cramp. A vendor who relies upon a certified platform specification and related API's can be in the business of building server blades or set top boxes or industrial control systems or PDA's or middleware or smart appliances or telematics or whatever.

Standardizing the base allows everyone the freedom to innovate where it matters, while application vendors and customers can enjoy portability and interoperability.

Lehrbaum: It is difficult to envision consensus around such areas as real-time technology or APIs, or GUI/windowing environments. These both tend to be *hot* areas for diversity and debate — yet Embedded Linux has been criticized for having too much choice and not enough consistency in these areas. Are these two areas likely to be standardizable? What other areas aside from the basic Linux kernel services (a subset/superset of standard Linux) are likely to become subject of ELC standardization efforts, and what progress has there been in this regard following the call for proposals at ESC?

Brown: The Working Group intends to work towards consensus. Areas that are “hot”, as you call it — where there is no consensus — are areas that are probably not *ready* for standardization — there is no “standard” solution yet. It is not the primary goal of the Working Group to “invent” “standard” solutions for all areas, but rather formalize and specify areas of agreement among ELC members.

However, the ELC is looking at proposals in these areas and hopes to charter working groups to deal with them. On a more general note, many industry areas have diversity issues that are solved by “profiles” or standardized variations that are able to achieve consensus from a significant segment of the market. At the very least, efforts to build profiles often achieve a reduction in the noise and hype surrounding an issue — such as defining “hard real time” — and thus result in an overall benefit by clarifying distinctions and leveling the bumps in the playing field. The ELC wants to facilitate these efforts.

Lehrbaum: Any other comments you would like to add?

Brown: Yes. Some criticism has been leveled at the possible banality of a core platform. The criticism stems from an expectation that any broad-consensus operating system will be so general as to be too lightweight to function in specialized areas such as hard real time or industrial control or robotics or high availability. The ELC believes these fears to be naive and unfounded. Our efforts, expressed through working groups, champion just the opposite. Whether a particular application needs an extremely durable form of Linux or an exceptionally lightweight, reduced footprint Linux, the core platform and associated APIs will ultimately offer the solution.

Lehrbaum: Thank you very much!

---

---

 
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.