Feature:Explaining MP3/ISO Standards

Justin Couch (Mithrandir) writes "As one of the millions out there that use MP3 daily for work, and also as someone who writes ISO specs for a living I was rather interested in the article that got posted today about the disappearing MP3 encoder from 8hz. Almost all of the comments at least showed a lack of understanding of the ISO process so I thought I should write you an article on exactly what happens and how this situation comes about." Hit the link to read it.

Where ISO and Open Source Software Collide

The recent debate on /. about MP3 and 8hz has shown a lot of confusion in the community about how standards, standards organisations and software implementations mix. While I am not an expert on the entire inner workings on ISO, I do write an ISO standard as part of my day job, work on open sourced software, write programming books and play in the big arena of standards enough that I feel qualified to comment.

In the standards process, there are many players - ISO, IEEE, US DoD, W3C and many, many others. Almost all of these groups write standards by getting a group of interested people together, provide the discussion facilities (mailing lists, private news servers and other methods) and then place thier stamp on the resulting piles of dead trees that are a by product of such activities. As part of that organisations legal activities, they create a IPR policy that governs the hows and whys of IP in any standard that gets developed.

Since the current debate is about MP3 which is part of the MPEG ISO standard, in order to understand the current problems we need to look at how ISO runs.

ISO is a huge umbrella organisation for getting international standards together. As such, it has to straddle the legal boundaries of every country on earth. It is responsible for more standards than you or I could ever imagine. A common one that you are familiar with would be 9001 (engineering process standards). Others are JPEG and MPEG. For all I know they probably have standards on which direction to put the thread on a bolt. As you can see, they cover an extreme range of fields, many of which have no relation to software (could you imagine developing an open source bolt?)

The way that ISO works is that it looks for areas that may need standardisation and then brings together a team to do so. Usually it does this by contacting and attracting established leading players in the particular area and ask them to develop the specification to ISO standards (which involves the death of many more trees in the process). Other times an organisation might approach ISO and ask that they make their standard into an ISO one (an example is the recent Sun move to do this with Java). If ISO can see a reason for this it will usually start its own process. For example ISO might accept a submission because it does not have a standard covering the proposed area already or that many companies are crying out for something to be standardised in a formal way.

The problem that ISO is now challenged with - how do we define who "owns" the technology. If ISO is just a big enabling organisation (it is) then if it can't get buy-in from parties interested in writing standards then it will lose its strength. To solve this problem, ISO takes the attitude of letting each standards development group decide its own policy wrt IPR issues. The only legal requirement that ISO puts on the specification is that the spec development process must be open to _anyone_ and the resulting specification is open to anyone to implement it from the specification.

However, open is not exactly as you would define it. Until recently, a copy of any particular specification had to be purchased from ISO. Typically this was in the range of US$50-100 depending on the number of forests needed. Anybody may purchase a copy of the spec. Once you have a spec, you may do with it whatever you please - light fires with it, implement software/hardware whatever. If you wanted to implement the item defined by the specification, then you are subject to whatever that spec contains in its particular IPR clause. This can and often contains software patents. Part of the deal to get buy in of companies in a spec development is the ability to claim IP rights to part of the spec.

Writing an ISO spec is not a trivial exercise that can be thrown together over night. Typically, it takes lots of effort from many people. My almost fulltime job is writing one part of one specification (ISO/IEC 14772-2 VRML97 EAI). As someone who has recently been involved in the development of the MPEG-4 spec I can begin to tell you how much effort this takes. The MPEG4 spec is something well over 2000 pages and written by 40-50 people. My own VRML spec is 300+ pages and written by 10 people. These specs take time and research to come up with. At a $100K or more per year per person to work on this stuff you can see why companies are eager to protect their work with some form of recouping the money outlaid.

So why does MP3 cause such a problem. MPEG has an IPR policy that allows companies to claim certain parts of the spec as theirs - some of which may have involved getting patents on the technology. These patents usually exist before the standard is written. In the case of MPEG usually this has come from hardware implementations of the encoding/decoding but since commodity generalised hardware is cheap enough to implement many of the compression schemes, the patents now extend to software implementations of the algorithms as well. It is the algorithm + the encoded byte stream itself that is subject to the patenting. Therefore, by writing your own implementation of the encoding mechanism to produce the MPEG formatted stream you are effectively implementing the patent and thus subjected to any such claims (as is the case with 8hz).

To appear to be good members of their community, often these companies will provide an implementation of the encoding capabilities as a library that is free of charge. Therefore, if you use their library it won't cost you anything, but implementing your own will. This serves two purposes: The basic library provides a common reference implementation to compare against insuring a minimum level of compatibility, and, it gains them some influence on future decisions (meritocracy in a different form). For example - look at libjpeg.

How can the open source community work with this sort of system? The best answer to this is to look at the group I'm involved in - VRML. VRML was developed as an open community project. The original work was a modified version of a toolkit written by SGI that was pushed into the open domain with no strings attached. It then went through a couple of revisions to become VRML2.0. Nobody really owned VRML2.0. Sure the main authors were on the SGI payroll, but they answered to 2000+ vocal contributors. When the final spec was completed, it was decided to take it to ISO for formal standardisation. A lot of negotiating went on - the VRML spec was out on the web FOC to anyone. ISO would not be allowed to remove it from the web and make everyone pay for a copy of it. In return we maintained control of the development of the spec. (In many respects this parallels what Sun is attempting to do with Java). The VRMLC then controls all the development. As part of this we also had to come up with an IPR policy. In contrast to the MPEG group, we decided that all contributed technology shall remain unencumbered by patents. Recently we bounced a proposal for a binary formay submitted by IBM that contained patented encoding schemes. This part was only optional and there were libraries and everything supplied to anyone at no cost or hinderence on its use, however, the patent resulted in it being bounced because of our IP policy.

Recently, Sun donated their source code to the VRML community for a Java3D based VRML browser with no restrictions on it (even less than a BSD or X license!). A group of us have taken this code and run with it in our own implementation under the LGPL. It is still part of the VRML consortium work and is developed by the community. It is likely to become the core test bed for working groups developing other parts of the specification or recommended practices using the spec.

As you can see, even between ISO specifications, there is a difference in how IP issues are handled. If the open source community wishes to take advantage of this, then you'll need to get in and work the system to your advantage. We've done it once before with VRML, so there is no reason why it cannot be done again with new specifications. If you don't like MP3's problems, then a community driven effort is certainly possible and can work within international standards frameworks. You just need to find the right one to work with. You may have fun with ISO as they already have a standard defined for streaming media (MPEG) but it is always worth a try. PNG worked, why not for audio? (How about a streamed version of one of the MOD formats as an example?)

1. Justin Couch Senior Software Engineer VRML-Java Hacker ADI Ltd, Systems Group.

"Look through the lens, and the light breaks down into many lights. Turn it or move it, and a new set of arrangements appears... is it a single light or many lights, lights that one must know how to distinguish, recognise and appreciate? Is it one light with many frames or one frame for many lights?" -Subcomandante Marcos