Hector Martin

huh, that's a good point pity I've never gotten around to contributing anything to either webkit or chromium upstream

It also statically links ffmpeg. Not totally obvious, because the version strings get optimized out, but it's definitely in there. $ strings chrome|grep -i ffmpeg, Not yet implemented in FFmpeg, patches welcome (see libavutil/error.c)

Then it's an LGPL violation. The LGPL requires that the user be able to relink your code with a modified LGPL library.

Isn't linking LGPL lib from proprietary code allowed? I believe that what differentiate GPL from LGPL. As long as the (possibly) modified lib has its source published somewhere, I'd say it's okay (but not ideal)

From the LGPL preamble: "If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it." The terms and conditions spell out the details.

LGPL only means you need to be able to relink, not have the full sources. Sources for the LGPL part + .o for the proprietary part is sufficient. Dynamically linking the LGPL code also satisfies the requirement.

wouldn't this only be a problem if blink links to the binary part, not the rest of the chrome code. Else opera have an even bigger problem. https://chromium.googlesource.com/chromium/src.git/+/master/LICENSE … is the licence for the whole project.

The `chrome` binary includes Blink, therefore if that binary cannot be built from Chromium code, it includes proprietary parts and everything is linked together. That file is not the license for the whole project. It's just the top-level license. Blink is licensed differently.