Re: [rtcweb] H.261

tim panton <tim@phonefromhere.com> Wed, 27 November 2013 17:02 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D31ACC91 for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 09:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU0NS5M4oz9w for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 09:02:38 -0800 (PST)
Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id A42C61A1F6F for <rtcweb@ietf.org>; Wed, 27 Nov 2013 09:02:37 -0800 (PST)
Received: (qmail 80152 invoked from network); 27 Nov 2013 17:02:36 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 11633
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Nov 2013 17:02:36 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 514F418A0243; Wed, 27 Nov 2013 17:02:36 +0000 (GMT)
Received: from [192.168.157.132] (unknown [192.67.4.35]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id EC84018A023A; Wed, 27 Nov 2013 17:02:35 +0000 (GMT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: tim panton <tim@phonefromhere.com>
In-Reply-To: <CEBB59D2.AAFE2%stewe@stewe.org>
Date: Wed, 27 Nov 2013 17:02:35 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F64B67E-A22C-45F4-9986-63DAE582D6BF@phonefromhere.com>
References: <CEB4350B.1E7B2%mzanaty@cisco.com> <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <529569C1.5010909@bbs.darktech.org> <CEBABA4F.AAF51%stewe@stewe.org> <5295828A.4050506@bbs.darktech.org> <DFE8489F-D483-44AE-8612-5106A2981BD6@phonefromhere.com> <CEBB59D2.AAFE2%stewe@stewe.org>
To: Stephan Wenger <stewe@stewe.org>
X-Mailer: Apple Mail (2.1822)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 27 Nov 2013 17:02:40 -0000

On 27 Nov 2013, at 16:41, Stephan Wenger <stewe@stewe.org> wrote:

> Hi,
> 
> On 11.27.2013, 08:03 , "tim panton" <tim@phonefromhere.com> wrote:
> 
>> 
>> On 27 Nov 2013, at 05:26, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> 
>>> On 27/11/2013 12:07 AM, Stephan Wenger wrote:
>>>> If I recall correctly, someone asked for a more concrete definition of
>>>> a licensing "unit".
>>>> StW: I do not recall the context, but MPEG-LA licenses (in addition to
>>>> content, which is not at issue here) a thing called ³codec², which is
>>>> defined as one encoder, one decoder, or one encoder and one decoder.
>>>> /StW
>>> 
>>> I don't think that answers the question. It was my understanding they
>>> were asking what constitutes one unit (out of the 100k free units we are
>>> allowed per year). For example, should we be counting the number of
>>> installs? Or number of concurrent users (e.g. what happens when a user
>>> installs the software on 5 machines but only runs one at a time?)? Or
>>> number of downloads? What happens if the same user downloads the app 100
>>> times? When users uninstall the app, do we get a unit back? The point
>>> is, we need a very concrete definition of how to count units.
>> 
>> Or even more fun, if you install an update of the app, say once a month,
>> that¹s 12 units per year per user - Or am I misunderstanding the Œunit¹
>> thing?
> 
> You guys are discussing MPEG-LA FAQ and agreement interpretations.
> Therein, there is no such thing as a ³unit² in the context you use it.
> When discussing hypothetical interpretations of an agreement text most of
> you obviously have never seen, let¹s at least try to stick with
> terminology that is known to exist in the agreement.

My example was lifted from the direct experience of a startup I know who
were indeed charged license fees for every upgrade by the MPEG-LA. 
They ended up shipping partial patches that re-used old binaries to
avoid this issue.

But you are correct I have not read the license.

> 
> Broader point:
> 
> I doubt very much that you will get an authoritive answer to the those
> broad interpretation questions from MPEG-LA, even if they were formulated
> in a precise and concise way (which, currently, they certainly are not).
> MPEG-LA commonly doesn't want to go public with their own interpretation
> of the agreement, and prefer to do so only with consent of the licensor
> group, which is harder to obtain than herding cats because of the very
> diverse nature of the licensor community.  One motivation of this silence
> may be the fear of weakening the license by making public statements about
> its interpretation that may provide openings for sharp company lawyers to
> cheat out of their licensing obligations.  It¹s a common theme in the
> legal community: say as little as possible.
> 
> What can be done, and is (so I understand) not uncommon, is that a company
> (a prospective licensee, but not a ³community²) contacts MPEG-LA directly,
> explains their business model, and asks how that fits within the agreement
> language.  This process can result in a side letter that includes an
> interpretation of the agreement language tailored to the business model of
> the company.  Those side letters are confidential.  The agreement itself
> is AFAIK take it or leave it.
> 


This is the kind of restrictive thinking that was common place before the web.
Back in the day, if you wanted to use the Nortel SDK, you had to apply to use it, handing over a
detailed app description and business model  to them, which might or might not be 
‘accepted’. 

Tim.