Recently, new attacks on the ELC's Platform Standard efforts have become rather public. Criticism has come from Karim Yaghmour in his new book, Building Embedded Linux Systems, and in his article on oreillynet, and in the… subsequent talk-back on linuxdevices.com by “Dwight”.

All of these attacks seem to boil down to the single complaint that the process for developing the specification was insufficiently “open”. I wish to address this. I am an active member of the ELC's Platform Standard Working Group and participated throughout the development of the ELC Platform Standard (ELCPS).

These are my personal opinions.

What is wanted?

It appears what is wanted is for the ELCPS to have been created by some kind of open forum such as a mailing list. Somewhere anyone could make suggestions for contents of the standard document. Also, I assume that means that the current draft of the document would be freely available for download by anyone at any time.

I agree that this kind of development approach sounds preferable to the one mandated by the ELC. The ELC requires that participants must both sign the ELC's Intellectual Property Agreement (IPA) and be members of the ELC. These requirements are naturally seen as burdensome to developers accustomed to traditional open source projects.

Traditional open source projects provide the means for anyone to download the software at any time. Those who download the software may modify their copy of the software and send the project their changes. The project can then accept the changes or ask for further modifications or public comment or whatever. It has been shown to often be a healthy and productive environment.

I am sure that some process like this could be employed to develop a standard for embedded Linux. For example, the LSB has such a mailing list.

Why was it not done this way?

The main rub is that the ELC wanted to avoid the SCO kind of problem. It wanted to make sure that nothing made it into the standard that was not legally available. I think most people now realize that freely accepting code contributions is potentially problematic – the issue is the same with any other copyrighted material. The ELC also wanted to provide a means where major corporations, potentially with quite a lot at stake, could safely contribute.

Granted, there is a fair amount of legal language in the agreement. But, in my personal interpretation, the most salient feature was the having to sign and say contributions I made could be used by the ELC without restriction. Here is a link to the “Intellectual Property Agreement” and the by-laws (PDF download).

Given the, I think reasonable, constraint that contributors need to put it in writing that they are free to contribute what they contribute, then what is to be done? The ELC decided to make folks sign a document that says they can contribute. That's in the ELC IPA cited above.

Is there some moral high ground in not signing such an agreement? Is requiring such signing necessarily nefarious? Is there no satisfactory justification for requiring the signing? Apparently, in the critics' view there is not justification. This is one place where I disagree with the critics. I believe the legal document is justified. I did not arrive at such a conclusion easily. My first reaction was the same as these outspoken critics.

I decided to go ahead and read it over carefully and decide for myself to what I was committing. After reading it I decided it made sense to sign, so I did.

Secondly, the ELC says one has to be a member. That may not have been necessary, but to be honest I didn't mind joining and since the ELC is sponsoring the effort it makes sense that participants be members. Further, since the ELC gives free membership to open source contributors it is cost free for most folks that could be the biggest contributors, such as Mr. Yaghmour.

The meeting that was referred to in the talkback was private to those that signed. If you didn't sign, and you came to the meeting, and you made a suggestion, and something like it showed up in the ELCPS then you could say the ELC took your idea. If your idea was not “open” or “free” then the ELC is in a bind. So, you can only come and comment, and in effect, affect the document, if you sign and say you're not going to hold the ELC hostage by giving something that the ELC can't really have. Are there proposals for some other safe method?

Again, think of the SCO situation. I'm not saying that there is SCO stuff in Linux, because I don't know. But, suppose that, at some point, there is some proprietary code copied into Linux because the code was accepted through the “open” process and now Linux is tainted. Not a good situation is it?

I commend the ELC for thinking ahead and requiring contributors to give their written assurance that their contributions would be legal and usable. This is not tantamount to deriving something proprietary. On the contrary, it was used to insure the exact opposite: the resulting ELCPS is freely available.

Anyone can contribute

My essential perspective is that the rules for being able to contribute were fair and made sense. Remember that I was the most vocal critic of the process in the beginning. For those that attended the announcement meeting at ESC I was the only (!) person that raised their hand as opposed to the process. I publicly accused the ELC of attempting to create a cartel — read the EE Times report. I then decided to contribute and not just complain. This is a “fish or cut bait” situation.

It's like if one wants Linux to have some capability. One can't just complain that Linux can't do it. Write it yourself. Of course, just because you write it doesn't mean that it will be incorporated. There is a protocol for contributions for projects like Linux too. That's what anyone could have done, as I did, with the ELCPS. I wanted it to be a certain way so I did the work to make it that way. This is what I meant by apathy and blind criticism (see my first talkback comment. It's the unwillingness to follow a protocol, and do the work, to get one's agenda considered; and it's an outsider's criticism when not looking into the details of the situation.

The value of the ELCPS

So, I think the embedded Linux situation now is that having consistency among implementations is valuable. A written guide to that is valuable. The ELC made efforts in that regard and makes it's “guide” available for free. The ELCPS document uses the GNU Free Documentation License. Download the ELCPS here. Approximately 10,000 downloads have been made of it. Hopefully, consistency and portability will be improved because of it. Thus, application developers for embedded Linux win.

If the ELC effort doesn't help because folks don't want to use its suggestions because it wasn't created in the manner they would have wanted, then, how is not using it being constructive? Now, if someone says they don't like the way it was done and they do a different one that may be constructive. Is someone volunteering? If someone examines the ELCPS and thinks, “hey, you guys shouldn't have done X” then hey, say so. What is it about the ELCPS that is distasteful? Say something. Or do your own standard. The embedded Linux industry will benefit if we get some work done here.

As I see it the purpose of the ELCPS is to make a suggestion as to what an embedded Linux system should provide. It does not require it. No one says do it this way or you're a bad guy. If you don't follow its advice you can still call your system embedded Linux. We're saying is, hey, if someone does it this way (or more) and says so, then you, you application developer, can depend upon the stated functionality being available. The winners here, as intended, are application developers. They don't have to join anything. All they have to do is read the ELCPS and not use any functionality not required. That's the goal of the ELCPS.

What is an application developer to do without such a suggestion? Sure, someone else can make a suggestion, a “standard”, fine. In fact, you know, it would have been easier for me if someone else had done it then I wouldn't have had to spend so much of my own time and money to help with this effort. But, no one else did do it.

Now, let's say you want to make your own embedded Linux device. It may be prudent to construct it in such a way that third party software will run on it. If you want third party software to run on it then what functionality should you make sure to provide? Hey look, there's a free suggestion to use, cool! You benefit too.

There is nothing in the ELCPS that either is not already available in open source, such as in the Linux kernel or GNU libraries, or wasn't invented new just to provide some convenience to applications wishing to query about ELCPS conformance.

Details of concerns

When I first opposed the ELC's effort the following were some of my concerns. I suspect the critics in the open source community such as Mr. Yaghmour, and “Dwight” share some of them. I am certainly interested to find out what other concerns may be prevalent as well so that they can be addressed.

(a) Because of the “closed” nature of the ELC's process it was possible that one or more participants incorporated requirements in the ELCPS that were selfishly motivated. Features may be included that were not in the best interest of the goal of providing an embedded Linux standard to support application and middleware development. Maybe an effort was made to drive implementers to a particular organization's way of doing things. Maybe an effort to standardize on some company's method was included. This certainly happens with other standards. This is a reasonable concern. Frankly, this was perhaps my greatest concern and a major reason why I joined the working group. I wanted to prevent such a thing from happening.

(b) By having a “closed” process insufficient effort and talent was available to craft the best possible standard.

(c) By having a “closed” process the Linux community would naturally be suspect of the results.

(d) The ELC is doing this just to justify its existence, to try and control the industry, to give a real incentive for membership, or some other selfish goal.

Let me address these.

Point (a) — I do think some organizations may have wanted to do this. There certainly is some temptation to do so. There is a contrary incentive to not do so as well. If one's goal is to expand embedded Linux as much as possible there is a disincentive to incorporate limiting requirements – requirements that don't have the best technical justification. I thought a lot about whether requirements may be misguided. I considered it with every feature that the ELCPS contains. I simply can't see any evidence of misguided features. Can you? I know there are explicit features of the ELCPS that try to prevent it.

For example, it is explicit that no particular implementation method of the specifications is mandated. One may use the GNU C library, for example, or some other library. It doesn't matter as long as the required functionality is provided. Secondly, the LSB and existing practice are incorporated. I personally see no component of the ELCPS that requires any functionality that is tilted toward any particular implementation. Further, the ELCPS doesn't really break any new ground. It doesn't incorporate anything that's not already POSIX or LSB except for a couple of completely new, ELCPS specific things.

Point (b) — Agreed. The ELCPS is not the best possible. If someone wants it to be better then they should help. I pleaded with folks to help and I still do. That is part of the point of this article. You can help make it better.

Point (c) — Of course the community is suspect. Read my “cartel” comments. Naturally folks are going to complain as are My. Yaghmour and “Dwight”. I think they should move past that. Look at the facts. Has anyone tried to participate and been refused? ELC membership is open to anyone. Can anyone name someone that was not allowed to join or to participate in the Platform Specification process? I certainly don't know of anyone.

From what I can tell folks look at the legal document and/or membership and say “The heck with that I'm not helping under those circumstances.” I say, if you want to contribute it is not much to ask and I've tried to explain that that they are reasonable requirements. If you feel that they are unreasonable then don't contribute – but don't denigrate the integrity of the result just because you were not willing to agree to the requirements. Complaining about the result is fine and useful, but complaining about the legal requirements, which are not discriminatory, is not only not useful, it is destructive to embedded Linux.

Point (d) — I believe the ELC leadership did promote this effort to help to justify its existence, and to give incentive for membership. I would say that is called “added value”. I don't think there is anything wrong with an organization doing a lot of hard work so that it is justifying its existence. If an organization is justified in existing it is because it accomplished something worthwhile. Bravo! Similarly, an organization accomplishing something worthwhile so that there is some value in being a member is also obviously justified.

Now, did the ELC leadership, or the Working Group pursue this project so that it could in some way “control” the industry? To perhaps hamper others, that were not members, or leaders of the ELC? Was it a conspiracy? May be this was the intent. Control of an industry does sound tempting. I don't see any evidence of this either, though. What new, essentially not already freely available, components are in the ELCPS? What is there that allows for any kind of control? The only new stuff is functionality to query what environment is supported and some required header information. The ELCPS either contains freely available Linux stuff or stuff that didn't exist before. There is nothing required by the ELCPS that is available in only a limited way.

What next?

Now, while we're on the subject of the ELC and standards let's consider what the ELC could do next. There is interest in standardizing functionality that is not already present, or perhaps common in Linux. This is an area that is more problematic. What if there are competing, proprietary solutions to some important problem, such as, say, real-time response, that vendors push the ELC to adopt in some new standards effort. That will be tricky. That is not the case, however, with what was covered in the ELCPS. Read the ELCPS and see.

Keep in mind, also, that if we want vendors to step forward and offer their proprietary solutions for important problems, they will need to be assured that if the standard does not adopt their method that they will be free to retain the rights to that method. The ELC Intellectual Property Agreement provides for that as well. Do we expect that the solution to every important problem is going to come from open source contributions? Or, will it make sense to adopt a solution based upon an already existing, proprietary solution, contingent upon it becoming open sourced? Note I did not say a patented solution. We don't want to go down the same road as the W3C did in its prior acceptance of patented technology. Is it wrong for a standard to adopt, perhaps with some modifications, the solution of a commercial entity just because it wasn't created in an open source manner?

There are important standards that were based upon commercial inventions. That's the way the standards world often works. I think that's why the fear about the ELC adopting some vendor's solution is natural. Sure it's the case that sometimes a vendor will try to heavy-hand a standards effort. But, where is there any evidence of this in the ELCPS?

Are we going to stand around criticizing the ELC's effort because it wasn't open enough, are we going to make a new effort, or are we going to support and improve the ELC's effort? Is there another choice besides these or apathy?

So far, the only criticism of the ELCPS I've seen is that folks aren't happy because the process wasn't open enough or because it didn't include more.

So, now, what constructive things can be done? Here are some suggestions for those of you that want to advance embedded Linux. I don't really see where just complaining about the ELCPS process helps. If you want the process to be different — then make it different. Remember that I tried just complaining at first, too.

1. Define a new standard and specification.
   
2. Create components of a test suite to help with compliance testing. Personally, I would appreciate it if you would let the ELC's Platform Standard Working Group use them too.
   
3. Comment on the ELC's Platform (ELCPS) Standard's features. Find something you like or don't like and make it public.
   
4. Use the ELCPS in your decision making.
   
5. Publicly say that you support the ELCPS and you plan to consider it in your decision making.
   
6. Write some code. Enhance embedded Linux and contribute it.
   
7. Write some documentation or other informative piece and contribute or publish it.
   
8. Encourage adoption of the ELCPS publicly or privately.

Thank you for reading. Drop me a note and tell me what you think.

— Kevin Dankwardt / [email protected]

[The opinions expressed in this column are those of the author, not of LinuxDevices.com or its management.]

---

About the author: Kevin Dankwardt is a LinuxDevices.com Contributing Editor and is founder and President of K Computing, a training and consulting firm. He has spent most of the last 9 years designing, developing, and delivering technical training for such subjects as Unix system programming, Linux device drivers, real-time programming, and parallel-programming for various organizations world-wide. He received his Ph.D. in Computer Science, in 1988.

---

Talk back!

Do you have comments or questions on this topic? talkback here.

---

 
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.