While looking through the updated libvpx library included since Firefox 28, I noticed a potentially severe legal issue: The patent grant (summarized in PATENTS) grants a use license for Google's copyrighted IP in the WebM video format, but this grant only applies to VP8. The newer codec, VP9, is not mentioned anywhere in the grant, and as such is fully patent-encumbered and can't/shouldn't be used by Mozilla, Firefox, or any Mozilla-derived products (SeaMonkey, third-party builds, forks, etc.). I verified with the latest version on gitweb/chromium, and the PATENTS included there is unchanged, i.e.: not including a grant for anything but VP8. I can only assume this means that it hasn't been granted for VP9 upstream either, and all Mozilla products including libvpx 1.3.0 and later would be in violation of Google's IPR as a result.

This belongs in the legal component.

(In reply to Chris Pearce (:cpearce) from comment #1) > This belongs in the legal component. I wasn't aware such a thing existed, since it's apparently hidden from view when reporting; I picked the closest component I could find.

While it is not expressly stated in /media/libvpx/PATENTS This news release and blog post seems to allow one successor generation IE VP9. "The agreements also grant Google the right to sublicense those techniques to any user of VP8, whether the VP8 implementation is by Google or another entity. It further provides for sublicensing those VP8 techniques in one next-generation VPx video codec." from http://www.businesswire.com/news/home/20130307006192/en/Google-MPEG-LA-Announce-Agreement-Covering-VP8#.U6jW5R2KCHt -AND- "It further provides for sublicensing those VP8 techniques in one successor generation to the VP8 video codec" from http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html However, I really do think this should be clearly stated so it may be advantageous to contact the parties to get the actual updated agreement for inclusion in the source code to avoid any future confusion.

(In reply to Matt A. Tobin from comment #3) > This news release and blog post seems to allow one successor generation IE > VP9. As far as I can tell, they don't. The first reference only talks about the grant given to use VP8 techniques, and allowing those VP8 techniques to also be incorporated in a larger works (VPx) but doesn't talk about VP9 techniques or its (different) patents. While the second reference does talk about a successor, it talks about the permission to use VP8 techniques in that successor (avoiding any patent conflicts for using parts of VP8 in VP9); it does not talk about new techniques that are a protected and an integral part of it. Considering the relatively large differences between VP8 and VP9 in terms of compression and delivery, you can't say that VP9 is a direct descendant of VP8 and should be considered "significantly different". > However, I really do think this should be clearly stated so it may be > advantageous to contact the parties to get the actual updated agreement for > inclusion in the source code to avoid any future confusion. Most definitely. Clarity is certainly needed in this respect, and without this clarity and a clear and official statement from the patent owners, you should consider removal.

Thanks Mark for bringing your concerns to our attention. I'm adding Tim Terriberry who has corresponded with Google.

I wrote to Matt Frost at Google about this issue, who responds: "We should release revised license language soon. That license will further clarify that we're making our VP9 patents available on the same terms as we make our VP8 patents available. You should feel free to share this last comment with the Mozilla community, if you think that would be helpful."

Since Google has said their comment can be shared with the Mozilla community and it looks like no legal review is needed, I'm converting this back to a non-legal bug.

(In reply to Timothy B. Terriberry (:derf) from comment #6) > I wrote to Matt Frost at Google about this issue, who responds: > > "We should release revised license language soon. That license will further Should, indeed. Any idea what "soon" is? I'm actually really surprised this wasn't picked up at the time the new codec was introduced, and that the appropriate license isn't even available yet. Please update this bug when more information is available on this issue - I'd like to incorporate/use VP9, but won't until this is licensed, of course. Can someone with bug edit powers also please change the state to something that is confirmed so it doesn't get forgotten about?

Any update on Google's actions in this respect? 3 weeks down the road I haven't seen anything. Are you sure you want to keep releasing Firefox with this issue still outstanding?

Some progress: https://code.google.com/p/webm/issues/detail?id=779 Don't be confused by comment 2 on that issue, the actual substitution that was done was s/VP8/WebM/g.

Does that work, legally? IIUC WebM is just a container, and the actual codecs are individually patented and not part of the WebM container specification.

Oh, and another thing I didn't think of: With libvpx I assume you can use the codecs without wrapping the streams in a WebM container - so it wouldn't work for the lib, either, then, and in fact would no longer grant the use of either codec through the lib... i.e.: I don't think Google's response addresses this issue.

(In reply to Mark Straver from comment #12) > the codecs without wrapping the streams in a WebM container - so it wouldn't > work for the lib, either, then, and in fact would no longer grant the use of > either codec through the lib... The actual text says: > "These implementations" means the copyrightable works that implement the WebM > codecs distributed by Google as part of the WebM Project. AFAICT, nothing about the container comes into this at all.

> "These implementations" means the copyrightable works that implement the WebM > codecs distributed by Google as part of the WebM Project. Ah, okay. "WebM codecs ... part of the WebM project" would include any codec part of the WebM project, then. Its the problem with WebM being ambiguously used for the container, the project, the video file format, etc. As long as the grant clearly means the patented bitstream formats when talking about WebM, that should solve the problem. It could still certainly do with a rewrite and clarification though, and I think the bitstream formats should specifically be named. (e.g.: What happens to the grant for libvpx when Google decides to no longer use VP8 in their WebM project?)