Re: [codec] Updated Charter Proposal Take 2

[Stephan Wenger <[e-mail]>]

Hi,

I have two comments with respect to IPR and deliverable 3 (and a possible
hidden IPR aspect), and a third comment re timing.  Both IPR related
comments have been raised before, but let me re-iterate them:

First, it is my understanding that the language in the charter related to
IPR is in full compliance with the relevant BCPs, and, therefore, I cannot
have a hard objection based on process or policy violation.

Still, explicitly citing only one of many preferences and rules of BCP 79 is
clearly setting the tone in one direction, and may discourage contributions
by those whose business model is not overly aligned with this very section
of BCP 79 (but fully aligned with others).  It would be easy to selectively
quote other parts of BCP 79 supporting a completely different business
model.  For example, I could quote (in isolation) section 3.1: "General
Policy / In all matters of Intellectual Property Rights, the intent is to
benefit the Internet community and the public at large, while  respecting
the legitimate rights of others."  Or, to be more specific, wouldn't the
inclusion of the second sentence of section 8 (from which you have taken
only the first sentence) also create a more balanced picture?  It reads: "
But IETF working groups have the discretion to adopt technology with a
commitment of fair and non-discriminatory terms, or even with no licensing
commitment, if they feel that this technology is superior enough to
alternatives with fewer IPR claims or free licensing to outweigh the
potential cost of the licenses."

I continue to prefer not to mention the IPR topic at all (which is the norm
in IETF charters), or state the required compliance with BCP 78 and 79
without further commentary, interpretation, or citation.  Please consider
this input.

My second issue is a bit more subtle and (I fear) quite a bit harder to
understand (especially for those not at least somewhat familiar with open
source licenses), but may also be more critical.  It relates to the hard
requirement for code.  In parts, I have already discussed the problem in my
messages sent around 7/15, but let me explain once more.

At present, the RFC editor, per a requirement set by the IETF trust, inserts
a BSD-style license template into the source code.  This templates include a
phrase "[...] Redistribution and use in source and binary forms, with or
without modification, are permitted [...]".  There are scholars and
corporate lawyers (I personally know quite a few of the latter) suggesting
that this language---specifically the unqualified use of the term
"use"---may imply a patent license grant.  In my recollection, supported by
the private conversation I had around this topic, allowing such an implied
license was not the intention of the IPR WG at the time, but we may still
have it.  It would not be the first mistake we made in the RFC 5378 mess.

A few of us more sensitive to these matters have started discussing this
problem with the IETF trust.  I do hope that we can find a solution that
makes those of us sensitive to implied patent licensing comfortable.  There
are a number of ways how this can be done, but I think this is not the right
forum for this discussion.  Personally, I believe that all those ways
require some form of a public statement by the IETF trust and/or its lawyer.
At this point, no such statement has been made.

The charter currently requires source code for the codec.  Quoting from the
draft charter, section deliverable 3: "There MUST be a text description of
the algorithm as well as a reference implementation.  The reference
implementation MUST be compliant with BCP 78 and BCP 79."  I object to the
code requirement on the procedural ground that it may imply  the grant of an
implicit patent license by anyone contributing to the I-D and/or the code
part thereof, which can be seen an introduction of a royalty-free licensing
requirement through the back door.  This is currently a hard objection, and,
if the subject is not resolved, I will go down the appeals process.

However, I do hope very much that a viable solution can be found by the
trust, which may be anywhere from a good legal argument by the trust to
convince me that this is a non-issue to a change of the outbound license.
If the trust finds such a solution, I will promptly remove my objection.

As a quick solution to this mess, I would suggest the following change in
the charter language (which would give those parties interested more time to
work with the trust on a "permanent" solution---famous last words :-)
"There MUST be a text description.  There SHOULD be a reference
implementation, which MUST be compliant with BCP 78 and BCP 79."  If that's
not acceptable, then I would suggest to split documents: text description in
one standard's track RFC and a reference implementation in another, whereby
the reference implementation MUST be derived from the textual description.
This would allow interested parties to contribute to the text version only,
thereby practicing code hygiene and avoiding implicit patent licensing.

As said, I will remove this objection promptly as soon as a satisfactory
solution is found, at which point I would have no problem in going back to
the (technically sensitive) choice of requiring reference code.

Finally, the timing.  Rarely I have seen such unrealistically ambitious
milestone goals.  In other SDOs, setting the Terms of Reference (Codec
Standardization Guidelines and Requirements are the equivalent) is a process
that can take many years. In fact, it's the hardest part of the whole
exercise, as every interested party will try to fine-tune the requirements
to their preferred technology.  I have witnessed some of this maneuvering
even on this very mailing list.  This is not only an IPR game, it also
covers other very legitimate interests.  Attempting to run such a process in
half a year cannot lead to good results.  IMHO, it WILL lead to
rubberstamping.  Please give yourself at least a year for the requirements
and procedures work to get those right.  I don't care how quickly you speed
through the codec specs themselves.

Regards,
Stephan
 
 




On 7/28/09 11:17 AM, "Jason Fischl" <[e-mail]> wrote:

> Jean-Marc and I have put together an update to the charter based on comments
> received privately and on the mailing list as well as input from Cullen and
> Greg. 
> 
> The key updates are:
> - added a motivation section
> - clarified the IPR section
> - added Codec Standardization Guidelines deliverable
> - added more detail for all of the deliverables
> - added specific milestones
> 
> --------------
> DRAFT CHARTER:
> 
> Motivation:
> 
> There is interest and value in having widely, easily distributable and
> accessible codec technology from the Internet community. Codec experts from
> both within and outside the IETF community have expressed an interest in
> contributing effort in this area. The IETF standards process provides a
> model for producing standards that encourages transparent design and open
> collaboration early on in the process. Any IETF codec designs that may
> emerge will also benefit from input and review from other RAI working groups
> and other areas of the IETF.
> 
> Goals:
> 
> The goal of this working group is to standardize audio codecs that can be
> implemented, distributed, and used broadly, and be interoperable between a
> wide set of interested parties. The group is chartered to work on audio
> codecs for interactive communication over the Internet. Codecs optimized for
> very low bit rates or for non-interactive audio are out of scope. The codecs
> should address the following technical considerations:
> 
> * suitability for most fixed-point DSPs;
> * medium- to high-quality speech at moderate bit-rate;
> * high-quality music encoding at higher bit-rates;
> * sampling rate profiles from narrow-band to full audio bandwidth;
> * real-time adaptive bit rate;
> * source-controlled variable bit-rate (VBR);
> * low algorithmic delay;
> 
> Beyond technical considerations, IPR issues will be handled in accordance
> with BCP 78 and BCP 79. Specifically, many existing codecs with the
> technical attributes listed above are encumbered with licensing fees and
> other IPR claims that make royalty-free and wide distribution and use across
> the Internet community difficult. The working group will try to standardize
> codecs that can be relatively freely and easily distributed, and employed as
> much as possible. In doing so, it will adhere closely to these BCPs. More
> specifically, "In general, IETF working groups prefer technologies with no
> known IPR claims or, for technologies with claims against them, an offer of
> royalty-free licensing." Note that in accordance with BCP 79, this working
> group will not explicitly rule out the possibility of adopting technology
> that does not meet these IPR requirements; the decision will be left to the
> normal rough consensus of the working group.
> 
> Deliverables:
> 
> 1) Codec Standardization Guidelines - that define a set of metrics which can
> be used to evaluate a codec. These metrics would include complexity, quality
> vs bitrate, algorithmic delay, packet loss performance and footprint. The
> complete list will be specified in this document. An evaluation of these
> metrics should be considered by the working group in trying to come to
> consensus about proposed changes to one of the draft codecs. After a codec
> is finalized, these guidelines will be used to characterize the codec. This
> is an Informational track document.
> 
> 2) Requirements Document - that defines the application requirements of the
> resulting solution. The requirements will include the exact technical
> considerations, the scenarios that are being addressed and the assumptions
> about the Internet operating environment. This is an Informational track
> document.
> 
> 3) Algorithm descriptions for wideband Internet audio codecs. There MUST be
> a text description of the algorithm as well as a reference implementation.
> The reference implementation MUST be compliant with BCP 78 and BCP 79. The
> text description MUST indicate those components of the encoder and decoder
> which are mandatory, recommended and optional. For example, in some codec
> definitions only the decoder is specified whereas others have bit-exact
> specifications. This is a Proposed Standard document.
> 
> It is not necessary to produce a single codec that solves the entire range
> of scenarios. A codec may be approved by the working group without
> addressing all of the scenarios.
> 
> Milestones:
> 
> Jan-2010: WG LC on Codec Standardization Guidelines
> Jan-2010: WG LC on Requirements
> Jul-2010: WG LC on codec algorithm description(s) to IESG
> Mar-2010: Codec Standardization Guidelines to IESG (Informational)
> Mar-2010: Requirements to IESG (Infomational)
> Jan-2011: Submit codec algorithm description(s) to IESG (Proposed Standard)
> 
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec