Re: [rtcweb] H.264 patent licensing options

Roman Shpount <> Thu, 11 December 2014 10:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2558D1ACDDE for <>; Thu, 11 Dec 2014 02:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.578
X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6abzREAHwci5 for <>; Thu, 11 Dec 2014 02:19:14 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 106371ACDD1 for <>; Thu, 11 Dec 2014 02:19:14 -0800 (PST)
Received: by with SMTP id ex7so14022608wid.15 for <>; Thu, 11 Dec 2014 02:19:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cMq0sYH4nwXskRANdNs4o7ZKWs5DNNRSVebv4+DtTgw=; b=Aviahr5P3MSflyTDlelaqvO3WsfRWXbaZ2epg7Oz6h3iwzqELXsu0Mmx8SFc65riCQ S/Hpw2Z1qhqr5xZWi8pzo+wEE99Ua2KPV9VuWTLa3kfM5m97y0WRnx20HOlk6/wifoNn U03hgN7F4ClkQsM7hT3OiobtOM6+YN8SA/DtX06zjnzs/E6ojFacaCOK7C06khJNIB+V 78lgPHc4NbCpuHMock9rqxtVftEnuuzm2KgfYmlZst5WW8VrLeFTfy3+gJF6nfuol5UB oPljRdO+qaJUzWpx8leapT+05qYnCEXjCzcxcSZBoNTL7JNpHDzvVMl1nIE818p25gfV 6LaA==
X-Gm-Message-State: ALoCoQlRygMaUsIK3TJNaRyFLZ6KTd5zqOld+typWvvt6VnkbByX48sToW2SEk+OP3uKo2tqYQwA
X-Received: by with SMTP id n14mr21549828wiv.60.1418293151600; Thu, 11 Dec 2014 02:19:11 -0800 (PST)
Received: from ( []) by with ESMTPSA id p1sm1080081wjy.22.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 02:19:10 -0800 (PST)
Received: by with SMTP id bs8so14038197wib.4 for <>; Thu, 11 Dec 2014 02:19:10 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id ho3mr14459808wib.39.1418293150151; Thu, 11 Dec 2014 02:19:10 -0800 (PST)
Received: by with HTTP; Thu, 11 Dec 2014 02:19:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 11 Dec 2014 05:19:10 -0500
Message-ID: <>
From: Roman Shpount <>
To: Florian Weimer <>
Content-Type: multipart/alternative; boundary="e89a8f3b9daf66ffd70509ee1b98"
Cc: "" <>
Subject: Re: [rtcweb] H.264 patent licensing options
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Dec 2014 10:19:16 -0000

On Thu, Dec 11, 2014 at 2:24 AM, Florian Weimer <> wrote:

> This is about IETF policy towards RAND licensing.  It's a working
> group and IETF decision, not something that can be left to lawyers.

When discussing RAND terms in general, I would suggest reading something
like this
and then talking to your legal counsel.

Typically, as far as standards are concerned (this comes with a a huge
IANAL disclaimer), obligation to license IPR under RAND terms implies only
that some licensing terms will be offered for this IPR to anybody who is
willing to implement the standard. What these terms are is up to the IPR
holder. In a lot of cases, obligation to license under RAND terms is
meaningless and the actual licensing policy by IPR holders must be

In case of H.264, as far as our company is concerned, this implies that we
cannot license H.264 IPR. To work around this, we are planning to offer
H.264 in client software on the platforms where H.264 is provided by the
platform itself or via OpenH264. In both cases, we consider H.264 licensing
will be something that will occur between the end user and the platform
provider, or, in case of OpenH264, between the end user and Cisco. If end
users decides to ignore the H.264 licensing terms, as they typically do,
this is between the end user and whoever provided them with the H.264
license. We will not license H.264 ourselves or provide any H.264 licenses
from us to our customers. In anything that we license directly to our
customers or operate ourselves (which typically means professional
conferencing services), we are planning to support VP8 only and will not
claim WebRTC compliance. End points which implement H.264 only will not be
fully supported by the services we operate and would only be provided with
limited feature set that can be enabled based on peer-to-peer
communications or relay without the need for transcoding or
other H.264 related server functionality. This is why the currently offered
compromise works for us even though H.264 licensing policy is less then
Roman Shpount