<nettime> How Open Of A Standard Is MP3?

[Justin Couch <couch@ccis.adisys.com.au>]

How Open Of A Standard Is MP3?

By Justin Couch <justin@vlc.com.au>

The recent debate on /. [www.slashdot.org]
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 their
stamp on the resulting piles of dead trees that are a
by-product of such activities. As part of that
organisation's 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_
- resulting specification is open to anyone to
implement it from the specification.
- if IP is included in a standard, owners of patents
that cover ISO standards are required to licence the
patents in fair and non-discriminatory terms.

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 and was primarily used to cover
ISO's general expenses as much as printing costs.
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 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 current, 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't 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 through patents.

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. Typically, this is as a
library that is submitted as part of the spec.
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?)

What does having an officially labelled
"International Standard" buy you? Enforceable
security is one. If someone claims to implement ISO
Std XYZ but then extends it, or changes it slightly,
then lots of legal paperwork can come in that
company's direction _very_ quickly. Each standard
includes a minimum conformance section to make
sure of the level playing field. Should the open
source community come up with something
worthwhile (such as PNG) then an international
standard can be quickly forthcoming. The only
problem that you face then is that ISO likes to have
some formal body to represent the developers of that
spec - not particularly difficult given the thousands
of these that already exist in the opensource world.
Just some more formal wrappers are needed. This is
the unfortunate by-product of multi-billion dollar
companies meeting the hacker underground.

When dealing with the world of ISO standards, one
usually gets the impression of rooms filled with lots
of suits (but probably ex-hackers) smoking cigars
creating standards. In some areas this is certainly the
case, but in the computing industry this is far from
the norm. I've barely walked out of Uni having
survived EE/CS degrees and yet am writing an ISO
standard. No age problems here (just reached the
quarter century mark). So don't get too discouraged
about asking the impossible!

P.S. Slew attended many of the early MPEG
meetings and adds the following comments:

Nobody liked the MPEG audio license fiasco on the
committee, but this was a world wide effort and
some of the European countries strongly supported
the MUSICAM/MP3 standards even though many
others objected. In fact, members of the USNB
(United States National Body) just went and
bypassed the standard altogether when they made
their products.

That's why on DVD and HDTV in the US,
DOLBY-AC3 is used instead of MPEG audio. Even
though Dolby was proprietary, they have a long
history of licensing experience: Dolby-A, Dolby-B,
Dolby-C noise reduction, Dolby-surround-sound etc.

In addition, the MPEG committee is now in
development of yet another audio compression
standard that has more companies backing (AT&T,
Dolby, Franhaufer(sp?), etc.) which used to be
called NBC audio (not backward compatible), but
now called AAC (advanced audio coding). I don't
know what the licensing will be for this, but I'll bet
the MPEG committee won't make that mistake again.

Related links
ISO - http://www.iso.ch/
VRMLC - http://www.vrml.org/
Java3D based VRML browser - http://www.vrml.org/WorkingGroups/

[MP3 news: http://www.mp3.com/news/ (where this article appeared)
or http://www.wired.com/news/news/search_results_news?words=MP3

MP3 Walkmen:
http://www.mp3.com/hardware
http://www.diamondmm.com/rio/

.... ]

--
Justin Couch
Senior Software Engineer                           VRML-Java Author
ADI Ltd, Systems Group.
justin@vlc.com.au                    http://www.vlc.com.au/~justin/
-------------------------------------------------------------------
"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?"      -Suocomandante Marcos
-------------------------------------------------------------------
---
#  distributed via nettime-l : no commercial use without permission
#  <nettime> is a closed moderated mailinglist for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@desk.nl and "info nettime-l" in the msg body
#  URL: http://www.desk.nl/~nettime/  contact: nettime-owner@desk.nl