| |||||||||||||
An unfortunate descriptionAn unfortunate descriptionPosted Mar 15, 2012 16:42 UTC (Thu) by slashdot (guest, #22014)In reply to: An unfortunate description by gmaxwell Parent article: Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (ars technica)
Does that mean that using Microsoft's license doesn't cover users of the H.264 codec in Windows 7?
What if Firefox runs Windows Media Player or Flash player in an hidden window (or equivalent hack) and extracts the frames?
What if Firefox automatically downloads ffdshow but doesn't ship it?
What if Firefox automatically downloads a Windows 7 update for Windows Media Player and/or the Microsoft H.264 codec, extracts the binaries from it and runs it on Windows XP via suitable hacks?
Some legal investigation of these things seems quite essential, especially since 6 million dollars per year for H.264 licensing are a significant portion of Mozilla's 43 million income that Wikipedia reports.
(Log in to post comments)
An unfortunate description Posted Mar 15, 2012 17:51 UTC (Thu) by khim (subscriber, #9252) [Link] Some legal investigation of these things seems quite essential, especially since 6 million dollars per year for H.264 licensing are a significant portion of Mozilla's 43 million income that Wikipedia reports. This may be so, but do you really feel it's wise to try to find loopholes in licenses (many of which are not available to general public) for critical browser's functionality? It's obvious that lawyers have tried very hard to make sure answer to questions presented above are all “no”. It is possible that they made a mistake in some custom contracts and something like this is possible today. But do you want to rely on the further availability of such loopholes when you know for sure MPEG-LA will try to close them ASAP? Does that mean that using Microsoft's license doesn't cover users of the H.264 codec in Windows 7? Yes and no. The general stance of MPEG-LA is: we don't care about technical details. You may use binaries from Windows ffdshow or Flash, from Media Player or from x264. We don't care. As in: totally. If your program shows encodes or decodes H.264 then it needs a license - period. But yes, this is just a general stance. MPEG-LA it also offers extended license (for example you can distribute Windows Media Player and use it to show video to the user), but of course these licenses are carefully crafted to make sure other vendors will still need to pay if they will try to create some kind of “advanced” functionality (similar to what <video> tag allows). Oh and these licenses are, obviously, are subject to change (this is important to make sure all loopholes similar to what you are discussing) can be closed quickly. Some things are truly hilarious: for example most professional videocams include “only for non-commercial use” MPEG4 license. Of course MPEG-LA will not try to use that clause to sue Hollywood - but it can use it if someone will try to use these things to circumvent MPEG-LA requirements as you've suggested above.
An unfortunate description Posted Mar 15, 2012 18:28 UTC (Thu) by rqosa (subscriber, #24136) [Link] > If your program shows encodes or decodes H.264 then it needs a license - period. If that's true, that means that every program that uses any sort of external media playback API (including DirectShow, GStreamer, xine, QuickTime, and even the ancient "Media Control Interface" from Win3.x and OS/2) without explicitly whitelisting codecs needs an MPEG-LA patent license. But why stop there? Under that reasoning, any software that uses any API whatsoever must be in violation of some patent — because the implementation of that API might contain a patented algorithm. That would apply equally to both library APIs and kernel system call APIs. So to summarize, your reasoning inevitably leads to the conclusion that all software that runs on any operating system is violating every software patent ever. (Of course, what this really tells us is that what you're saying is actually false. It's just like the situation there was in the 1990s with US export restrictions on cryptographic software — developers worked around the restrictions by making their apps not perform cryptography themselves, but instead use external libraries such as OpenSSL, and these libraries were then hosted on servers outside of the US.)
An unfortunate description Posted Mar 15, 2012 20:35 UTC (Thu) by khim (subscriber, #9252) [Link] If that's true, that means that every program that uses any sort of external media playback API (including DirectShow, GStreamer, xine, QuickTime, and even the ancient "Media Control Interface" from Win3.x and OS/2) without explicitly whitelisting codecs needs an MPEG-LA patent license. No. This is covered by broad OS license. It basically covers “personal and non-commercial use” - this is the same terms you'll find on license for bazillion products. But if you'll try to pull the software from one (properly licensed) player or OS and embed it in another player or OS then of course license is not transferred. It's just like the situation there was in the 1990s with US export restrictions on cryptographic software — developers worked around the restrictions by making their apps not perform cryptography themselves, but instead use external libraries such as OpenSSL, and these libraries were then hosted on servers outside of the US. Yahoo! Now you get it. It just so happens that I worked on crypto packages back then thus I know how the whole thing worked from personal experience, not from some narration of narration. Yes, people used external libraries hosted outside of the US. BUT THESE VERSIONS WERE ILLEGAL TO USE IN US BECAUSE OF RSA PATENT. Another, different version of program with PROPERLY LICENSED library was sold in US. It was huge PITA: it was impossible to use one library both in US and outside. US-licensed library was not exportable because of crypto regulations and NON-US version was illegal in US because of RSA patent. When something worked in US and refused to work outside (on vice versa) it was impossible to run two versions side-by-side! These were the days…
An unfortunate description Posted Mar 15, 2012 21:09 UTC (Thu) by rqosa (subscriber, #24136) [Link] > I know how the whole thing worked from personal experience So does anyone who remembers compiling the OpenSSL-enabled variants of programs (e.g. Lynx) that existed back then. > BUT THESE VERSIONS WERE ILLEGAL TO USE IN US BECAUSE OF RSA PATENT. Well, I was actually talking about the former export restriction laws, not the RSA patent. But the same principle applied either way: the legal encumbrance only applied to the library that contains the algorithm in question, not to programs (or other libraries) that call into that library. In other words, if you distribute the program without bundling the legally-encumbered library it uses, you're free from any legal trouble. That's the situation that Mozilla would be in if they made Gecko depend on GStreamer, and then distributed Gecko in only these three ways: as source code (thus not including GStreamer), as a binary built against OS-provided GStreamer (thus not including GStreamer), and as a binary bundled with a custom build of GStreamer that's had all its codecs and containers stripped out except for the ones Mozilla wants to support (thus not including the patented parts of GStreamer). > Another, different version of program with PROPERLY LICENSED library was sold in US. But there wasn't any legal requirement for the US version of the program (not the library) to be "different" from the non-US version. (If they were different from each other, it was because the cryptography libraries were being linked statically, or because the US and non-US cryptography libraries didn't use the same API/ABI as each other, or both of those reasons.)
An unfortunate description Posted Mar 15, 2012 21:52 UTC (Thu) by khim (subscriber, #9252) [Link] But there wasn't any legal requirement for the US version of the program (not the library) to be "different" from the non-US version. There was: patent license. Actual binary was exactly the same, but accompanying license was different.
An unfortunate description Posted Mar 15, 2012 22:09 UTC (Thu) by rqosa (subscriber, #24136) [Link] > Actual binary was exactly the same Well, that hardly qualifies as a "different version of program", then.
An unfortunate description Posted Mar 15, 2012 22:20 UTC (Thu) by rqosa (subscriber, #24136) [Link] And furthermore: in Mozilla's case, they wouldn't need a different license, because in either case (GStreamer or no GStreamer) they wouldn't be distributing any patent-encumbered codecs. (I believe that the only possible legal reason for the "different license" on the software you're talking about there could have been was that it bundled the cryptography library as a .so / .dll along with the executable, or something like that.)
An unfortunate description Posted Mar 16, 2012 5:48 UTC (Fri) by khim (subscriber, #9252) [Link] I believe that the only possible legal reason for the "different license" on the software you're talking about there could have been was that it bundled the cryptography library as a .so / .dll along with the executable, or something like that. No. The fact that it was sold as PGP-compatible solution was basically enough. If your software is useful without H.264 codecs and can only use them is they are found on the target system then you can probably get away with it. But if you'll start actively encourage people to download H.264 codecs from shady sources to get “the full experience” then you may be accused in evasion of patent (that's why Fedora does not link to unofficial repos with codecs, for example).
An unfortunate description Posted Mar 16, 2012 12:07 UTC (Fri) by ekj (guest, #1524) [Link]
But that's mostly a question of wording. "Download h264 codecs from here to make Firefox play those movies" might get you into trouble.
But: "Firefox will play any movie for which your system has the appropriate codecs installed." will definitely not. (it's just a statement of fact, and it doesn't have anything to do with h264 or any other specific codec, it's a general mechanism.)
|
|||||||||||||