Re: [codec] comparitive quality testing

Roman Shpount <roman@telurix.com> Wed, 20 April 2011 01:17 UTC

Return-Path: <roman@telurix.com>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 706E5E07EF for <codec@ietfc.amsl.com>; Tue, 19 Apr 2011 18:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQPW29vsH1dB for <codec@ietfc.amsl.com>; Tue, 19 Apr 2011 18:17:25 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 15731E076E for <codec@ietf.org>; Tue, 19 Apr 2011 18:17:24 -0700 (PDT)
Received: by ewy19 with SMTP id 19so86885ewy.31 for <codec@ietf.org>; Tue, 19 Apr 2011 18:17:24 -0700 (PDT)
Received: by 10.213.109.213 with SMTP id k21mr2707614ebp.140.1303262244044; Tue, 19 Apr 2011 18:17:24 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx.google.com with ESMTPS id m55sm292621eei.22.2011.04.19.18.17.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 18:17:23 -0700 (PDT)
Received: by eye13 with SMTP id 13so87025eye.31 for <codec@ietf.org>; Tue, 19 Apr 2011 18:17:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.213.28.212 with SMTP id n20mr46032ebc.131.1303262243037; Tue, 19 Apr 2011 18:17:23 -0700 (PDT)
Received: by 10.213.98.83 with HTTP; Tue, 19 Apr 2011 18:17:22 -0700 (PDT)
In-Reply-To: <C9D37557.2AC4A%stewe@stewe.org>
References: <BANLkTik1DhJjUPYFtNL08gbSjqUB0KkLbQ@mail.gmail.com> <C9D37557.2AC4A%stewe@stewe.org>
Date: Tue, 19 Apr 2011 21:17:23 -0400
Message-ID: <BANLkTimnM6NsP-ZFP12CnY=wWmMmgLrxTg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Stephan Wenger <stewe@stewe.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] comparitive quality testing
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 01:17:26 -0000

One more interesting point is that RFC 3551 or the related IPR
releases do not include any mention of the GIPS freeware license. The
only mention is on iLBCFreeware.org website, which technically has
nothing to do with RFC and cannot be used to impose additional
licensing restrictions on the code. The only copyright notice present
in the RFC is to IETF which I assume means BSD, but might need some
historic clarification.
_____________
Roman Shpount



On Tue, Apr 19, 2011 at 8:45 PM, Stephan Wenger <stewe@stewe.org> wrote:
> Interesting information.  Two comments inline (after having removed a lot of
> valuable info).
> Stephan
>
> From: Roman Shpount <roman@telurix.com>
> Date: Tue, 19 Apr 2011 19:08:33 -0400
> To: Alan Duric <Alan.Duric@telio.no>
> Cc: "codec@ietf.org" <codec@ietf.org>
> Subject: Re: [codec] comparitive quality testing
>
> […]
> There is also a question of ILBC Freeware license. Based on IETF rules, all
> the code released as a part of IETF RFC should be covered by BSD license.
> The reasoning and applicability of iLBC Freeware license in this context is
> unclear.
> iLBC, and the drafts leading to the RFC, pre-date the requirement for code
> in RFCs to use the BSD style license.  Therefore, the authors had the right
> to license their code even in the RFC text under any license compliant with
> the then in force IPR documents, which were 2026 (overall procedures), 3667
> (for copyright), and 3688 (for patent rights).  I believe the RFC is in
> compliance with these documents.
> Further, no one requires an author to provide the IETF trust with an
> exclusive license for code portions of an RFC.  Therefore, anyone is free to
> make available code contributed to an I-D or RFC (and, thereby and for the
> purpose of this discussion, BSD-style licensed) also under licenses other
> than the BSD style license.  They just have to use a different medium than
> the RFC text.
> IPR disclosure for iLBC RFC was not updated when RFC was finalized and only
> has provisional patent applications, not the final granted patent numbers.
> I'm not aware of the nature of the patent rights, or their numbers, that
> were disclosed by GlobalIPSound.  I can't find such information in the
> disclosure.  That said, those with a bit of patent experience, access to the
> right tools, and and a few hours of time, can find the relevant patents
> covered by the disclosure with limited effort and reasonable certainty.
> Even today the IETF does not require "updates" of IPR disclosures beyond
> what is mandated in the rather generic language of the policy documents.
>  Some rightholders go at great length in keeping their disclosures updated,
> others don't.
> The really interesting question in this context is whether google finds
> itself bound to the promises made by GIPS at the time.  The policy documents
> provide no guidance on this topic, and this area of law is currently
> litigated in several venues, with (so far) rather inconclusive results.
> […]
> Stephan