El GPL, Two and a smidgen more

Google raised eyebrows recently when it talked about its use of FFmpeg in Chromium for H.264 playback. The code in FFmpeg that Google is using is available under the LGPL 2.1 license. Apparently Google says it has a patent license (which we’ll probably never get to see) that covers H.264 playback in Chromium. Now there are lots of pundits out there on Slashdot who hast spoke their piece, several of whom question whether Google’s distribution of Chromium + LGPLed FFmpeg + undisclosed H.264 patent license is legal.

I can’t tell you if what Google is doing is legal — legal advice is the department of the SFLC guys — but I do have an interesting take on the situation and wonder if Google hasn’t gotten itself into a very sticky situation. Let’s first set the stage:

1) The LGPL 2.1 includes some text about patents:

Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. 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.

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.

2) As I said before, Google has indicated that it has a patent license for the H.264 codec — at least when used with Chromium + a chunk of FFmpeg. I’m not clear if the license is just for official Chromium builds (aka “Chrome” builds), or all Chromium builds.

Okay, now that the stage is set, let’s start!

Let’s say that I download a copy of Chrome today (I think it might have to be a beta or nightly in order to get the FFmpeg additions). I now have in my possession a binary copy of Chrome with FFmpeg linked in and, presumably, the Power and Might of Google’s H.264 patent license which gives me protection from being sued by the H.264 patent holders for playback of H.264-encoded media in this particular build of Chrome.

The Chrome executable has a copy of FFmpeg linked in. The LGPL 2.1 describes the terms under which this linking is allowed:

6. …you may also combine or link a “work that uses the Library” with the Library to produce a work containing portions of the Library… [if you do so, you must either include source] so that the user can modify the Library and then relink to produce a modified executable containing the modified Library, … [u]se a suitable shared library mechanism for linking with the Library, [or offer to give source, make sure they already have the source, etc…].

So the way I see it, that section of the LGPL indicates that if you link against a particular library, you must provide the user with a way to link in a different library if they so desire. And if that’s the case, then when I link a new library into my build of Chrome — let’s call it qubitqubit-mpeg — then I should have the same patent protection from the H.264 patent holders that I had with the original Chrome build, “consistent with the full freedom of use specified in… [the LGPL 2.1] license”.

Here’s where it gets interesting. If I have a patent license to use FFmpeg linked in to Chrome, what if I un-link the FFmpeg code and use it to decode H.264-encoded material outside of Chrome? If, by linking my qubitqubit-mpeg library into Chrome, I then have the same patent protection for Chrome + qubitqubit-mpeg as I did for Chrome + FFmpeg, may I then separate the qubitqubit-mpeg code out of the combination and still have patent protection on just the library?

Even if separation is not allowed under the patent license, could I instead use the Chrome + FFmpeg binary as a library itself? If I wrote qubitqubit-mpeg to shove all decoded data out to files on disk, I could just feed the program encoded files and then pull the decoded data off disk. A bit kludgy, but it would be a nifty hack.

Now let’s say that the lawyers tell me that the patent license is very specific and only covers the specific Chrome + FFmpeg binary that Google creates. Linking in a different library is possible, they say, but if you do change the library then you loose your patent protections. If that’s the case, I’d argue that the mechanism whereby Google links in FFmpeg is obviously breaking the LGPL 2.1 as Google is “…restrict[ing] the users of a free program by obtaining a restrictive license from a patent holder,” something forbidden by the LGPL 2.1 license.

Looking at the bigger picture, this wouldn’t even be an issue if software patents had been nixed a long time ago. But software patents are here for now (hopefully not for too long, if the SCOTUS has anything to say about it) and we need to continue to address the software patent issue whenever it comes up in Free Software whether it’s Chrome or the Linux kernel VFAT code or anywhere else. It’s a two-pronged approach: (1) Campaign to End Software Patents, (2) Put out software patent fires in the meantime.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s