I have already mentioned that MPEG had to deal with the software aspects of its work from very early on. The first MPEG-1 Video Simulation Model, fully assembled at the Tampa meeting in March 1990, was still a traditional textual description but, at the first Santa Clara, CA meeting in August 1990, the group started complementing the text of the standard with pseudo C-code. For people accustomed to write computer programs describing the operations performed by a codec with this means of expression was often more natural and effective than words.
In MPEG-1 and MPEG-2 times active participants individually developed and maintained their own simulation software. Some time later, as has been reported, the decision was made to develop reference software, i.e. a software implementation of the MPEG-1 standard.
Seen with the eyes of a software developer, the process of standard development in MPEG-1 and MPEG-2 times was rather awkward, because the – temporally overlapping – sequence of steps was:
- Produce a textual description of the standard
- Translate the text to the Simulation Model software
- Optimise the software
- Translate the software back to text/pseudo C-code.
But with MPEG-4 a new world came to the fore where the information technology mind set was in the driver\s seat. Software was no longer just a tool to develop the standard; it was becoming the tool to make many (even though not all) products based on the standard. Therefore a reversal of priorities was required because the standard in textual form was still needed – a traditional method of expressing standards cannot be changed overnight – but for many users the standard expressed in a programming language was considered as the real reference. This applied not just to those making software implementations, but also to those making more traditional hardware-based products and VLSI designs. Therefore it was decided that the software version of the standard should have the same normative status as the textual part. This decision has been maintained in alla subsequent MPEG standards.
Quite independently from the formalisation of the OSS rules that were already taking place in the general IT world, as recalled here, MPEG made the decision to develop the reference software collaboratively because
- Better software would be obtained
- The scope of MPEG-4 was so large that probably no company could afford to develop the complete software implementation of the standard
- A software implementation made available to the industry would accelerate adoption of the standard.
Finally, a standard that had two different forms of expression would have improved quality because the removal of an ambiguity from one form of expression would help clarify possible ambiguities in the other.
I certainly do not claim that MPEG has followed the OSI rules that define a piece of software as OSS. I am just saying that even within a peculiar environment like an SDO, driven by an industrial mindset, collaborative software development naturally ends up obeying similar rules. These are the first rules set by MPEG
- Every normative (decoder) and informative (encoder) component of the standard has to be implemented in software, except for external parts such as tools for shape extraction
- Whoever makes a proposal that is accepted must provide a software implementation and assign the copyright of the code to ISO
- ISO grants a license of the copyright of the code for products conforming to the standard
- Release of patents required to exercise the code is not required and users should not expect that the copyright release includes a patent licence.
For each portion of the standard, a manager of Core Experiments was also appointed. This manager integrated the code of the accepted tools in the existing code base. The following companies and organisations appointed a representative for the corresponding portions of the MPEG-4 standard.
Company | Portion of MPEG-4 |
Apple | MP4 File Format |
ETRI | Text-to-Speech Interface |
Fraunhofer | Natural audio |
Microsoft | Video code in C++ |
MIT | Structured Audio |
MoMuSys | Video code in C |
Optibase | Core |
Sun | MPEG-J |
In the table, “Core” is the portion of code on which all media decoders and other components plug in.
Unlike traditional OSS projects, only MPEG members can participate in the project, a consequence of ISO rules related to standards development. Discussions, however, are usually done on email reflectors that are open to anybody.
The so-called “copyright disclaimer” that is found on all the original MPEG-4 software modules establishes the following points:
- The role of the original developer and subsequent contributors to the software module
- The status of the software module as an implementation of a part of one or more MPEG standard
- The ability of users to obtain a free license from ISO/IEC to use the module or modifications of it in products claiming conformance to the MPEG standard
- warning to users that use of the module may infringe existing patents
- A liability disclaimer for developers, contributors, their companies and ISO/IEC for use of a software module or its modifications
- No release of copyright for non MPEG standard conforming products
- Full rights of the original developer to
- Use the code for its own purpose
- Assign or donate the code to a third party
- Inhibit third parties from using the code for products that do not conform to the MPEG standard
- Inclusion of the copyright notice in all copies or derivative works.
Of late some objections have been raised to the clause that MPEG-4 reference software should be licenseable only for “conforming products”. The first objection, the same that is made to OSS in general, is that access to the reference software may contaminate employees of a software company. The second objection is that the reference software of a standard should not have any restriction, e.g. it should be in the public domain. The response to this second objection is that an SDO is in the business of promoting its own standards, not to promote the public domain software philosophy in general, much less competing standards. Besides, having that clause prevents forking, a concern for software companies as we have seen before.
The joint project with ITU-T that led to the Advanced Video Coding (AVC) standard has prompted some changes to the reference software policy. The first is the possibility for the original developer of the code to simply donate the code without possibly identifying himself. The second is the possibility to reuse the code in other ISO/IEC and ITU standards. The latter covers the obvious case where, say, the DCT transform code can be reused in other standards that make use of the DCT.
The MPEG OSS approach has been extended to two other cases. One case was motivated by the fact that, while the reference software is intended to be “reference” (normative or informative as the case may be), it is not necessarily intended to be efficient. Therefore since December 1999 MPEG has been working on MPEG-4 part 7 that contains optimised code, e.g. software for optimised motion vector search, a computationally very expensive part of an encoder implementation, where savings of more than one order of magnitude can easily be achieved. Any implementer can take this code and use it under the same conditions as the rest of the reference software, with the added condition that optimised code should not require the use of patents in addition to those already existing for the standard reference software.
More recently MPEG has started using a slightly modified version of the Berkeley Software Distribution (BSD), a licence originally used to distribute a Unix-like operating system. This simply says code may be used for anything with the usual disclaimer that patents are not released.This new licence is particularly interesting for software companies that do not want to have liaibilities when using software not developed internally.