Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Chris DiBona writes: this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. I'm not so sure. YouTube is very popular despite the fact that its video clips resemble the transmission from the moon landing in 1969. And JPEG2000 achieves better pictures/megabyte than JPEG, but internet users are not calling for it. Saving a megabyte here and there is less important than having a video format that is free and open for all to use. Dailymotion.com has understood this and their recent offerings using video and Ogg Theora is laudable [1]. This was exactly what I've been hoping for, and arguing for, since the video element was proposed [2][3]. [1] http://blog.dailymotion.com/2009/05/27/watch-videowithout-flash/ [2] http://people.opera.com/howcome/2007/video/ [3] http://video.google.com/videoplay?docid=5545573096553082541 At Google, you have a unique opportunity to be part of this. You have the video clips, the disks, the processing power, and the talent to launch a service that will firmly establish video and Ogg Theora as the video solution for the web. However, it seems that Google doesn't care much for having a free and open video format. Most of the bits you put out on the web are in patent-encumbered formats, and this doesn't seem to bother you. Rather, you promote patent-encumbered formats in your new experimental service [4]. [4] http://www.youtube.com/html5 The web is based on free and open formats. Google would not have existed without the web. It will be a terrible tragedy if you tip the scales in favor of patent-encumbered formats on the web. We expect higher standards from you. -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
It is impractical to convert video that was already compressed. My attempt to convert QuickTime to Theora inflated the file from 10 MB to 50 MB; this is unacceptable. Moreover, unpleasant visual artifacts appeared. I was told it must be like that; you can get satisfactory compression results from raw video only. I suspect Google cannot convert most of the video it already serves even if they wanted to. IMHO, Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Am Montag, den 08.06.2009, 12:47 +0200 schrieb Křištof Želechovski: I suspect Google cannot convert most of the video it already serves even if they wanted to. I suspect Google, with its enourmous storage capacity, has the original files of each and every video ever uploaded. But only Youtube engineers can tell us that. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
People are reluctant to learn new tools and new ways. Most of the time it is a sane protection from overwhelming abundance. It is not limited to programming languages, it can affect also video encoders. It even affects telephones (some people dislike telephones with keys). Bjarne Stroustrup on this (quoting from memory): I used to expect the programming languages of the future would be as easy to use as a telephone. Now I do not know how to use my telephone any more. Moreover, I suppose every video encoder has parameters that you adjust to get the best results, depending on the source video, so the problem is not limited to choosing another encoder. IMHO, Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Mon, Jun 8, 2009 at 11:27 AM, Chris DiBonacdib...@gmail.com wrote: Thinking out loud: One thing that was mentioned in an earlier post: Vorbis. I am also of the mind that Vorbis is of higher quality/mb/sec and statically than is mp3. The only real problem is that people don't pirate with it, so the demand isn't there, but I think it is a superior codec. For video, I worry that for theora to become 'better' than h264, it will need to infringe on the same patents it is designed to avoid. I think you may be underestimating the potential that is still in Theora. As Monty described in this May update http://web.mit.edu/xiphmont/Public/theora/demo7.html, there are still many improvements to be made on the encoder, but Thusnelda has already improved heaps without using h264 techniques. I wouldn't give up on Theora and quality video yet. In particular when most people will not really notice the difference on a well encoded video using Theora in comparison to H.264 - and I say that from anecdotal evidence rather than actual research. In fact, I disagree with the whole notion that the lack of uptake on Theora is caused by its lesser quality. I think the real issue that a user has with Theora is that it doesn't yet have the same kind of tool support as other codecs, e.g. H.264. However, that was also true of H.264 not a long time ago - increasing vendor support on h.264 made all the difference. It would for Theora, too. So, vendor support - and that includes browser vendors, but also video editors, transcoders, hosting providers, video players etc - is the real issue. Lack of vendor support in turn has nothing to do with the slightly lesser quality of a codec. It's all about costs and returns: about return on investment on past expenditure on other codecs, about new cost on the codec (beyond the sheer implementation cost which should be minimal with Theora), about perceived risk of expenditure on legals around it (including patents), and about money the new codec support could bring. A new codec doesn't bring the vendor new income unless it promises something special to the user and thus creates a market need. Only if the market is asking for it and the vendor will not be able to sell his tools without supporting the codec will he be forced to provide support. We are in a chicken-and-egg situation. H.264 broke this chicken-and-egg situation by promising a amazing new quality of picture, which was communicated through marketing and thus created the market need. This obviously won't work on a codec that is of equal or slightly lesser quality. Being royalty-free, unencumbered, and easier to innovate around could and should be the message for Theora. That married with it being written into HTML5 as baseline codec would definitely break that chicken-and-egg situation and create the market need that is required for Theora to gain vendor support. Amazing demos of capabilities of HTML5 video available in all browsers because they all support Theora would blow users away and make them ask for Theora support. I think we are starting to see this happening: the content published at Archive.org, Wikipedia and Dailymotion in Theora will have impact, the native support of Theora decoding in Firefox, Chrome, and possibly Opera will have impact, and the DirectShow filters, QuickTime components, encoding and decoding plugins, etc will have impact. Whether it will be enough to get the all browser vendors on board and therefore Theora written into the HTML5 spec as a baseline codec, I don't know. I fear we are on the same path again that we were on with image codecs and it will take a long time until the new, open and unencumbered PNG (umm: theora) codec is accepted in all browsers. I'm not even sure that writing it into the standard would make vendors actually support it, for the reasons above. If everyone had only the best interest of Web users on mind, it might happen, but that is now how the world works. I can only hope that it won't take as long as PNG took, which was introduced in 1996 and got browser support by all mainstream browsers only in 1999, fully bug-free only in 2008. Regards, Silvia.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Mon, Jun 8, 2009 at 9:55 PM, Silvia Pfeiffersilviapfeiff...@gmail.com wrote: On Mon, Jun 8, 2009 at 11:27 AM, Chris DiBonacdib...@gmail.com wrote: .. I'm not even sure that writing it into the standard would make vendors actually support it, for the reasons above. If everyone had only the best interest of Web users on mind, it might happen, but that is now s/now/not/ how the world works. I can only hope that it won't take as long as PNG took, which was introduced in 1996 and got browser support by all mainstream browsers only in 1999, fully bug-free only in 2008. Sorry for they typo, Silvia.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
The VIDEO element will not be useless without a common decoder. Its usefulness depends on its content: it will be limited to user agents that support at least one encoding offered by the author. Even if a common decoder is specified, many authors will not use it because they do not know it, they do not have the tools, they are reluctant to learn or they consider the proprietary solution better for production and valid for their target audience. IMHO, Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
2009/6/7 Daniel Berlin dan...@google.com: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: I do appreciate your willingness not discuss these matters, though. Thanks. As I said, it's clear we won't convince everyone, I question the relevance to HTML5 of someone from a completely proprietary software company closely questioning a direct competitor on their conformance to the GPL. - d.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 2:08 AM, David Gerard dger...@gmail.com wrote: 2009/6/7 Daniel Berlin dan...@google.com: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: I do appreciate your willingness not discuss these matters, though. Thanks. As I said, it's clear we won't convince everyone, I question the relevance to HTML5 of someone from a completely proprietary software company closely questioning a direct competitor on their conformance to the GPL. - d. Despite being proprietary, Opera Software ASA is the only one that produces an engine that is totally standards compliant. Gecko and WebKit cannot say the same thing, even though they are open source. Also, Opera has a much higher turnaround for implementing new standards into Presto than either of the two others.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 1:55 AM, Kristof Zelechovski giecr...@stegny.2a.plwrote: The VIDEO element will not be useless without a common decoder. Its usefulness depends on its content: it will be limited to user agents that support at least one encoding offered by the author. Even if a common decoder is specified, many authors will not use it because they do not know it, they do not have the tools, they are reluctant to learn or they consider the proprietary solution better for production and valid for their target audience. IMHO, Chris Ahh, but the thing is, there ARE tools to make Ogg videos. And more would spring up if Theora was chosen as the common codec. Already quite a few proprietary and open source multimedia manipulation programs support the Ogg container and Ogg Vorbis codec out of the box. A good example being Nero Burning ROM. The thing is, the audience won't know the difference. To them, its just a faster player playing videos without crashing their browser or causing it to slow down at odd times. The content makers are not going to have a problem making Theora videos. Besides, most content making software use either DirectShow codecs or ffmpeg on Windows. On Mac, generally they use QuickTime codecs. And on Linux, usually GStreamer or ffmpeg is used. Since Theora/Vorbis codecs for all of those platforms are available, existing software would be able to output Ogg videos. And where the heck would reluctant to learn come from? This isn't a programming language, it is a codec! All they have to do is change the selection of codecs on the output of their video. As for not knowing it, there is already some publicity on Ogg Theora videos from the Mozilla team. And Dailymotion has converted a portion of their library for the purpose of experimenting with it. Wikipedia/Wikimedia uses it already. The Internet Archive also uses it. There is no doubt that people already know it.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
2009/6/7 King InuYasha ngomp...@gmail.com: And where the heck would reluctant to learn come from? This isn't a programming language, it is a codec! All they have to do is change the selection of codecs on the output of their video. As for not knowing it, there is already some publicity on Ogg Theora videos from the Mozilla team. And Dailymotion has converted a portion of their library for the purpose of experimenting with it. Wikipedia/Wikimedia uses it already. The Internet Archive also uses it. There is no doubt that people already know it. Wikimedia is blatantly encouraging the use of Firefogg: http://firefogg.org/ It's an encoding extension for Firefox. Ideal for processing videos pre-upload. (No, I don't know why Wikimedia doesn't have its own on-site re-encoder for videos uploaded in encumbered formats. Presumably considered to have some vague legal risk before the Supreme Court uses in re Bilski to drive the software patents into the ocean, cross fingers.) - d.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 10:23 AM, David Gerard dger...@gmail.com wrote: 2009/6/7 King InuYasha ngomp...@gmail.com: And where the heck would reluctant to learn come from? This isn't a programming language, it is a codec! All they have to do is change the selection of codecs on the output of their video. As for not knowing it, there is already some publicity on Ogg Theora videos from the Mozilla team. And Dailymotion has converted a portion of their library for the purpose of experimenting with it. Wikipedia/Wikimedia uses it already. The Internet Archive also uses it. There is no doubt that people already know it. Wikimedia is blatantly encouraging the use of Firefogg: http://firefogg.org/ It's an encoding extension for Firefox. Ideal for processing videos pre-upload. (No, I don't know why Wikimedia doesn't have its own on-site re-encoder for videos uploaded in encumbered formats. Presumably considered to have some vague legal risk before the Supreme Court uses in re Bilski to drive the software patents into the ocean, cross fingers.) - d. That is a very nice tool to promote. It makes it very easy to upload as Ogg video. The only thing is that sites have to be modified to accept from Firefogg. Nevertheless, it is a rather ingenious tool.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Hello, I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? At this point, I am just as confused as Hakom. I am curious if someone has contacted the FSF for the interpretation of the LGPL in this particular case. It would make a lot of people's life easier if they could license patents from MPEG-LA and redistribute ffmpeg. We are on a similar situation with Moonlight where we ended up distributing proprietary codecs for VC1 (also MPEG-LA licensed) instead of the open source ffmpeg. Today our answer for those that want to use ffmpeg (and it is my personal choice as well, since I rather dogfood open source software) is to compile Moonlight from source code and use the ffmpeg code themselves instead of depending on proprietary codecs to be installed. Miguel.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
You guys would probably be less confused if you actually stuck to the terms of the license instead of trying to parse the examples :) In any case, I doubt its worth asking the fsf, since at least in the US, only the ffmpeg folks would have standing to enforce, so its their view that really matters. I'd be interested in knowing what the ffmpeg folks think (for example, if they felt what we were doing was not right, I'm fairly positive we'd just switch to differently licensed libraries). On Jun 7, 2009 2:08 PM, Miguel de Icaza mig...@novell.com wrote: Hello, I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent righ... At this point, I am just as confused as Hakom. I am curious if someone has contacted the FSF for the interpretation of the LGPL in this particular case. It would make a lot of people's life easier if they could license patents from MPEG-LA and redistribute ffmpeg. We are on a similar situation with Moonlight where we ended up distributing proprietary codecs for VC1 (also MPEG-LA licensed) instead of the open source ffmpeg. Today our answer for those that want to use ffmpeg (and it is my personal choice as well, since I rather dogfood open source software) is to compile Moonlight from source code and use the ffmpeg code themselves instead of depending on proprietary codecs to be installed. Miguel.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: However, let me ask *you* a question. Why do you rely on the example instead of the actual clause from that part of the conditions? You realize the example has roughly no legal effect, right? It does not add or modify the terms and conditions of the license. I'm a spec guy, not a lawyer. When we write specs, we typically insert specific examples that help clarify the more general conditions in the text. Often, an example will describe a common scenario and state, in simple terms, the outcome. To me, it seems that the LGPL is written the same way. The first two sentences of #11 are general conditions. The third sentence contains a specific example to help clarify what the more general conditions say. Current specs typically state that the examples are non-normative, while the general statements are normative. I do not know if the same rules apply to legal licenses -- LGPL itself doesn't say. As to your question: I'm not really relying on anything. I've merely said that I don't understand your interpretation of #11. You guys would probably be less confused if you actually stuck to the terms of the license instead of trying to parse the examples :) The example in #11 seems fairly clear. Do you see any incompatibilities between the example text and the general clauses? Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 9:18 PM, Chris DiBonacdib...@gmail.com wrote: At this point I feel like we're giving open source advice to teams outside of Google, which is beyond our mission. We're comfortable with our compliance mission and feel it is accurate and correct. Other companies and people need to make their own decisions about compliance. There may be a real legal problem here, but I don't think it matters much. An LGPL loophole via naming in licenses--whatever. I'm sure there are resources available to license or rewrite whatever you need if that falls through. The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Am Montag, den 08.06.2009, 09:24 +0900 schrieb Chris DiBona: The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Please, stay calm. Flash is also evil[tm] (read: detrimental to accessibility and compatibility) too and I think you know that. Also, the status quo (various proprietary plugins) says nothing about how something should be (accessible, interoperable standards); this is called the is-ought-problem, please read up on it. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Hello Dan, In any case, I doubt its worth asking the fsf, since at least in the US, only the ffmpeg folks would have standing to enforce, so its their view that really matters. The FSF might be able to provide some guidance on the intentions of the license as this seems to be the bit that is confusing. Is the example provided in the debated question part of the license or not;But most importantly which one of the two interpretations is the valid one.If your interpretation is correct, this opens a lot of doors not only for Chromium but for plenty of other software (both using ffmpeg and not using ffmpeg). I'd be interested in knowing what the ffmpeg folks think (for example, if they felt what we were doing was not right, I'm fairly positive we'd just switch to differently licensed libraries). Right, if this is a problem, the fix is straight forward. We went with a separate (and proprietary) implementation of the codecs for Moonlight because we understood the license differently. Miguel.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. You can claim Humians as much as you like, the rest of us are trying to ship software here. Chris On Mon, Jun 8, 2009 at 9:29 AM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Am Montag, den 08.06.2009, 09:24 +0900 schrieb Chris DiBona: The incredibly sucky outcome is that Chrome ships patent-encumbered open web features, just like Apple. That is reprehensible. Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Please, stay calm. Flash is also evil[tm] (read: detrimental to accessibility and compatibility) too and I think you know that. Also, the status quo (various proprietary plugins) says nothing about how something should be (accessible, interoperable standards); this is called the is-ought-problem, please read up on it. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Mon, Jun 8, 2009 at 12:24 PM, Chris DiBona cdib...@gmail.com wrote: Reprehensible? Mozilla (and all the rest) supports those same open web features through its plugin architecture. People don't usually think of Flash as part of the open Web (except for certain Adobe evangelists). Why don't you make a stand and shut down compatibility with plugins from flash, quicktime and others? How long would Firefox last in the market if it were incompatible with those? Honestly. Even if supporting plugins was against our principles, which I'm not convinced of, it's currently impossible to drop support for them and remain relevant, so we'd have to compromise, but that wouldn't make plugins right. If patent-encumbered codecs delivered via video become essential for Web browsing then we'll have to make some compromises, but that wouldn't change their reprehensibility. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Am Montag, den 08.06.2009, 09:42 +0900 schrieb Chris DiBona: I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., That sounds too qood to be true — so can we throw that argument out then and ask Nokia and Apple why they won't pull a Google and just implement both h264 and Theora natively ? but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. Well, Vorbis seems to be performing better than MPEG Layer 3 bitrate-wise, but wasn't really a killer. So I don't really buy that argument. Same about FLAC vs. WAV. You can claim Humians as much as you like, the rest of us are trying to ship software here. I was just tryin' to keep the discussion fair. Rhetoric tricks are something for politicians, not suitable for an engineering discussions I believe we are having here. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Mon, Jun 8, 2009 at 12:42 PM, Chris DiBona cdib...@gmail.com wrote: I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. You can claim Humians as much as you like, the rest of us are trying to ship software here. Historically a lot of the Web standards community, even many people at large for-profit companies, have felt it very important that Web standards be usable royalty-free. There were big battles when that situation was threatened in the past. I personally care about it just as much as shipping software. In that context, helping make H.264 an essential part of the open Web is reprehensible. If your only goal is to ship software with the best bitrate/quality tradeoff, OK, but you can't complain when you get flak. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
I'm okay with Flak, and I really do believe in shipping free/unemcumbered software (see our lgpl discussion earlier). That said, I dislike when I'm accused of being reprehensible by another browser vendor. It seems unfairly nasty to me. Thinking out loud: One thing that was mentioned in an earlier post: Vorbis. I am also of the mind that Vorbis is of higher quality/mb/sec and statically than is mp3. The only real problem is that people don't pirate with it, so the demand isn't there, but I think it is a superior codec. For video, I worry that for theora to become 'better' than h264, it will need to infringe on the same patents it is designed to avoid. That said, I feel like I've been threadjacking this list for too long now, and for that I apologize, it seems like we're gong down a codec rathole that may or may not have any relevance for the spec in the end. Chris On Mon, Jun 8, 2009 at 10:10 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Mon, Jun 8, 2009 at 12:42 PM, Chris DiBona cdib...@gmail.com wrote: I'm perfectly calm, what people need to realize is that this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. So long as this is true this issue will not be resolvable cleanly and the kind of puritism that Robert mentioned is achievable only upon expiration of said patents or dramatic quality improvements of the free codecs. You can claim Humians as much as you like, the rest of us are trying to ship software here. Historically a lot of the Web standards community, even many people at large for-profit companies, have felt it very important that Web standards be usable royalty-free. There were big battles when that situation was threatened in the past. I personally care about it just as much as shipping software. In that context, helping make H.264 an essential part of the open Web is reprehensible. If your only goal is to ship software with the best bitrate/quality tradeoff, OK, but you can't complain when you get flak. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 9:27 PM, Chris DiBonacdib...@gmail.com wrote: I'm okay with Flak, and I really do believe in shipping free/unemcumbered software (see our lgpl discussion earlier). That said, I dislike when I'm accused of being reprehensible by another browser vendor. This line of argument is incorrect in a couple of ways. Firstly, it is an ad hominem argument, stating that my employer makes my statement somehow unacceptable. Secondly, I didn't say anything about /you/. I wrote about the practice of shipping encumbered software and calling it open. It seems unfairly nasty to me. What is unfair or nasty about it? That said, I feel like I've been threadjacking this list for too long now, and for that I apologize, it seems like we're gong down a codec rathole that may or may not have any relevance for the spec in the end. Actually, the spec used to mention Ogg specifically. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 6:41 PM, Robert Sayre say...@gmail.com wrote: I wrote about the practice of shipping encumbered software and calling it open. Where is the language where Google is calling H.264 open? The closest I know of is Google Chrome is made possible by the Chromium open source project and other open source software (from Tools-About Google Chrome), which links to a page containing links to the FFMPEG homepage and license. I don't see that as saying what it sounds like you claim something somewhere is saying? In the end I personally view hostility towards patent-encumbered video formats the same way I view hostility toward non-GPL free software licenses: a stance I understand, but not one I agree with. More importantly for this thread in particular, I'm not sure what the purpose of stating that opposition here is. I thought the purpose of this thread was to resolve questions people had about the use of FFMPEG vis-a-vis its license. This is probably going to be an ineffective forum if your hope is to dissuade Google from shipping H.264 support. PK
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 7:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I don't think the particular parallel you've drawn there is the appropriate one. And I think you failed to answer the line in my email that asked what the point of this tangent is. PK
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 10:45 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 7, 2009 at 7:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I don't think the particular parallel you've drawn there is the appropriate one. And I think you failed to answer the line in my email that asked what the point of this tangent is. PK I split the thread specifically because I agreed with your position that the encumbered codec angst was unrelated the LGPLv2 licensing concerns. I apologize for not saying so directly. Much of my email was presenting a position as to why the concerns related to these formats keep arising within whatwg and why these concerns have practical implications for the standard. Frankly, the legality of Google's software while interest is almost entirely off-topic, though of some interest to implementers. I felt guilty for the two messages I posted on the subject a few days ago. As switch in focus to the codec compatibility issues is a move back on topic, although that horse is already well beaten at this point. Cheers.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: 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 Library. Note that the actual *clause* (not the example) in question says 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. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 4:35 PM, Håkon Wium Liehowc...@opera.com wrote: Also sprach Daniel Berlin: 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 Library. Note that the actual *clause* (not the example) in question says 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. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. As i've said in other messages, this example doesn't match this case at all, since the patent license was not given to us by the same people who gave us the library, *and* our patent license doesn't even say anything about the library used to do encoding/decoding. I.E. Our patent license has 0 to say about our distribution of ffmpeg, only something to say about our distribution of Chrome, which is only covered by section 6 of the LGPL 2.1 (which allows distribution under whatever terms we choose so long as we meet certain requirements, which we do). I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? That our patent license does not restrict/grant/say anything about ffmpeg, only Google Chrome, and Google Chrome itself doesn't fall under the LGPL 2.1 except through section 6. --Dan
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 3:47 PM, Daniel Berlin dan...@google.com wrote: On Sat, Jun 6, 2009 at 4:35 PM, Håkon Wium Liehowc...@opera.com wrote: Also sprach Daniel Berlin: 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 Library. Note that the actual *clause* (not the example) in question says 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. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. As i've said in other messages, this example doesn't match this case at all, since the patent license was not given to us by the same people who gave us the library, *and* our patent license doesn't even say anything about the library used to do encoding/decoding. I.E. Our patent license has 0 to say about our distribution of ffmpeg, only something to say about our distribution of Chrome, which is only covered by section 6 of the LGPL 2.1 (which allows distribution under whatever terms we choose so long as we meet certain requirements, which we do). I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? That our patent license does not restrict/grant/say anything about ffmpeg, only Google Chrome, and Google Chrome itself doesn't fall under the LGPL 2.1 except through section 6. --Dan So are you saying you DO have a patent license for ffmpeg and Chrome? Or don't you?
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 5:00 PM, King InuYashangomp...@gmail.com wrote: On Sat, Jun 6, 2009 at 3:47 PM, Daniel Berlin dan...@google.com wrote: On Sat, Jun 6, 2009 at 4:35 PM, Håkon Wium Liehowc...@opera.com wrote: Also sprach Daniel Berlin: 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 Library. Note that the actual *clause* (not the example) in question says 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. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. As i've said in other messages, this example doesn't match this case at all, since the patent license was not given to us by the same people who gave us the library, *and* our patent license doesn't even say anything about the library used to do encoding/decoding. I.E. Our patent license has 0 to say about our distribution of ffmpeg, only something to say about our distribution of Chrome, which is only covered by section 6 of the LGPL 2.1 (which allows distribution under whatever terms we choose so long as we meet certain requirements, which we do). I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? That our patent license does not restrict/grant/say anything about ffmpeg, only Google Chrome, and Google Chrome itself doesn't fall under the LGPL 2.1 except through section 6. --Dan So are you saying you DO have a patent license for ffmpeg and Chrome? Or don't you? Why are you conflating both of them together? Our patent license covers user use of Chrome so they can play H.264/AVC/etc. It says nothing about ffmpeg. Zilch. Zero. If you were to replace ffmpeg in Chrome with another decoder, our patent license should still cover your use (I would have to double check this, but this is my recollection). --Dan
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 4:20 PM, Daniel Berlin dan...@google.com wrote: On Sat, Jun 6, 2009 at 5:00 PM, King InuYashangomp...@gmail.com wrote: On Sat, Jun 6, 2009 at 3:47 PM, Daniel Berlin dan...@google.com wrote: On Sat, Jun 6, 2009 at 4:35 PM, Håkon Wium Liehowc...@opera.com wrote: Also sprach Daniel Berlin: 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 Library. Note that the actual *clause* (not the example) in question says 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. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. As i've said in other messages, this example doesn't match this case at all, since the patent license was not given to us by the same people who gave us the library, *and* our patent license doesn't even say anything about the library used to do encoding/decoding. I.E. Our patent license has 0 to say about our distribution of ffmpeg, only something to say about our distribution of Chrome, which is only covered by section 6 of the LGPL 2.1 (which allows distribution under whatever terms we choose so long as we meet certain requirements, which we do). I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? That our patent license does not restrict/grant/say anything about ffmpeg, only Google Chrome, and Google Chrome itself doesn't fall under the LGPL 2.1 except through section 6. --Dan So are you saying you DO have a patent license for ffmpeg and Chrome? Or don't you? Why are you conflating both of them together? Our patent license covers user use of Chrome so they can play H.264/AVC/etc. It says nothing about ffmpeg. Zilch. Zero. If you were to replace ffmpeg in Chrome with another decoder, our patent license should still cover your use (I would have to double check this, but this is my recollection). --Dan Mainly because ffmpeg has way more than H.264 and other MPEG4 profile codecs. FFmpeg has a lot more than MPEG4 and MPEG2 and having licenses just for those might not be enough. You would be better off integrating xvid and x264 rather than ffmpeg. Of course, I am not a lawyer, so take my advice with a grain of salt.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. As i've said in other messages, this example doesn't match this case at all, since the patent license was not given to us by the same people who gave us the library The example doesn't mention this as a requirement. *and* our patent license doesn't even say anything about the library used to do encoding/decoding. The example doesn't mention this as a requirement, either. The example only has one if statement: 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 Library. This if statement seems to be true, and I therefore still don't understand your reasoning. I do appreciate your willingness not discuss these matters, though. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: This if statement seems to be true, and I therefore still don't understand your reasoning. I've explained my position and reasoning, and we are going to have to agree to disagree, because it's clear neither of us are going to accept the other's viewpoint. My understanding of the example is consistent with the LGPL's goal statement at the start: Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. The goal statement, at least to me, makes clear the example is talking about obtaining a patent license that covers the library directly, not that covers something that uses the library. However, let me ask *you* a question. Why do you rely on the example instead of the actual clause from that part of the conditions? You realize the example has roughly no legal effect, right? It does not add or modify the terms and conditions of the license. We can argue back and forth over what the example means all day, and it makes no difference. The clause being 11. If as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. 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. Do you see any requirements in the actual legal clauses that you believe we violate? I do appreciate your willingness not discuss these matters, though. Thanks. As I said, it's clear we won't convince everyone, --Dan
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 8:50 PM, Daniel Berlindan...@google.com wrote: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: This if statement seems to be true, and I therefore still don't understand your reasoning. I've explained my position and reasoning, and we are going to have to agree to disagree, because it's clear neither of us are going to accept the other's viewpoint. My understanding of the example is consistent with the LGPL's goal statement at the start: Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. The goal statement, at least to me, makes clear the example is talking about obtaining a patent license that covers the library directly, not that covers something that uses the library. Missed a sentence somehow. My understanding of the example is also consistent with the actual legal clause in front of the example, and I use it to inform my position on the example. Taking a example from a paragraph out of the surrounding context and trying to claim it stands alone seems a bit strange to me, but i'm just a simple engilawyer.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
At this point I feel like we're giving open source advice to teams outside of Google, which is beyond our mission. We're comfortable with our compliance mission and feel it is accurate and correct. Other companies and people need to make their own decisions about compliance. Chris On Sun, Jun 7, 2009 at 10:03 AM, Daniel Berlindan...@google.com wrote: On Sat, Jun 6, 2009 at 8:50 PM, Daniel Berlindan...@google.com wrote: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: This if statement seems to be true, and I therefore still don't understand your reasoning. I've explained my position and reasoning, and we are going to have to agree to disagree, because it's clear neither of us are going to accept the other's viewpoint. My understanding of the example is consistent with the LGPL's goal statement at the start: Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. The goal statement, at least to me, makes clear the example is talking about obtaining a patent license that covers the library directly, not that covers something that uses the library. Missed a sentence somehow. My understanding of the example is also consistent with the actual legal clause in front of the example, and I use it to inform my position on the example. Taking a example from a paragraph out of the surrounding context and trying to claim it stands alone seems a bit strange to me, but i'm just a simple engilawyer. -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 8:18 PM, Chris DiBona cdib...@gmail.com wrote: At this point I feel like we're giving open source advice to teams outside of Google, which is beyond our mission. We're comfortable with our compliance mission and feel it is accurate and correct. Other companies and people need to make their own decisions about compliance. Chris On Sun, Jun 7, 2009 at 10:03 AM, Daniel Berlindan...@google.com wrote: On Sat, Jun 6, 2009 at 8:50 PM, Daniel Berlindan...@google.com wrote: On Sat, Jun 6, 2009 at 7:52 PM, Håkon Wium Liehowc...@opera.com wrote: This if statement seems to be true, and I therefore still don't understand your reasoning. I've explained my position and reasoning, and we are going to have to agree to disagree, because it's clear neither of us are going to accept the other's viewpoint. My understanding of the example is consistent with the LGPL's goal statement at the start: Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. The goal statement, at least to me, makes clear the example is talking about obtaining a patent license that covers the library directly, not that covers something that uses the library. Missed a sentence somehow. My understanding of the example is also consistent with the actual legal clause in front of the example, and I use it to inform my position on the example. Taking a example from a paragraph out of the surrounding context and trying to claim it stands alone seems a bit strange to me, but i'm just a simple engilawyer. -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com To me, it seems more like Google doesn't really want to take a position in the matter regarding codecs and is taking the weird way out by using ffmpeg. Given Google's dominance in search, which tends to bring people to at least look at Google's products, anything Google does is examined with a fine toothpick and commented about pretty much everywhere. So yes, anything Google does will be taken as an example for others, regardless of the sane way to do it. Even if Google's method is sane to them and not to others, people will take it as otherwise. That's fine if Google doesn't want to take a position, but this squabbling does not help anything at all And the video tag will be rendered useless if no default codec is specified. Same for audio. Whatever... People, Google's choice to use FFmpeg doesn't have anything to do HTML 5 other than it shows Google's neutrality. If they take a position later, they should show it in their browser too, but I have a feeling they won't.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
To me, it seems more like Google doesn't really want to take a position in the matter regarding codecs and is taking the weird way out by using ffmpeg. Given Google's dominance in search, which tends to bring people to at least look at Google's products, anything Google does is examined with a fine toothpick and commented about pretty much everywhere. So yes, anything Google does will be taken as an example for others, regardless of the sane way to do it. Even if Google's method is sane to them and not to others, people will take it as otherwise. That's fine if Google doesn't want to take a position, but this squabbling does not help anything at all I think we've taken a very clear position on compliance but... And the video tag will be rendered useless if no default codec is specified. Same for audio. This is really a matter for the spec to handle one way or another, not Google. Chris
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sat, Jun 6, 2009 at 9:16 PM, Chris DiBona cdib...@gmail.com wrote: [snip] I think we've taken a very clear position on compliance but... [snip] This is really a matter for the spec to handle one way or another, not Google. Chris Compliance does not mean taking a position. It just means you follow the spec as it is currently written. As it is currently written, the default/recommended codec is not specified, so Google can do whatever. The spec is currently not finalized, even though there have been few changes the to video and audio parts of the HTML 5 recently. All people participating in this mailing list are basically working to get that done. Google, having a business primarily in the web, through search, advertisements, etc. has a vested interest in HTML 5. If most of the people interested in the video and audio parts of the spec settle on Theora/Vorbis as the codec pair that must be provided in any browser supporting those tags, then hopefully that part can be finished. This includes Google, by proxy of you, Chris, since you're not really saying that your posts do not reflect on Google, it could be assumed that. I gave my opinion ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020190.html ) supporting Theora and Vorbis as the opinion from the Enano CMS Project, which I am affiliated with. I suppose the same would be true for Håkon Wium Lie, since his posts don't say that either. But he is the CTO of Opera, he can say whatever I guess...
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Wed, Jun 3, 2009 at 3:28 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 11:51 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 10:18 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 9:50 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? I'm not saying that at all. I'm simply saying that any patent license we may have does [not] cause our distribution of ffmpeg to violate the terms of the LGPL 2.1 I now understand that your statement was only that Google's distribution of FFMPEG is not in violation of the LGPL due to patent licenses. Thank you for clarifying what you have stated. I will ask no further questions on that point. But I do have one further question: Can you please tell me if, when I receive Chrome from you, I also receive the patent licensing sufficient to use the Chrome package to practice the patents listed in MPEG-LA's 'essential' patent list for the decoding of H.264? I wouldn't want to break any laws. Yes, you do. Ah, that's interesting. I believe I know the answer, based on your statement No more or less … than … ffmpeg as ffmpeg explicitly does not provide any patent licensing, :) Again, that was specifically about ffmpeg as a component of Google Chrome, not about Google Chrome as a whole. Licensing of projects that use a lot of open source components with a lot of different licenses is a complicated matter, since each component can have a license that is separate than the license for the work as a whole. I'm trying to make sure I am being as explicit as I can about what each subject i am talking about is while still providing answers, so that the answers are the actual answer, but as you can imagine, it's tricky. It can be hard to differentiate between the questions people want to know an answer that is more general than what they asked, and those where they want to know just about that specific thing. When it comes to matters like these, it's usually best for me to just answer the question people actually asked explicitly, and let them ask followups, than it is to try to anticipate what they really wanted to know. It can come off as dodging at times, but i'm doing the best i can ;) Glad you did, since I think this discussion has clarified a lot of things - at least for me. Thanks a lot! Regards, Silvia.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
Yeah, this is really pretty difficult stuff. The lgpl is probably the least understood and most complicated free software licenses. Chris On Wed, Jun 3, 2009 at 2:49 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Jun 3, 2009 at 3:28 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 11:51 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 10:18 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 9:50 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? I'm not saying that at all. I'm simply saying that any patent license we may have does [not] cause our distribution of ffmpeg to violate the terms of the LGPL 2.1 I now understand that your statement was only that Google's distribution of FFMPEG is not in violation of the LGPL due to patent licenses. Thank you for clarifying what you have stated. I will ask no further questions on that point. But I do have one further question: Can you please tell me if, when I receive Chrome from you, I also receive the patent licensing sufficient to use the Chrome package to practice the patents listed in MPEG-LA's 'essential' patent list for the decoding of H.264? I wouldn't want to break any laws. Yes, you do. Ah, that's interesting. I believe I know the answer, based on your statement No more or less … than … ffmpeg as ffmpeg explicitly does not provide any patent licensing, :) Again, that was specifically about ffmpeg as a component of Google Chrome, not about Google Chrome as a whole. Licensing of projects that use a lot of open source components with a lot of different licenses is a complicated matter, since each component can have a license that is separate than the license for the work as a whole. I'm trying to make sure I am being as explicit as I can about what each subject i am talking about is while still providing answers, so that the answers are the actual answer, but as you can imagine, it's tricky. It can be hard to differentiate between the questions people want to know an answer that is more general than what they asked, and those where they want to know just about that specific thing. When it comes to matters like these, it's usually best for me to just answer the question people actually asked explicitly, and let them ask followups, than it is to try to anticipate what they really wanted to know. It can come off as dodging at times, but i'm doing the best i can ;) Glad you did, since I think this discussion has clarified a lot of things - at least for me. Thanks a lot! Regards, Silvia. -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Wed, 03 Jun 2009 09:34:08 +0200, Chris DiBona cdib...@gmail.com wrote: Yeah, this is really pretty difficult stuff. The lgpl is probably the least understood and most complicated free software licenses. Thanks for taking the time to explain it! -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
I mostly wanted to explain our position on the use of the library and the LGPLs. Danny keeps it all straight for us. Happy hacking, everyone! Chris On Wed, Jun 3, 2009 at 3:40 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Jun 2009 09:34:08 +0200, Chris DiBona cdib...@gmail.com wrote: Yeah, this is really pretty difficult stuff. The lgpl is probably the least understood and most complicated free software licenses. Thanks for taking the time to explain it! -- Anne van Kesteren http://annevankesteren.nl/ -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Looping in Dannyb (who may not be on the list, so if necessary, I'll forward) as I'm in the midst of a conference and can't give this the attention it deserves. Chris On Tue, Jun 2, 2009 at 1:19 PM, Håkon Wium Lie howc...@opera.com wrote: Also sprach Chris DiBona: 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). Thanks for your willingness to discuss these matters. So, to be clear, you're saying that situation 2 applies in your case? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On 2 Jun 2009, at 02:58, Chris DiBona wrote: 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 Library. I'm still unclear as to how this does not apply to Chrome's case. If I get a copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the source ffmpeg, and I must be able to redistribute that in either binary or source form. I would, however, get in trouble for not having paid patent fees for doing so. Hence, as that example concludes, you cannot distribute ffmpeg whatsoever. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
Looping in Danny (in transit) On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon foolist...@googlemail.com wrote: On 2 Jun 2009, at 02:58, Chris DiBona wrote: 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 Library. I'm still unclear as to how this does not apply to Chrome's case. If I get a copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the source ffmpeg, and I must be able to redistribute that in either binary or source form. I would, however, get in trouble for not having paid patent fees for doing so. Hence, as that example concludes, you cannot distribute ffmpeg whatsoever. -- Geoffrey Sneddon http://gsnedders.com/ -- Open Source Programs Manager, Google Inc. Google's Open Source program can be found at http://code.google.com Personal Weblog: http://dibona.com
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Tue, Jun 2, 2009 at 3:50 AM, Chris DiBona cdib...@gmail.com wrote: Looping in Dannyb (who may not be on the list, so if necessary, I'll forward) as I'm in the midst of a conference and can't give this the attention it deserves. Chris On Tue, Jun 2, 2009 at 1:19 PM, Håkon Wium Lie howc...@opera.com wrote: Also sprach Chris DiBona: 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). Thanks for your willingness to discuss these matters. So, to be clear, you're saying that situation 2 applies in your case? That would be correct :)
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 8:20 PM, Chris DiBona cdib...@gmail.com wrote: Looping in Danny (in transit) On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon foolist...@googlemail.com wrote: On 2 Jun 2009, at 02:58, Chris DiBona wrote: 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 Library. I'm still unclear as to how this does not apply to Chrome's case. If I get a copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the source ffmpeg, and I must be able to redistribute that in either binary or source form. Which you can. I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do not restrict any of your rights under the LGPL 2.1, is the important part. Hence, as that example concludes, you cannot distribute ffmpeg whatsoever. Not quite :) Nowhere in the LGPL 2.1 are we required to grant you patent rights that we may have. We are only required to ensure any other licenses we may have signed do not prevent us from distributing the library under the terms of the LGPL 2.1, and that we place no further restrictions on use/redistribution/etc of the Library than the terms of the LGPL 2.1. Note that the actual *clause* (not the example) in question says 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. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. In short, the only thing this clause does is prevent you from getting a license that restricts your ability to fulfill the obligations of the other clauses of the LGPL, or would restrict the ability of those downstream to fulfill their obligations. No patent license we have does that. --Dan
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Wed, Jun 3, 2009 at 11:29 AM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 8:20 PM, Chris DiBona cdib...@gmail.com wrote: Looping in Danny (in transit) On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon foolist...@googlemail.com wrote: On 2 Jun 2009, at 02:58, Chris DiBona wrote: 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 Library. I'm still unclear as to how this does not apply to Chrome's case. If I get a copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the source ffmpeg, and I must be able to redistribute that in either binary or source form. Which you can. I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do not restrict any of your rights under the LGPL 2.1, is the important part. Let me ask for more clarification here, since you seem to have a really good understanding of the legal implications. It seems to me that if I have decided for whatever reason (probably because I did not want to use a library that is likely to infringe on patents) that I did not want to have ffmpeg installed on my computer, and I installed Chrome, that in this case I would get a library installed on my computer without being aware of it. Or turned the other way - if I knew that Chrome comes with ffmpeg and I really didn't want ffmpeg installed on my computer, I could not use Chrome. Is this correct? I know full well that this is a theoretical example and that patent holders don't normally go after end users for patent infringements. However, I am asking for legal clarification and whether this has been thought through. Regards, Silvia.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself?
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 9:38 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, Jun 3, 2009 at 11:29 AM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 8:20 PM, Chris DiBona cdib...@gmail.com wrote: Looping in Danny (in transit) On Wed, Jun 3, 2009 at 1:38 AM, Geoffrey Sneddon foolist...@googlemail.com wrote: On 2 Jun 2009, at 02:58, Chris DiBona wrote: 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 Library. I'm still unclear as to how this does not apply to Chrome's case. If I get a copy of Chrome, you are bound (by the LGPL) to provide me with a copy of the source ffmpeg, and I must be able to redistribute that in either binary or source form. Which you can. I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do not restrict any of your rights under the LGPL 2.1, is the important part. Let me ask for more clarification here, since you seem to have a really good understanding of the legal implications. It seems to me that if I have decided for whatever reason (probably because I did not want to use a library that is likely to infringe on patents) that I did not want to have ffmpeg installed on my computer, and I installed Chrome, that in this case I would get a library installed on my computer without being aware of it. Or turned the other way - if I knew that Chrome comes with ffmpeg and I really didn't want ffmpeg installed on my computer, I could not use Chrome. Is this correct? No, it isn't. I'm told if you remove the ffmpeg dll, Chrome should still function properly, it should just not recognize video as a valid tag.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 9:50 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? I'm not saying that at all. I'm simply saying that any patent license we may have does cause our distribution of ffmpeg to violate the terms of the LGPL 2.1 Chrome as a whole is a work that uses the library, and as such is covered by the terms of section 6 of the LGPL 2.1. This section provides you are allowed to distribute the work under whatever terms you want as long as you perform one of a set of choices they give (such as using the library as a replaceable shared lib) as well as meet a few requirements in your distribution terms (which we do by allowing those requirements to supersede the EULA by clause 1.2 in the Chrome EULA)
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 10:18 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 9:50 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? I'm not saying that at all. I'm simply saying that any patent license we may have does ^^ NOT Sigh.
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 10:18 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 9:50 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? I'm not saying that at all. I'm simply saying that any patent license we may have does [not] cause our distribution of ffmpeg to violate the terms of the LGPL 2.1 I now understand that your statement was only that Google's distribution of FFMPEG is not in violation of the LGPL due to patent licenses. Thank you for clarifying what you have stated. I will ask no further questions on that point. But I do have one further question: Can you please tell me if, when I receive Chrome from you, I also receive the patent licensing sufficient to use the Chrome package to practice the patents listed in MPEG-LA's 'essential' patent list for the decoding of H.264? I wouldn't want to break any laws. I believe I know the answer, based on your statement No more or less … than … ffmpeg as ffmpeg explicitly does not provide any patent licensing, but it seems surprising so I am asking for clarification. A simple yes or no will suffice. Thank you!
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
On Tue, Jun 2, 2009 at 11:51 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 10:18 PM, Daniel Berlin dan...@google.com wrote: On Tue, Jun 2, 2009 at 9:50 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Jun 2, 2009 at 9:29 PM, Daniel Berlin dan...@google.com wrote: [snip] I would, however, get in trouble for not having paid patent fees for doing so. No more or less trouble than you would have gotten in had you gotten it from ffmpeg instead of us, which combined with the fact that we do For the avoidance of doubt, Are you stating that when an end user obtains Chrome from Google they do not receive any license to utilize the Google distributed FFMPEG code to practice the patented activities essential to H.264 and/or AAC decoding, which Google licenses for itself? I'm not saying that at all. I'm simply saying that any patent license we may have does [not] cause our distribution of ffmpeg to violate the terms of the LGPL 2.1 I now understand that your statement was only that Google's distribution of FFMPEG is not in violation of the LGPL due to patent licenses. Thank you for clarifying what you have stated. I will ask no further questions on that point. But I do have one further question: Can you please tell me if, when I receive Chrome from you, I also receive the patent licensing sufficient to use the Chrome package to practice the patents listed in MPEG-LA's 'essential' patent list for the decoding of H.264? I wouldn't want to break any laws. Yes, you do. I believe I know the answer, based on your statement No more or less … than … ffmpeg as ffmpeg explicitly does not provide any patent licensing, :) Again, that was specifically about ffmpeg as a component of Google Chrome, not about Google Chrome as a whole. Licensing of projects that use a lot of open source components with a lot of different licenses is a complicated matter, since each component can have a license that is separate than the license for the work as a whole. I'm trying to make sure I am being as explicit as I can about what each subject i am talking about is while still providing answers, so that the answers are the actual answer, but as you can imagine, it's tricky. It can be hard to differentiate between the questions people want to know an answer that is more general than what they asked, and those where they want to know just about that specific thing. When it comes to matters like these, it's usually best for me to just answer the question people actually asked explicitly, and let them ask followups, than it is to try to anticipate what they really wanted to know. It can come off as dodging at times, but i'm doing the best i can ;) --Dan
[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 Library. 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: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ 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: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium?revision=16648view=markup 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-wha...@yahoo.com wrote: Thank you for a very informative reply. Inline comments follow. --- On Sun, 5/31/09, Gregory Maxwell gmaxw...@gmail.com wrote: From: Gregory Maxwell gmaxw...@gmail.com Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec To: whatwg@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
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Chris DiBona: 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). Thanks for your willingness to discuss these matters. So, to be clear, you're saying that situation 2 applies in your case? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
