[whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec

I'd like to address some questions that have been raised about the use
of FFmpeg in Chromium and Chrome as well as H.264 decoding in Chrome
(Google's distribution of Chromium). The use of FFmpeg in Chromium and
Chrome is fully compliant with the obligations of the associated
licenses. It feels a little thread/list jacking to do this, but I
don't like letting these kinds of questions stand, so...

1. FFmpeg and potential patent license issues

FFmpeg is licensed under the LGPL 2.1 (there are some components that
are licensed under the GPL but those are not relevant here, as
explained below).  The LGPL 2.1 states: "If you cannot distribute so
as to satisfy simultaneously your obligations under this License and
any other pertinent obligations, then as a consequence you may not
distribute the Library at all."

The LGPL 2.1 only requires that a party distributing LGPL code give
other people the same rights to that code that they themselves
received under the license.  The Chromium project happily does exactly
this.  Google takes the FFmpeg libraries under the LGPL 2.1, with no
attached patent license.  Subsequently, Google makes the FFmpeg
libraries available as part of Chromium under the LGPL 2.1, with no
patent license attached.

One participant quoted one of the examples from the LGPL 2.1, which
says "For example, if a patent license would not permit royalty-free
redistribution of the Library by all those who receive copies directly
or indirectly through you, then the only way you could satisfy both it
and this License would be to refrain entirely from distribution of the

To be clear, there are two situations here:

Situation 1:

(a) Party A gives Party B a library licensed under the LGPL 2.1 along
with a patent license which says only Party B has the right to use it
(b) Party B wants to distribute the library to others

That's the situation the example in the LGPL 2.1 text is talking about
and would likely be a violation.

Situation 2:

(a) Party A gives Party B a library licensed under the LGPL 2.1
(b) Party B gets a patent license from Party C
(c) Party B then distribute the library under the LGPL 2.1

This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0
for a license that does deal with this situation).  Under the LGPL
2.1, the fact that Party B may have a patent license with an unrelated
third-party is irrelevant as long as it doesn't prevent Party B from
granting people the rights LGPL 2.1 requires they grant them (namely,
only those rights it in fact received from Party A).

2. Location of FFmpeg source code

The source code for FFmpeg is easily locatable in the same place as
the rest of the Chromium source:


3. GPL licensed code in FFmpeg

FFmpeg can be configured to use GPL licensed code, but it is not
configured that way in Chromium.  We use the set of configuration
flags that only enables the LGPL 2.1 code.

The list of configuration flags used is listed in the README file in
the source directory:


We take our obligations under all open source licenses very seriously,
and work hard to ensure we are in compliance with these licenses

Chris DiBona

On Mon, Jun 1, 2009 at 11:21 AM,  <jjcogliati-whatwg at yahoo.com> wrote:
> Thank you for a very informative reply. ?Inline comments follow.
> --- On Sun, 5/31/09, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> From: Gregory Maxwell <gmaxwell at gmail.com>
>> Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec
>> To: whatwg at lists.whatwg.org
>> Date: Sunday, May 31, 2009, 2:17 PM
>> 2009/5/31? <jjcogliati-whatwg
>> at yahoo.com>:
>> > Since the near complete MPEG-1 committee draft was
>> publicly available in December 1991,
>> [snip]
>> You keep repeating this particular piece of misinformation,
>> so I'm
>> worried that people are going to take your word for it and
>> get into
>> trouble.
>> What you are claiming with respect to the inventors
>> disclosure and
>> patent duration is correct for patents filed and granted
>> today but it
>> not true for patents from the mid-1990s.
>> Prior to mid-1995 was possible to use application
>> extensions to defer
>> the grant date of a patent indefinitely.? You could
>> begin an
>> application in 1988, publicly expose your invention in
>> 1991, all the
>> while filing extensions only to have the patent granted in
>> 1995.
>> I am somewhat surprised that you are unaware of this
>> issue,
>> considering that you mentioned it specifically by name
>> (submarine
>> patent).
> Yes, I agree and I was not making this clear in my reply posts. ?The first email I sent I did detail this.
>> I'm more familiar with the area of audio coding than video,
>> so I don't
>> have a ready list of patents that read on mpeg1 video.
>> However, There
>> are mid-90s patents which read on both layer-2 (e.g.
>> 5,214,678) and
>> layer-3 audio which followed the 'submarine patent' style
>> of prolonged
>> application and late disclosure times.
> That is interesting that 5,214,678 is considered to read on Layer-2 since
> AudioMPEG says that they are not doing licensing for Video-CD, which uses
> MPEG-1 Layer 2 audio. ?It was granted in May 25, 1993 and filed on May 31,
> 1990, so it barely made it in three years (and will not expire till
> May 31, 2010).
> http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,214,678
> http://www.audiompeg.com/
>> Additionally, Theora avoids some techniques used in MPEG1
>> which have
>> been believed to be patented.? For example, the
>> differential coding of
>> motion vectors. While I don't have the knowledge needed to
>> provide a
>> detailed analysis, even I know enough to point out at least
>> a few
>> engineering reasons why Theora has less patent exposure
>> surface than
>> MPEG1.
> I can certainly believe that MPEG-1 Video might be non-royalty free and
> Theora might be. ?I haven't really looked at the exact coding of Theora motion vectors. ?That is an interesting thing to look at.
>> Without the benefit of mpeg layer-3 audio MPEG1 is left
>> enormously
>> handicapped compared to Theora+Vorbis. 16kHz 16bit stereo
>> PCM is
>> 512kbit/sec on it own, which is comparable to the total
>> bitrate 'high
>> quality' option delivered by sites like Youtube. And 16kHz
>> audio is
>> pretty poor for anything that needs to carry music.
> Layer-2 audio can certainly beat PCM for compression, since it can reduce
> the bit rate for coding the quieter frequency bands. ?Typical stereo bit
> rates for stereo Layer 2 audio are probably more on the order of 256
> kbit/s. ?Vorbis and MPEG-1 Audio Layer 3 certainly can beat this rate.
>> While you could
>> argue for using MPEG1+Vorbis, none of the few parties who
>> indicated
>> that they would not ship Theora have stated they would (or
>> are
>> already) shipping Vorbis. (For example, Nokia does not ship
>> Vorbis on
>> their Linux tables)? Everyone shipping Vorbis already
>> seems to have no
>> issue with Theora.
> I am not going to argue for MPEG-1 video plus Vorbis audio.
>> Even if you pay fairly low prices for transit the cost of
>> sending PCM
>> audio vs Vorbis is likely enough to pay for the H.264+AAC
>> licensing no
>> matter what it turns out to be in 2010.? A 'free'
>> format which has an
>> effective price much higher than the 'non-free' stuff would
>> be
>> something of a hollow victory.
> Interesting point. ?I think that transit costs will decrease
> faster than H.264+AAC licensing costs, (unless Theora and Vorbis
> start causing serious competion.)
>> And really, now that we see multiple large companies with
>> experienced
>> legal teams and non-trivial exposure committed to shipping
>> Theora I
>> think we're kidding ourselves when we attempt to analyze
>> this as a
>> legal issue. It's not. It's a business/political decision.
>> The market
>> is now going to battle it out.? Enjoy the show.
> I agree. ?I was not aware that Google planned on shipping Theora support when I made the first email last week (Wikipedia article since updated).
> If Ogg Theora and Vorbis become the defacto standard, that is
> fine with me.
> Right now, the best video codec/audio codec that works with Gstreamer good
> plugins (i.e. Linux), Quicktime and Media Player is Motion JPEG with PCM
> audio, which I have used for shipping videos on CDs and USB drives, but is
> impractical for online transfers. ?I am hoping for a better outcome with
> the video tag.
> Josh Cogliati

Open Source Programs Manager, Google Inc.
Google's Open Source program can be found at http://code.google.com
Personal Weblog: http://dibona.com

Received on Monday, 1 June 2009 18:58:21 UTC