OSS Watch team blog

HTML 5 - the next version of the language used to create web pages - is due to be finalised somewhere between 2010 and 2012, depending on whether you believe the W3C or the WHATWG, the two groups who are contributing to the language specification. One of the expected benefits of the new version is that it will allow page authors to reference and embed videos in their pages without requiring end users to have a specific browser plugin installed. At the moment, Adobe’s Flash and Apple’s Quicktime are the most popular methods for getting video into web pages, but this irks many web purists who feel that the requirement to install these plugins undermines the goal of a truly ‘open’ standards-based web. After all, while web video playback depends upon vendor-specific software, the vendors in question have enormous power to control which browsers and operating systems they will support and therefore which will be widely used. There is of course a powerful pragmatic counter-argument to this, which says that the success of the web is driven by adoption not contemplation and any solution that has been generally adopted has to be considered the correct one. If you are a business wanting to outshine your competitor’s web presence, you are likely to adopt whatever is the most attractive, eye-catching and available technology at the time without worrying to much about high-minded ideals of openness. Into this argument, HTML5 - and specifically its <video> tag - strides to resolve the question once and for all.  That at least was the idea. 

 Proprietary plugins are not the only things that threaten the ‘open’ web. Patents covering the use and creation of certain types of media file are also a problem. It would be fairly pointless to sweep away proprietary video playback plugins if you then replace them with in-browser functionality that requires a patent licence to actually include. Therefore as well as mandating that compliant browsers should be able to playback video URLs indicated by the <video> tag, the HTML5 specification originally directed that every browser should - at the very least - be able to decode the ogg theora multimedia encoding format. Theora - named after a character from Max Headroom an 80s sci-fi TV drama - is an open standard for the encoding of video which is of a similar quality to the patented H.264 MPEG4 encoding standard used in Quicktime and on many Blu-Ray High Definition video discs. Theora derives from work done by technology firm On2 who have granted a worldwide royalty-free licence to anyone who wishes to incorporate theora encoding and decoding functionality into their products. The software for actually doing the encoding and decoding is released under the open source BSD licence. It all sounds great I’m sure you’ll agree - patent-free video (and audio - ogg has a project called vorbis that handles that) playing right in your browser and no-one has to install a plugin or pay a patent licence.

 Unfortunately Apple and Nokia - companies that would be creating HTML5 browsers in the future - lobbied successfully to have the theora/vorbis mandate removed. Nokia puzzlingly claimed(pdf) that theora was proprietary, and less puzzlingly pointed out that the format had no accompanying Digital Rights Management implementation that might help providers make money from their content. Apple argued that although the On2 patents in theora were licensed royalty-free, there was no guarantee that there were not other video-related patents out there that might be infringed upon by theora (particularly submarine patents - meaning patents that have yet to be fully published for administrative reasons but which it is still possible to inadvertently infringe). Apple also claimed that there were few-if-any hardware implementations of theora decoders, meaning that low-powered devices like mobile phones could not incorporate a specialised decoding chip to take the pressure of video work off their overworked central processors and sagging batteries. Open web enthusiasts pointed out that no video format is free of submarine patent concerns, and mandating theora in HTML5 would almost certainly mean that there soon would be theora decoding hardware available. Some uncharitable commentators also pointed out that Apple held one of the essential patents for MPEG4 decoding, and so stood to make money from additional licence sales if MPEG4 became a common format for the contents of the HTML5 <video> tag. 

So the issue was already a vexed one when last week Google announced on the WHATWG mailing list that their support for the <video> tag in version 3 of their browser Google Chrome was going to use LGPLv2.1-licensed free software video library ffmpeg to decode both theora and MPEG4 H.264. Why was this controversial? Well as I mentioned above, H.264 is subject to a whole cupboard-load of patents, and anyone who looks like they have a bit of money would be well advised to get a comprehensive licence from the relevant group or be prepared for a writ on the corporate doormat one morning. Clearly anyone with a pocket-book the size of Google’s would have taken this essential step. However even doing this might well not allow you to distribute ffmpeg safely. The LGPLv2.1 - like the GPLv2 - contains a clause which aims to prevent the software it covers becoming subject to additional responsibilities and fees. This clause (section 11) reads:

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.  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 clause is generally understood to mean that paying for patent licences to distribute LGPLv2.1-licensed code is impossible; once you pay for the licence you lose your right to distribute, so it’s never worth doing (and this in turn acts as a deterrent to patent owners looking to get per-copy royalties on LGPLv2.1- and GPLv2-licensed software - even if you win the case against the distributor, you kill the product and will get no royalties going forward). Nevertheless, Google’s lawyers seemed to have found a way through waters which had previously been thought unnavigable. As the argument on the thread continued, it emerged that Google’s approach had been to seek a patent licence for Chrome itself, not the ffmpeg library that was actually doing the video decoding. The LGPLv2.1 is designed to allow code it covers to co-exist in an uneasy peace with code covered by any other kind of licence, including patent licences. In this was free software libraries could be used with proprietary software in a way that would be impossible if they were covered by the full GPLv2. Google argued that as long as they never sought patent rights to use ffmpeg, no-one could accuse them of not passing on those rights to others in a way that ffmpeg’s licence mandated. All their permissions to use patents rested with Chrome itself - however it chose to do the decoding. 

 Now this is a sly move, and not one that has been attempted in as high-profile a piece of software as Chrome up to now. Will Google get away with it? Well that question really reduces to the question: Who might try to stop them? In this case Google Chrome is relying on licences from the MPEG-LA for the patents used to decode MPEG4 (and possibly theora if they want to rule out any future challenges from MPEG-LA on that score) and a software licence from the ffmpeg project. The likelihood is that Google have paid well for complete coverage from the MPEG-LA, and so a challenge from that quarter seems unlikely. What about the ffmpeg project?  Well they clearly explain that they have no specific knowledge of any patents infringed by distributing ffmpeg. Of course, everyone is aware that the project very likely infringes on many patents in the H.264 patent pool at the very least, but time and experience has taught programmers operating in patent-rich problem domains to never read the relevant patents. It only increases the likelihood that you will infringe upon them and increase the damages if it can be shown that you knowingly infringed. What this means for ffmpeg is that it would be very difficult for them to argue that Google is not in compliance with the LGPLv2.1 for ffmpeg because they have licensed some patents ostensibly for use in Chrome. To do so they would have to explain exactly which of the patents licensed were in reality embodied in ffmpeg, and would therefore trigger Google’s responsibilities inder the LGPLv2.1. This could be seen as an unwise move for ffmpeg. With neither the MPEG-LA or ffmpeg likely to question Google’s actions, it seems likely they will get no substantial challenge to their actions.