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.
But Google is not shipping just a dynamically linked application that is meant to use a 'system' install of ffmpeg. They are shipping ffmpeg themselves. And ffmpeg is LGPL licensed, period. 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.
And the patents licensed for H264 support are for the code in ffmpeg, not for the BSD licensed code in 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.
Sorry, but this is about relicensing, not about linking
Posted Jun 12, 2009 20:00 UTC (Fri) by khim (subscriber, #9252)
[Link]
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).
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!