Re: [rtcweb] H.261

Stephan Wenger <stewe@stewe.org> Wed, 27 November 2013 16:41 UTC

Return-Path: <stewe@stewe.org>
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 5BCF01ADBF7 for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 08:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001] 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 IZRTHVv2eqS9 for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 08:41:38 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id B680A1ACCFE for <rtcweb@ietf.org>; Wed, 27 Nov 2013 08:41:37 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 16:41:33 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.113]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 16:41:33 +0000
From: Stephan Wenger <stewe@stewe.org>
To: tim panton <tim@phonefromhere.com>, cowwoc <cowwoc@bbs.darktech.org>
Thread-Topic: [rtcweb] H.261
Thread-Index: AQHO50Itstn9eh6B8EejB0XcQHHKMpoxfO0AgAADjQCAAAzFgIAABU2AgAAKLQCAAAdiAIAACBKAgAADOgCAAAJPgIAGwe6AgAACxID//5IBgIAAi4sAgACx+YD//4R3AA==
Date: Wed, 27 Nov 2013 16:41:32 +0000
Message-ID: <CEBB59D2.AAFE2%stewe@stewe.org>
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>
In-Reply-To: <DFE8489F-D483-44AE-8612-5106A2981BD6@phonefromhere.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [75.60.27.131]
x-forefront-prvs: 004395A01C
x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(51704005)(199002)(189002)(74366001)(36756003)(81816001)(76786001)(2656002)(87936001)(51856001)(50986001)(54356001)(81342001)(76482001)(81542001)(81686001)(46102001)(53806001)(56816003)(76796001)(56776001)(85306002)(80976001)(83072001)(74706001)(74876001)(4396001)(77982001)(19580405001)(59766001)(83322001)(19580395003)(65816001)(80022001)(66066001)(63696002)(79102001)(49866001)(74662001)(69226001)(87266001)(54316002)(47976001)(74502001)(31966008)(77096001)(47736001)(47446002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:75.60.27.131; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en;
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <F698E01D5F71844987D38FC584AFA1F9@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
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 16:41:41 -0000

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.

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.

Stephan

>
>T.
>