Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt]

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Oct 2009 14:59:58 -0600

My apologies for the delayed reply.

On 9/4/09 7:41 PM, Stephan Wenger wrote:
> Folks,
> I read through this draft and found it, all in all, a well written document
> covering a lot of (to me) agreeable aspects.  

Thanks. We have tried to incorporate most of your feedback into the
document.

> However, as you may expect, I
> have a number of comments, mostly on certain language aspects :-)  If this
> were a working group effort, I would phrase some of my suggestion below in
> stronger terms.  As things stand, you are, of course, free to ignore them...
> Regards,
> Stephan
> 
> 
> 1. Section 1 speaks in several places of "freely available".  I would
> recommend to be more precise.  There are just too many definitions, some of
> which contradicting, of what constitutes "freedom" in our business.

For consistency, we have changed all instances of "free" or "freely
available" (etc.) to "easily distributable" throughout the text.

> 2. Section 1: the above remark also goes for the definition of "open".  A
> very large part of the standardization people (perhaps a majority)
> associates "open" exclusively with "open process in the SDO" and not with
> what the draft implicitly assumes ("open" use, whatever that, in turn, may
> be).

We clarified the wording about this a bit.

> 3. Section 1, first bullet, "has inhibited": really?  I don't believe this
> claim is true---certainly not in the form as made.  At least, I have not
> seen a prove for this rather assertive statement.  Suggest softening the
> language.

I disagree. Certainly we received quite a bit of feedback before IETF 75
and at the Stockholm meeting about this topic, so I don't think it's
appropriate to remove it.

> 4. Section 1, final bullet: suggest replacing "will be freely available"
> with "may be available without royalties or other undue burden", as none of
> us has the means to guaranty something like "freely available".

In fact, here we really are talking about free distribution of software,
so we've left it the way it was, with a slight wording clarification.

> 5. Section 2.2, "preferably in the form of I-Ds".  I'm not aware of any
> other form of input but I-Ds on which a WG or a group of people without WG
> status in the IETF could act on (and that would allow documenting the
> complexity undoubtly involved).  Therefore, I would suggest to remove
> "preferably".  Also, publishing an I-D undoubtly triggers the BCP79
> disclosure requirements---unspecified input may not.

We've clarified this. There is input that is subject to BCP79 other than
I-Ds, such as mailing list posts and presentations at WG sessions.

> 6. Section 2.3: I read this section as a license to re-tune the requirements
> document based on results obtained by tests (or even theoretical analysis)
> of input proposals.  It may be necessary to do this.  However, you are
> certainly aware of that such a procedure can lead to gaming and other evil
> things (including unfair exclusion of proposals with IPR properties that are
> within the scope of the IETF's IPR policy).  If this were a working group
> charter, I would voice strong concerns over this vagueness.  For an informal
> activity outside a WG, I only appeal to you to be careful in what you are
> doing.

That is most definitely not the intent of Section 2.3. We've clarified this.

> 7. Section 2.6: to add something positive, I'm thrilled that people will at
> least attempt to work cooperatively on codecs from very early on: this is
> IMHO one of the really weak spots traditional codec standardization has had
> in most of its instances.  I'm also very happy to see the "no
> rubberstamping" sentence.

Great.

> 8. Section 2.7: developments of RTP payload formats happen in AVT.  No need
> to word around that.

Clarified to specify explicitly that this work will happen in the AVT WG.

> 9. Section 3: I'm missing a statement on what happens if it turns out that
> the requirements are NOT met.  I think there should be an end criteria of
> some sort.

I don't think we need a statement about this -- it is covered quite well
by existing IETF practices such as RFC 2418.

> 10: I can see value in a strategy of not requiring a bit-exact encoder (as I
> see a value in having such a requirement---in classic telco applications,
> for example).  However, I fail to see a value in not requiring bit-exact
> decoding.  Is this a fixed/floating point issue?
> The can of worms one the IPR side one is opening by not strictly defining
> conformance cannot be overestimated.  Almost every IPR statement in the IETF
> (and elsewhere) promises or grants licenses (or makes a non-assert covenant)
> only for conformant implementations.  I would strongly recommend to require
> bit-exact decoding, for that reason alone.  If you truly think that a soft
> definition of conformance is necessary from a technical viewpoint, then I
> would strongly recommend to at least define your version of conformance in a
> normative, permanent document (standard's track RFC) which includes the
> source code of the testing tool, and the test vectors against which soft
> conformance is tested.

We modified the text slightly here to clarify things, but retained the
preference against bit-exact encoders and decoders.

> 11: Section 5, first bullet, "open", see remark #2

Changed to "easily distributable".

> 12: Section 5, first bullet, "conspicuous gap", see remark #3

Unchanged, see above.

> 13: Section 5, second bullet "freely", see remark #1

Unchanged, because this really does refer to giving away software
without charging for it.

> 14: Section 5, fourth bullet, "free" , see remark #1

Changed to "easily distributable".

> 15: Section 5, "BSD license": it's not a BSD license.  It's *currently* a
> BSD-style license.  However, the IETF trust currently has control over this
> thing and could, in theory, change it.  Recommend to read the relevant
> documents and come up with a precise and future-proof formulation.  At this
> time of writing I do not have access to the documents in question (writing
> on a plane), but I can help in this.

Changed to:

   the BSD license or whatever
   license is defined as acceptable by the IETF Trust when the relevant
   Internet-Drafts are published.

> 16: Section 5, "royalty-free".  Finally, this reasonably precise term is
> used.  Why not earlier?  

Because royalty-free is one method for achieving the goal of easily
distributable. It is not, however, the only method.

> However, just before that, the subject of open
> source compatibility is mentioned as well (though not in this formulation).
> Please note that it is very easy to draft a patent license that is
> royalty-free and NOT open source compatible.  Similarly, I would argue that
> a good percentage of the RF licensing covenants in IETF IPR disclosures (in
> contrast to most non-assert covenants) are not compatible with the majority
> of the open source licenses in practical use.  If you wish to express a
> desire for compatibility with open source models, then you may want to
> express this early on, in precise terms, and not with ambiguous language
> such as "free" and "open".

This might need to be tightened up further.

> 17: Section 5, "20 years": as I have mentioned a number of times before: a
> novel combination of 20year+ old tools may be patentable in its own right.
> You may wish to add a sentence in this regard.

This text was tightened up a bit.

> 18: "infringing": it is in most cases unwise to use the term "infringement"
> unless you truly know what you are doing---even in combination with
> "unknowingly".  Suggest to replace "infringe" with "incur encumbrance" or
> something like this.

Done.

> 19: Section 6: I would suggest to remove this section in its entirety.  Some
> information presented may be seen differently in the cited SDOs.  For
> example, arguably, the low delay AAC effort is intended towards interactive
> work, and not storage.  Also, there may be SDOs not mentioned here which
> have (or have had) viable speech/audio coding efforts that may feel insulted
> by not being mentioned (3GPP2 come to mind, and some others).  As the very
> minimum, I would strongly suggest to "characterize" the other SDOs efforts
> using only their own (liaison-)statements or publications as a basis, and
> not your interpretation.

The authors think this section is very important, because it clarifies
the intent of the WG with respect to efforts at other SDOs and many
questions have been raised about this topic on the list and at the
Stockholm BoF. Those questions need to be addressed somewhere, and this
I-D seems to be the best place for them, especially to clarify the use
of existing liaison relationships.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Oct 2009 15:04:05 -0600

Again, my apologies for the delayed reply.

On 9/5/09 5:05 AM, Marshall Eubanks wrote:
> 
> On Sep 4, 2009, at 9:41 PM, Stephan Wenger wrote:

<snip/>

> There is no way to publish an IETF stream RFC without beginning as an
> Internet-draft and
> without the contributors agreeing to the IETF IPR rules. This is true of
> AD sponsored drafts
> as well as WG sponsored drafts. The disclosure rules definitely apply to
> all IETF contributions.

See the updated text. This was meant to include mailing list posts,
presentations at WG sessions, and the like.

<snip/>

>> thing and could, in theory, change it.
> 
> That is correct. Of course, licenses are granted to published text. I am
> not a lawyer, but my understanding is that these licenses, once granted,
> could not be made more restrictive retroactively.
> 
>>  Recommend to read the relevant
> BCP 78 and 79 apply to IETF contributions and IETF publications. Note
> that IETF licenses
> explicitly and only refer to copyright, not patent - RFC5378 :

The topic of the referenced text pertains to things that can be
copyrighted, not things that can be patented.

> 5.5. No Patent License The licenses granted in Section 5.3 shall not be
> deemed to grant any right under any patent, patent application, or other
> similar intellectual property right disclosed by the Contributor under
> BCP 79 [RFC3979] or otherwise.
> ---
> So, in the statement :
> In accordance with BCP 78 [RFC5378], the source code for the reference
> implementation should be available under the BSD license.
> I would take out "In accordance with BCP 78 [RFC5378],". If the
> reference implementation is published in an RFC, then IETF IPR rules
> will apply. If it is not, they will not.

Fixed.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 07 Oct 2009 15:27:58 -0700

Thanks, Peter.

I find most of my comments adequately addressed, and in some other cases we
can agree to disagree without another discussion at this point in time.  The

> This might need to be tightened up further.

Let me give it a try.  Replace the original paragraph

>    In accordance with BCP 78 [TRUST], the source code for the reference
>    implementation should be available under the BSD license or whatever
>    Internet-Drafts are published.  Also, in accordance with BCP 79
>    [IPR], the codecs should preferably use technologies with no known
>    IPR claims or technologies with an offer of royalty-free (RF)
>    licensing.  Compatibility with the licensing of typical open source
>    applications requires the avoidance of restrictive IPR claims.

With

"
In accordance with BCP 78 [TRUST], the source code for the reference
implementation should be available under the BSD-style license or whatever
license is defined as acceptable by the IETF Trust when the relevant
Internet-Drafts are published.

In accordance with the spirit of BCP 79 [IPR], the codecs should preferably
use technologies with no known IPR claims, technologies available under
patent non-assert covenants, or technologies with an offer of royalty-free
(RF) licensing (in this order of preference).  Among other goals, adhering
to these preferences should help achieving compatibility with the patent
licensing requirements of most open source licenses, thereby allowing for
open source applications of the specified codec(s).
"

Motivation:
1. BCP78 compliance of the reference software has nothing to do with
avoidance of patents of the algorithm, so the two should not be placed in
the same paragraph.
2. I added non-assert covenants.  As I mentioned before, non-assert
covenants are typically better for open source license compatibility than
mere RF licensing covenants, unless those RF licensing covenants are
intentionally worded to be friendly/compatible to open source.  Few of the
RF licensing covenants posted in the IETF's IPR database are open source
compatible at the time of writing (yes, I have reviewed all of them :-)
3. Expressing a preference of unencumbered-by-known-patents -> non-assert ->
RF-licensing-commitment makes sense as it increases the chances of a "legal"
open source implementation.

Regards,
Stephan

P.s.: Please note that I'm sending this in order to help you guys to express
what I believe are your intentions.  I haven't changed my mind on viability
of the exercise proposed, nor on my preference of the choice of venue for
codec development.

On 10/7/09 1:59 PM, "Peter Saint-Andre" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrNAU4ACgkQNL8k5A2w/vxnhQCgr6CkWBFgb66+4JH/cGytmZsU
> ZgcAoPwT22sH7KGcPsBmAhF+tzQks6No
> =E6pm
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Oct 2009 16:57:49 -0600

On 10/7/09 4:27 PM, Stephan Wenger wrote:
> can agree to disagree without another discussion at this point in time.  

OK, that seems reasonable.

> The

Thank you for your suggested text.

I am not a lawyer and even when I think about "IPR" issues it is in
relation to copyrights, not patents, so I will need to do a bit of
research and thinking before I am comfortable adding the text you have
provided. On the face of it, your text does seem to capture the intent
behind the current text, but I just want to give it a bit more thought
before I make any changes to the I-D.

> of the exercise proposed, nor on my preference of the choice of venue for

Fair enough. I appreciate your generosity.

Peter

- --
Peter Saint-Andre
https://stpeter.im/