Re: [rtcweb] cisco binary on ec2

cowwoc <cowwoc@bbs.darktech.org> Tue, 26 November 2013 20:51 UTC

Return-Path: <cowwoc@bbs.darktech.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 5C73C1ADFA9 for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 12:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 PVFGuTHoRErn for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 12:51:00 -0800 (PST)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 240EF1AD942 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 12:51:00 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id tp5so10257853ieb.11 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 12:50:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jGigTTK0hHLy6FrV+xZwGZxK8ALeivjJz67qW+YH6r8=; b=LFExaBPmEpbYE03chcmttYwf1u5f3UpLMLVlkluoama9ijzAHrSCbQWSc0vWl2t2oU A9nLVMcT1iis/mY6Cnq+oCKmL0qdpuXmaSI1FLjCXIJ4AM77IDV5fJ3v7mm97WibNcbC /QQ4eUzXoO4Ic8ma3Sff8ssDe0XSXNi4SXTbBFYUB+5+y0N0iHpWcbP3WnbTooLWZ5IO t3A5QrCa6Tp6Q/9ZrR/5alSDjK95iGlK1pVB8Cua6Y/Me1aftoPmkIt6q5eqpW8kbCSM YsKwm5126su8JhhDpgwykE7coTL5OGDp0nETM8Il+DsFwOIcXwZmCFVc9UC5aFJ9ZXez 9mJA==
X-Gm-Message-State: ALoCoQkReIu8kt/z7bQDyV5WalIis20XSoXGc2V/LqR/pQPBTSWq/mzQMJ8zSyH/yLUAM+H9HTMH
X-Received: by 10.50.103.6 with SMTP id fs6mr18944026igb.16.1385499059718; Tue, 26 Nov 2013 12:50:59 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm34290334igc.4.2013.11.26.12.50.58 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 12:50:58 -0800 (PST)
Message-ID: <52950992.9050100@bbs.darktech.org>
Date: Tue, 26 Nov 2013 15:50:26 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <52891EDB.2050607@googlemail.com> <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com> <528B2ABE.4040701@googlemail.com> <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl> <528C79AD.10608@googlemail.com> <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <D4CA7C71-1CBF-4090-AB26-48E0B9215590@iii.ca> <CABcZeBNcoRWNsaTsjOEF03jNwAunGNOtozv0E4p5utVjVjLWUQ@mail.gmail.com> <A5B5C80F-AEA0-4E28-8B3C-73654E2BE76B@stevek.com> <CABcZeBO+AZqvG4Div7CgBkizyYck6oy4_ZeVtkP8jfHoK1Dp6Q@mail.gmail.com> <CAHZ_z=ww_mdfo31wVBiB6HySfmbtQxCzKLuWsV4wERWxAt+72Q@mail.gmail.com> <CBD53918-3F7C-43BB-8F57-202495797672@iii.ca> <20131121234706.09a04878@rainpc> <1EB8F765-7FA5-4FA1-A3E8-A2B940335B08@iii.ca>
In-Reply-To: <1EB8F765-7FA5-4FA1-A3E8-A2B940335B08@iii.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] cisco binary on ec2
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: Tue, 26 Nov 2013 20:51:02 -0000

MPEG-LA is doing a terrible job here. The licensing rules are so poorly 
understood and enforced that they have a practical impact of companies 
ignoring them altogether (unless you're huge like Apple or Google). They 
are wasting our time, and it is costing themselves legitimate royalties.

The fact that we are being asked to pay lawyers as an insurance policy 
(to get a legal opinion on a vague license) is not right. I can 
understand why the open-source guys are finding this lack of 
transparency very disturbing.

All this is to say: Cisco's proposal is a step in the right direction 
but there remains a large gap that needs to be filled. I encourage H.264 
advocates to work with MPEG-LA to bridge this gap as opposed to pushing 
this on the rest of us.

As discussed with Cullen during the conference, we should be able to 
come up with "creative" licensing terms that allow us to buy multiple 
units in bulk and integrating the codec directly into our images. As 
opposed to manually downloading the codec each time. Similarly, we 
should get more concrete/official answers from MPEG-LA regarding the 
various questions that came up, such as what constitutes a "unit".

Gili

On 26/11/2013 2:32 PM, Cullen Jennings wrote:
> I think for a scenario like that you would use a different approach as long as you used less than 100k virtual machines - which is a reasonable assumption for all the cloud services I am aware of. You would take the source code and compile it to form the executables on the master image for the VM. You would then distribute the VM normally and not use the Cisco binary.
>
> The other case that has come up is a large enterprise that makes a master copy of the image that distributed to all their desktops  and it is a case where the company has over 100k desktops.  If they own the desktops my understanding is they are the end user from that point of view and as long as the IT department downloaded a copy of the Cisco binary and put it into their master image and then put that master image on computers they own / operate then that can be made to work too.
>
> This stuff is all sort of subtle but there seems to be a wide range of options that can be made to work and have examples of people already doing it with H264 MPEG LA licenses.
>
>
> On Nov 21, 2013, at 3:47 PM, Lorenzo Miniero <lorenzo@meetecho.com>; wrote:
>
>> On Thu, 21 Nov 2013 14:33:15 -0800
>> Cullen Jennings <fluffy@iii.ca>; wrote:
>>
>>> On Nov 21, 2013, at 12:21 PM, Matt Fredrickson <creslin@digium.com>; wrote:
>>>
>>>> I cannot use that on my dynamically
>>>> deployed EC2 instances due to licensing restrictions. :-)
>>>
>>> My understanding of the legal situation is that you can use the cisco binary on your EC2 instance and have Cisco pay the MPEG-LA fees.
>>
>> The issue that was mentioned was cloned/frozen VM images that you could spawn to increase scalability. In that case, you would prepare/install an image just once, freeze it, and then launch a new one whenever you need it. Ideally you'd have the plugin installed that first time only, but then all cloned instances would fall out of the license agreement, as they'd actually be different machines with the plugin reinstalled rather than downloaded on the fly. Downloading the plugin for each new image that is spawned as it unfreezes would be a problem, as 1) the image wouldn't be ready right away, and 2) any problem in the download process would make the machine useless with respect to H.264.
>>
>> Lorenzo
>>
>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> -- 
>> Lorenzo Miniero, COB
>>
>> Meetecho s.r.l.
>> Web Conferencing and Collaboration Tools
>> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb