Re: [rtcweb] non-standard codecs

"David Benham (dbenham)" <dbenham@cisco.com> Mon, 30 July 2012 19:45 UTC

Return-Path: <dbenham@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CFE11E81D4 for <rtcweb@ietfa.amsl.com>; Mon, 30 Jul 2012 12:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrOTV8N-pSzA for <rtcweb@ietfa.amsl.com>; Mon, 30 Jul 2012 12:45:55 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1F11E81C7 for <rtcweb@ietf.org>; Mon, 30 Jul 2012 12:45:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dbenham@cisco.com; l=2559; q=dns/txt; s=iport; t=1343677555; x=1344887155; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AHxPKs6YwDHErFuRclzbnGE6vBRloo3TJG+WkhVrtlQ=; b=HMm2v8tHGWdnJjlYiUyEgfoIpZ/3rUYRWrd9+9cH50PgmQ7vAXZvX1Im Y6vnlUMyJtxqZNsRQvsYJb6FBm5Eq/oJGvNSdXs1xn9S2ZqqRJb1bP0Rm IpOG7wyQz4QLMWG7NRxbfg3ZaaaoBIOFrK6gsaTCrYJAxDU1TdPgL/ggr c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAPXiFlCtJXG+/2dsb2JhbABFuVOBB4IgAQEBBBIBJzgZAQgYChRCJgEEChEah2uZQ4EooA2LUIYpYAOWXY0TgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106731353"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2012 19:45:55 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6UJjs8W017178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <rtcweb@ietf.org>; Mon, 30 Jul 2012 19:45:54 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Mon, 30 Jul 2012 14:45:54 -0500
From: "David Benham (dbenham)" <dbenham@cisco.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Re: [rtcweb] non-standard codecs
Thread-Index: Ac1ui7Gvhxj2sIruSWaI0RPHqY7OBg==
Date: Mon, 30 Jul 2012 19:45:53 +0000
Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC5057FA8@xmb-aln-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.118.22]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001
x-tm-as-result: No--33.362900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] non-standard codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2012 19:45:56 -0000

>(It's, I believe, generally assumed now that FRAND commitments travel with
> the patent, just like a license.   Meaning that a troll cannot expect
> non-FRAND licensing terms for a patent that, at some point in time, was
> owned by a legit SDO member.  Many SDOs have updated their policy
> documents to ensure this, and there is also case law addressing this issue.)

To confirm Stephen's point, SDOs that have built in FRAND also have a "survivability" clause where even if the member leaves the SDO, the obligation/promise to license (FRAND, etc) essential patents for the spec developed up to the date of the member leaving 'survives' the termination of their membership.   This extra clause should never be left out because without it, members might be eager to get their IPR in a SDO's spec so they can later leave and subsequently try to extract a pound of flesh from the rest of the SDO spec's adopters.    Further, such an ex-member worth their salt would transfer that obligation along with that IPR if transferring to another company (via a sale, etc).

On 7.30.2012 08:05 , "Harald Alvestrand" <harald at alvestrand.no> wrote:
>> B. FRAND status. SDO IPR policies (and legal precedents) confer
>>important benefits to documents that have gone through a standards
>>process. Without this, potential IPR claims have no upper bound.
>To be precise, the SDO IPR policies confer important benefits in
>relation to the companies or individuals that were part of that SDO at
>the time of the standardization procedure.

I would go even further: most SDO IPR policies confer important benefits
in relation to patents and patent applications under control of a member
of the SDO at the time of the standardization procedure.

(It's, I believe, generally assumed now that FRAND commitments travel with
the patent, just like a license.   Meaning that a troll cannot expect
non-FRAND licensing terms for a patent that, at some point in time, was
owned by a legit SDO member.  Many SDOs have updated their policy
documents to ensure this, and there is also case law addressing this issue.)

It's also worth noting that in video coding, most major industry players
are actively involved in the FRAND-bearing standardization effort.  That
doesn't mean that there can't be any non-FRAND pledged patents reading on
a video coding standard, but the likelihood is low compared to other areas
of technology.

All that doesn't help the open source industry, but it helps the rest of us.

Stephan