LWN.net Logo

Sorry, but this is about relicensing, not about linking

Sorry, but this is about relicensing, not about linking

Posted Jun 12, 2009 20:00 UTC (Fri) by khim (subscriber, #9252)
In reply to: Sorry, but no by Uraeus
Parent article: The LGPL and video codecs

This is wrong. The text you refer to talk about linking, and yes you can use any terms for an application dynamically linking to a LGPL library. So if Google shipped Chromium which was dynamically linked to use the system ffmpeg install on Linux distributions then that of course is fine.

Sorry, but no. The text I refer to specifically talks around relicensing: As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

The library is covered by LGPL license too, but this is license given to you not by Google, but by FFmpeg developers. Section 10 of LGPL: Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.

But Google is not shipping just a dynamically linked application that is meant to use a 'system' install of ffmpeg.

Yup. It distributes "a work containing portions of the Library" under "terms of your choice" (you here == Google, so Google can choose any license Google likes).

They are shipping ffmpeg themselves.

Where? How? Once more: they are shipping "a work containing portions of the Library", not FFmpeg itself! And they are NOT using LGPL but different "terms of your choice" (again Google is free to choose terms - with few limitations).

You are misunderstanding how source code licenses work if you think that text in the LGPL gives you the right to re-license code under the LGPL.

!#@!%#@!# Have you read the LGPL? Sure, if I want to modify the library - I'm bound by LGPL. But if I want to combine or link it and then distribute as part of bigger work - I'm free to choose any license I like (with some small limitations). Recipent will get the library in question under two licenses:
1. For the whole bundle from person who bundled the library (and Google uses pretty damn restrictive license for Google Chrome).
2. For the library itself - "from the original licensor" (not even from FFmpeg team but bunch of licenses from lots of separate contributors).
I presume here that Google uses FFmpeg without modifications and so gets to choose the license as per section 6, not bound by LGPL as per section 2...

LGPLv2.1 was written when patents were not a huge problem they are today and it does not bother to restrict distributor who does not modify the library - the authors decided that ability to just replace library with another version was enough of a requirement. Sad choice, but this was conscious choice. LGPLv3 fixed this loophole, but FFmpeg uses LGPLv2.1.

And the patents licensed for H264 support are for the code in ffmpeg, not for the BSD licensed code in Chrome.

Again: not even close. Patents cover the Google Chrome. They say nothing about FFmpeg. Any library will be covered as long as it's part of Google Chrome.

So while it would be fine for Google to license a patent covering bookmarks or something like that in their BSD licensed UI, they can't pretend the codec patent license is for the UI, as what the patent texts for H264 related patents describes functionality is found in ffmpeg code, not in the UI code.

Their license is for browser. Not for codec, not for UI, for browser as whole. Where and how patents are used does not matter. MPEG-LA is happy as long as it's some part of browser called Google Chrome. And it does not conflict with license used for Google Chrome. It may conflict with distribution of FFmpeg as decribed in LGPL separately from Google Chrome - but it's not Google's work to check if it conflicts or not (section 10: You are not responsible for enforcing compliance by third parties with this License).


(Log in to post comments)

Sorry, but this is about relicensing, not about linking

Posted Jun 25, 2009 21:21 UTC (Thu) by gdamjan (guest, #33634) [Link]

Sorry, but no. The text I refer to specifically talks around relicensing: As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

WTF?? The LGPL doesn't talk about relicensing at all.. and even the text you quote doesn't mention relicensing.

When you distribute a software you got to use under LGPL, it stays LGPL. It's allowed to be linked to non-LGPL software, yes. But still Google DOES distribute ffmpeg, and they distribute it under the LGPL.

So, Google does distribute FFmpeg under LGPL, FFmpeg contains code that might be covered by MPEG-LA patents. The only way for Google to do that is:

  • either, infridge patents of MPEG-LA
  • license patents for distributing FFmpeg (but then the FFmpeg license has some requirements about that).

"Infridging patents"

Posted Jun 26, 2009 2:17 UTC (Fri) by xoddam (subscriber, #2322) [Link]

If one can "chill" innovation, I suppose one can also "infridge" a patent!

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds