Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs)

"Olle E. Johansson" <oej@edvina.net> Fri, 01 November 2013 17:21 UTC

Return-Path: <oej@edvina.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A6911E8210 for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 10:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.408
X-Spam-Level:
X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGm2qp0qJS5r for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 10:21:36 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 673D511E8174 for <rtcweb@ietf.org>; Fri, 1 Nov 2013 10:21:35 -0700 (PDT)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E571993C2A2; Fri, 1 Nov 2013 17:21:34 +0000 (UTC)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <5273DEEE.4000302@gmail.com>
Date: Fri, 01 Nov 2013 18:21:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <05B9F53B-BEB8-45C8-A9B2-E09E72D1CA0E@edvina.net>
References: <CAPvvaaLwacOgQq5O8t0bMCJJfKTHbJM9RnawgXLJpKiADtsi2Q@mail.gmail.com> <5273D5C8.304@bbs.darktech.org> <5273D848.2060608@makk.es> <5273DEEE.4000302@gmail.com>
To: Daniel Constantin Mierla <miconda@gmail.com>
X-Mailer: Apple Mail (2.1816)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] x264 vs OpenH264 (Was: On the topic of MTI video codecs)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 01 Nov 2013 17:21:37 -0000

On 01 Nov 2013, at 18:03, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

> 
> On 11/1/13 5:35 PM, Max Jonas Werner wrote:
>> On 01.11.2013 17:24, cowwoc wrote:
>>> On 01/11/2013 12:19 PM, Emil Ivov wrote:
>>>> It would be nice for Mozilla to comment then. They wouldn't have been
>>>> required to statically link against it or even distribute it. It is
>>>> already possible to use GPL plug-ins with Firefox, so why is x264 an
>>>> insurmountable problem?
>>> Can I dynamically link x264 against my proprietary application without
>>> having to GPL it?
>> Actually no: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
>> 
>> That's why the LGPL (that poses other risks, though) exists.
> GPL constraints about open sourcing are for the case when distributing the application. You can link anything you want with gpl code and you don't have to make the sources available if you don't distribute your application.
> 
> I think that Emil wanted to say that we, users, don't distribute web browsers, we just use them.
> 
> Then, if I got it right, no browser will link against the h264 plugin. That will be loaded at user will (eventually), by downloading on demand from cisco site.
> 
> So I, as user, I take Firefox from Mozilla site, then when I need to do webrtc, my browser will download (first time) and use the h264 plugin. Because I don't distribute further the two, I don't see any restriction from gpl here. That's my understanding.

I don't think GPL agrees with that. GPL applies at runtime, not only when building the app. THe FAQ on the link above says

"Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination."

"If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case."

/O