Re: [rtcweb] cisco binary on ec2
Roman Shpount <roman@telurix.com> Tue, 26 November 2013 21:17 UTC
Return-Path: <roman@telurix.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 B22881ADF38 for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 13:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rh6zFmq43fDt for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 13:17:16 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC7C61AD942 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 13:17:15 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id a1so4084892wgh.23 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 13:17:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9vTTX5NF4EzwFXNARUFmtbT4tLwvlGrtY76KKFzop1I=; b=XkcvE8WLK6+1ROpl7dDSeon+u0rXSfYwW90UEXVCioOf0n/8CCJT5hIWfvlHaZIxPZ cmXNiiCdfjxQgotcdbliw7WwrJRdbFtcLn1lq3FziZ7Cckf88IX1j64lkcpapP93lvec g+En6JOLUwV1thPsbAonjK/9KwyTpH67sdJ43LS6265x+Kwcwie9xbAfC7fYAm5IVXJi uDQWw6AO7tqqNibPCV5xEU8GMlFqIPz7CrTTNCYP7Gbh9edSAZKE5aY5BdwujMYft5cl FUq4LYz3dhMSBAQ3OFL9ZPovmv92fKMfKQZet8HsluO03cml2kSCcDRX4ria7AbkwzEZ 9i4w==
X-Gm-Message-State: ALoCoQlRUSgHJ1gd4+bIpLnTC+6DJ/RjIOs6d3dY932kPlhj2+y00BeH/JyWyaBnQt14HDtSRaTD
X-Received: by 10.180.206.18 with SMTP id lk18mr19922407wic.64.1385500635162; Tue, 26 Nov 2013 13:17:15 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx.google.com with ESMTPSA id c10sm63972067wie.11.2013.11.26.13.17.14 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 13:17:14 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id ca18so5852096wib.16 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 13:17:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.198.170 with SMTP id jd10mr19810387wic.65.1385500633564; Tue, 26 Nov 2013 13:17:13 -0800 (PST)
Received: by 10.217.88.133 with HTTP; Tue, 26 Nov 2013 13:17:13 -0800 (PST)
In-Reply-To: <52950992.9050100@bbs.darktech.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> <52950992.9050100@bbs.darktech.org>
Date: Tue, 26 Nov 2013 16:17:13 -0500
Message-ID: <CAD5OKxvPiJm2cF1GOSv30Rn1xj0oP9UmaUWS+6pmWJ3c=M6Agg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: multipart/alternative; boundary="047d7b62509e198ce204ec1b010f"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 21:17:19 -0000
Just a reminder that license from MPEG-LA, even though required, is not sufficient to use H.264 codec. There are other intellectual property holders (such as Nokia) which are not part of MPEG-LA. These property holders are supposed to give you license under RAND terms, but you need to negotiate with them separately. All of this before taking patent trolls into account, which can obviously sue you at any time for any reason. Bottom line, unless you want to spend thousands of dollars and a lot of time negotiating, you cannot license H.264. Your choices are either use H.264 licensed by somebody else, assuming they will be responsible for license fee (like Cisco binary download) or hope that you are small enough not be sued. _____________ Roman Shpount On Tue, Nov 26, 2013 at 3:50 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > > 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 >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Stephan Wenger
- Re: [rtcweb] Video codec selection - way forward Jonathan Rosenberg
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward cb.list6
- Re: [rtcweb] Video codec selection - way forward Robin Raymond
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Gustavo Garcia
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Jeremy Fuller
- Re: [rtcweb] Video codec selection - way forward Jonathan Rosenberg
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Bjoern Hoehrmann
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Harald Alvestrand
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Basil Mohamed Gohar
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Basil Mohamed Gohar
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Ross Finlayson
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- [rtcweb] H.263 licensing situation Stephan Wenger
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- [rtcweb] Reference implementation of software cod… cowwoc
- Re: [rtcweb] Reference implementation of software… cowwoc
- Re: [rtcweb] Reference implementation of software… Maik Merten
- Re: [rtcweb] Video codec selection - way forward DRAGE, Keith (Keith)
- Re: [rtcweb] Video codec selection - way forward DRAGE, Keith (Keith)
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Adam Roach
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Martin Thomson
- Re: [rtcweb] Video codec selection - way forward Steve Kann
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Monty Montgomery
- Re: [rtcweb] Video codec selection - way forward Matt Fredrickson
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Martin Thomson
- Re: [rtcweb] Video codec selection - way forward Enrico Marocco
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward Matthew Kaufman
- [rtcweb] cisco binary on ec2 Cullen Jennings
- Re: [rtcweb] cisco binary on ec2 Matt Fredrickson
- Re: [rtcweb] cisco binary on ec2 Lorenzo Miniero
- Re: [rtcweb] Video codec selection - way forward cb.list6
- [rtcweb] H.264 CBP (was: Video codec selection - … cowwoc
- Re: [rtcweb] H.264 CBP (was: Video codec selectio… Eric Rescorla
- Re: [rtcweb] H.264 CBP (was: Video codec selectio… Stefan Slivinski
- Re: [rtcweb] cisco binary on ec2 Cullen Jennings
- Re: [rtcweb] cisco binary on ec2 cowwoc
- Re: [rtcweb] cisco binary on ec2 Roman Shpount