| |||||||||||||
Sorry, but noSorry, but noPosted Jun 11, 2009 10:34 UTC (Thu) by khim (subscriber, #9252)In reply to: The LGPL and video codecs by jhhaller Parent article: The LGPL and video codecs
For Chrome to fulfill the LGPL requirements, anyone getting FFmpeg as part of Chrome must be able to extract FFmpeg and redistribute it and derivative works without being sued by MPEG-LA. What exactly gives you these rights? Do you really think Google distributes FFmpeg under LGPL license? If so, you are dead wrong: Google does no such thing. Google distributes Google Chrome, not FFmpeg. It does not use LGPL when it does so - this is permitted by clause 6 of LGPL: 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. Chromium licenses (LGPL for WebKit, BSD for Google's own code, etc) sure as hell permit midification of work for customer's own use and reverse engineering for any purpose so Google is compliant. Since Google does not distribute FFmpeg separately LGPL is not in play at all! Only two items of LGPL are in play: main body of item 6 (it gives Google the right to redistribute binary of FFmpeg in Chromium under Google's license, not under LGPL) and 6b (this gives end-user the right to rip out FFmpeg and use any other library in it's place). Unfortunately, only FFmpeg contributors could sue Google for that breach of LGPL, which would then make no one able to redistribute FFmpeg. Or they can switch to LGPLv3 (it closes this loophole).
(Log in to post comments)
Sorry, but no Posted Jun 11, 2009 13:59 UTC (Thu) by drag (subscriber, #31333) [Link]
I have a very very strong suspicion that the ffmpeg folks are not going to care one way or the other. If they were were very worried about patents I don't think they would of put so much effort into making h.264 codecs in the first place.
I think that google is treading very safe water here.
As far as H.264 goes for the web... The amount of bandwidth saved by using H.264 over Theora is more then enough to compensate for the cost of royalties for big players. For everybody else then there is Theora which should continue to have it's encoders improve the point to were at least it is somewhat of a rival for DivX. And like is mentioned you need to have H.264 for hardware compatibility and so on and so forth.
Dirac, it seems, is not going anywhere, unfortunately. Unless people are going to start concentrating on it after the Theora enccoder improvements are implemented.
Maybe it is time to look at snow?
Sorry, but no Posted Jun 11, 2009 17:10 UTC (Thu) by zooko (subscriber, #2589) [Link]
"Dirac, it seems, is not going anywhere, unfortunately. Unless people are going to start concentrating on it after the Theora enccoder improvements are implemented."
Why do you say that? I hosted some dirac videos on my p2p filesystem, and when I play them with VLC on Macintosh it looks great:
http://testgrid.allmydata.org:3567/uri/URI%3ADIR2-RO%3Az3...
Sorry, but no Posted Jun 19, 2009 1:20 UTC (Fri) by roc (subscriber, #30627) [Link]
"The amount of bandwidth saved by using H.264 over Theora is more then enough to compensate for the cost of royalties for big players."
There's no evidence for this. In fact, there is evidence to the contrary.
http://hacks.mozilla.org/2009/06/open-video-codecs-and-qu...
Sorry, but no Posted Jun 11, 2009 15:23 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
Perhaps a little fact checking should come before you invoke the bold text?
Google distributes ffmpeg, as a binary library in DLL form, as part of the Chrome install bundle. The LGPL governs that redistribution.
I don't believe anyone has suggested that the LGPL applies to chrome itself, only to the ffmpeg binary that google is distributing with chrome.
Chromium, Google's open source browser project, is not the primary subject of the discussion.
Sure, let's check the facts Posted Jun 12, 2009 7:55 UTC (Fri) by khim (subscriber, #9252) [Link] Perhaps a little fact checking should come before you invoke the bold text? Let's do. Google distributes ffmpeg, as a binary library in DLL form, as part of the Chrome install bundle. Obviously. The LGPL governs that redistribution. Why? Sure LGPL is involved with distribution - this is the license Google had which gave them the right to craft their new license for Chrome, but why the hell LGPL "governs this distribution"? This is not even close to the reality. Their new license used for distribution of Chromium has nothing to do with LGPL! But you are saying: what if I pull the FFmpeg library from Chrome? Will I get LGPLed library? Sure! Absolutely! You will get the library licensed under LGPL terms by FFmpeg authors. Not by Google, but by LGPL authors! See clause 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. Basically when you are getting Chromium from Google you are getting two licenses: one - from Google - for the whole thing (with attached patent license, but without right to modify the thing), another one - from the original licensor - for the FFmpeg (this is LGPL with clause 11 and everything). This second license gives you the right to modify the thing (and many other rights) but sadly it does not include patent license at all. I don't believe anyone has suggested that the LGPL applies to chrome itself, only to the ffmpeg binary that google is distributing with chrome. Yes, but you and others claim that Google is distributing FFmpeg using LGPL - and this is false. They are distributing Chromium but they are not using LGPL. FFmpeg creators gave them such right in statement 6: 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. Google did right that: they are distributing "the work containing portions of the Library" and they are NOT using LGPL. There are some requirements in section 6, but there are no requirement for Google to distribute FFmpeg under LGPL terms! Please read the damn thing! LGPLv3 is different: it only gives you right to remove "section 3" from GPLv3, LGPLv2.1 gives you right to use any license for the as long as the library itself is unmodified. You somehow think that if I got the work (FFmpeg in question) under some terms I can only distrubte it using the same terms. This is not even close to reality: think Microsoft. Microsoft sells bulk packs of Windows to big manufacturers and then manufacturers sell Windows to end-users. These licenses are VERY different. Manufacturer can distribute Windows with any computer system it creates (but can not sell the license without computer) while end-user can only use Windows with one fixed computer. LGPLv2.1 is the same: if you are distributing the library - you are bound by LGPL. If you are distributing "a work containing portions of the Library" - you are not bound by LGPL. If your new license for "a work containing portins of the Library" will "permit modification of the work for the customer's own use and reverse engineering" and you are using "uitable shared library mechanism" - you are good to go. The LGPL license attached to the library exist as well, but it's "from the original licensor" - not from you.
s/Chromium/Chrome/ Posted Jun 12, 2009 8:04 UTC (Fri) by khim (subscriber, #9252) [Link] Apparently only Google Chrome supports H.264, Chromium does not support it.
Sorry, but no Posted Jun 18, 2009 2:49 UTC (Thu) by lysse (guest, #3190) [Link]
A word to the wise: khim is apparently of the opinion that since copyright lawyers disagree about the law, nobody's interpretation is any better than anyone else's; therefore, his uninformed ramblings are worth as much as anyone else's, too - and consequently he has every right to present them as fact and nobody else has any standing to challenge them. (I say "apparently" - as I understand it, this is precisely the position he laid out to me when I once challenged him about the eccentricity of one of his positions.)
Discussing copyright law with khim is like tic-tac-toe (or global thermonuclear war) - you can't win unless you don't play.
Sorry, but no Posted Jun 12, 2009 15:43 UTC (Fri) by Uraeus (subscriber, #33755) [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.
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: 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:
"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!
|
|||||||||||||