Sure. H.264 is something that's absolutely patentable in my book: it's novel, non-obvious, etc. It's just unfortunate, as you say, that the details of the licensing don't coexist well with open-source software (or anything else where the marginal cost of an extra decoder or encoder would otherwise be 0, in some ways).
> Removing Firefox as a viable option by implementing Theora only would do harm to the web > and its users
You're assuming that this would remove Firefox as a viable option. In the short term, that's very unlikely (e.g. Youtube continues to work in Firefox). In the longer term, if nothing changes, maybe Mozilla would in fact end up feeling forced to implement H.264 support.
> all in the name of some "holy" crusade for FOSS principles
Did you read the article? The "holy principle" in question here is that anyone should be able to put up video on the web and anyone should be able to view it. That seems to be a pretty key part of how the web is supposed to work.
> Firefox is not developed by the community.
It's developed by whoever cares to develop it, actually. In the last three months, I've seen at least 4 different people show up, dive in, fix things that were bothering them.
In general, the direction of any large project is set by its core contributors. In the case of Mozilla, they happen to have been able to hire a large fraction of the core contributors, so they're actually paid for their contributions. The direction is still set by said individual contributors.
Yes, if by "bad situation" you mean "lack of a sane unencumbered format for web video". The question is whether having all browsers support an encumbered format Right Now is the best way to make the best of that bad situation.
> But how is that worse than the current situation where they have no support on any machine?
Because right now you don't have a situation where someone writes a web page, it works fine on their computers, and then breaks on 60% of computers out there. That's really not a good situation to be in.
> But they already load badly written code in several different ways, and that never was an > argument against extensions or plugins
Oh, it's an argument against both. If they weren't quite as established as they are right now, in today's security climate they would be done _very_ differently.
Note that there's ongoing work to sandbox extensions to some extent and to move plugins to a diffferent, sandboxed if possible, process. Also note that there is code in place to blacklist extensions and plugins if they're being exploited and not being fixed. One could do the same for codecs, of course, but it's really just making the best of a bad situation.
The only major players in the browser market who don't, and who have said they won't are Apple (which is shipping H.264 by default and can have quicktime plug-ins to support theora) and Microsoft (which isn't shipping anything in this space yet).
That said, Firefox isn't GPL. It's MPL/LGPL/GPL tri-licensed, so it may well be able to legally license H.264 if it really really wanted to. Whether that would be worse than having a very large percentage of the current core contributors unable to work on the browser is a tough call.
You apparently didn't read the article. The issue is not that Mozilla can't get a license; it can. The issue is that it sees doing so as actively harmful to the web and to users.
> H.264 is a free and open standard, just not in the US.
Or France or Germany, last I checked (as in, there are H.264 patents that have been granted by those countries; these are not _software_ patents but patents on the design of the codec). I haven't looked into detail for other countries, but I think you're making some unjustified assumptions here (like "h.264 patents are software patents").
Citation please? Everything I can locate suggests otherwise. Now it happens that the trust fund holdings are US Treasury Bonds, but those are in fact assets.
Now it's true that redeeming these bonds will drain money from the general budget, but that's not exactly the fault of the SSA. What form did you expect the SSA to hold the funds in? Buckets of dollar bills? Gold bars? A NASDAQ index fund? They all have issues just as bad as Treasuries, if not worse.
> If social security were run by a private company instead of the government
Then you would still call holdings of treasury bonds "IOUs"? Seriously, the only one here applying a double standard is you.
I don't think anyone's ignoring those facts. In particular, no one is under the illusion that ogg is a suitable replacement for h.264 in all cases. The hope is that a better codec than either will appear with more suitable licensing terms; in the meantime a premature standardization on h.264 would hurt the chances of that codec being adopted when it appears, no?
On the other hand, you seem to be ignoring the fact that Wikipedia, say, has no plans to put its video in H.264 (so Safari, say, can't very well view it).
> Time for Mozilla to face reality and pay up the license as Apple and Google have done.
As a side note, Apple and Google did not have to pay for a license separately here. They already had the licenses.
> Otherwise, watch Chrome really destroy Firefox
If that were to start happening (and it's nowhere close yet), the calculation might have to change, of course.
Google is not dumb. One major effect of a broadcast licensing fee for all web video is to make it harder to set up a Youtube competitor. Sure, Google has to pay the fee too. But it might well be worth it to them given the stifling of potential competition.
> I'm just wondering what makes the Firefox team certain they can write these codec > implementations and players better than the teams who specialise in that field.
Nothing. That's why they're not writing the codec impl they're using; they're using an off-the-shelf theora decoder (though they've contributed a bunch back to it in the process of integrating it).
But the result is that the codec they're shipping they have the source for and have at least some people who can competently patch that source in the event of a security hole being discovered, while also sending the patch upstream.
As for the player... The player being used is pretty much off-the-shelf too, as above, but the method of feeding data into it had to be custom-written to deal sanely with HTTP, security restrictions in the browser, etc.
> no reason to believe that a volunteer for a browser project
I believe everyone working on the Theora support in Firefox was in fact a full-time employee whose job it was to make it work.
> I know Quicktime / ffmpeg / etc are all open to system flaws and attack, but what code > isn't.
Sure. The question is what happens once such a flaw is discovered. If you're not Apple and you depend on Quicktime and a hole is discovered in Quicktime, what are your options? Have a security hole or stop playing videos until Apple patches it? The situation is, of course, better with ffmpeg.
For what it's worth, $54k does buy a 4-year education at most state schools (though not all). It buys about 1 year at most private schools nowadays....
Right. And more to the point, it's not realistic to have a browser support all codecs "supported" by the spec. Have to pick and choose somehow (if only by picking which system libraries one uses).
> They are aware of the issue but they don't have a production ready solution.
"They" (we) are in fact aware of the issue, and feel that H.264 as the "standard" web video format is in fact detrimental to the long-term health of the web and to Mozilla's mission (which is not to make a web browser; the web browser is a means to an end).
> they will eventually have to support all of the codecs in the HTML5 standard
That can almost work ok until this someone else's code you have no control over ends up with a security hole that's being exploited. Then what courses of action do you have?
It would be legal for Mozilla to distribute Firefox if it did that. It would not be legal for anyone else to do so.
For example, if you put a copy of Firefox on your USB keychain and went over to your friend's house and installed it there (from that keychain) without paying the H.264 licensing fees required, you could be sued for damages. Not much in the way of damages, clearly, but you would in fact be liable for them.
Of course if you happened to be, say, Ubuntu, you would have to pay a pretty hefty fee (or be liable for significant damages) if you shipped Firefox as part of your distribution.
> I consider over a year of warning with no implementation in production 'unprepared'.
You're assuming that the goal was to support H.264. That's not in fact a goal at the moment, because it's seen as detrimental to the future of video of the web (though of course beneficial to several big companies today).
That's the subscription side of the licensing, you're correct. The big wildcard is the "broadcast" side, also known as "put that one video on my blog". It's free through the end of this year; after that we'll see what the licensing terms look like.
> I'm not sure if Google does (can't think which apps it would be)
The unit count is for decoders _or_ encoders. So Google is almost certainly already paying the licensing fees per unit for any machine involved in transcoding Youtube videos, say. They may well be hitting the cap with just that.
> where code that is written in any other codeshop is considered inferior
Not at all. I've written my share of code with security bugs in it and have no illusions about code I write.
But the key thing here is attack surface. Taking a shot at securing the decoder for the one codec that Firefox ships (by fixing the bugs fuzzers found in it, for example) took several man-months of work. This is work that has in fact not been done on most of the platform-default decoders, especially because new ones can be dropped in at any time. Firefox could whitelist codecs, but that's not what the proponents of using the system codec set are pushing for.
And since those system codecs would not be something Firefox can control the updating of, if there _is_ a security vulnerability in one... then what? Ship a Firefox update that disables that codec (blacklisting, effectively)? There don't seem to be any other options.
This isn't a theoretical issue, by the way; please count up the number of codec vulnerabilities patched in just Quicktime on Mac over the last year.
Slashdot Mirror
Sure. H.264 is something that's absolutely patentable in my book: it's novel, non-obvious, etc. It's just unfortunate, as you say, that the details of the licensing don't coexist well with open-source software (or anything else where the marginal cost of an extra decoder or encoder would otherwise be 0, in some ways).
> Removing Firefox as a viable option by implementing Theora only would do harm to the web
> and its users
You're assuming that this would remove Firefox as a viable option. In the short term, that's very unlikely (e.g. Youtube continues to work in Firefox). In the longer term, if nothing changes, maybe Mozilla would in fact end up feeling forced to implement H.264 support.
> all in the name of some "holy" crusade for FOSS principles
Did you read the article? The "holy principle" in question here is that anyone should be able to put up video on the web and anyone should be able to view it. That seems to be a pretty key part of how the web is supposed to work.
> Firefox is not developed by the community.
It's developed by whoever cares to develop it, actually. In the last three months, I've seen at least 4 different people show up, dive in, fix things that were bothering them.
In general, the direction of any large project is set by its core contributors. In the case of Mozilla, they happen to have been able to hire a large fraction of the core contributors, so they're actually paid for their contributions. The direction is still set by said individual contributors.
Yes, if by "bad situation" you mean "lack of a sane unencumbered format for web video". The question is whether having all browsers support an encumbered format Right Now is the best way to make the best of that bad situation.
> But how is that worse than the current situation where they have no support on any machine?
Because right now you don't have a situation where someone writes a web page, it works fine on their computers, and then breaks on 60% of computers out there. That's really not a good situation to be in.
> But they already load badly written code in several different ways, and that never was an
> argument against extensions or plugins
Oh, it's an argument against both. If they weren't quite as established as they are right now, in today's security climate they would be done _very_ differently.
Note that there's ongoing work to sandbox extensions to some extent and to move plugins to a diffferent, sandboxed if possible, process. Also note that there is code in place to blacklist extensions and plugins if they're being exploited and not being fixed. One could do the same for codecs, of course, but it's really just making the best of a bad situation.
Chrome supports Theora.
The only major players in the browser market who don't, and who have said they won't are Apple (which is shipping H.264 by default and can have quicktime plug-ins to support theora) and Microsoft (which isn't shipping anything in this space yet).
That said, Firefox isn't GPL. It's MPL/LGPL/GPL tri-licensed, so it may well be able to legally license H.264 if it really really wanted to. Whether that would be worse than having a very large percentage of the current core contributors unable to work on the browser is a tough call.
You apparently didn't read the article. The issue is not that Mozilla can't get a license; it can. The issue is that it sees doing so as actively harmful to the web and to users.
> H.264 is a free and open standard, just not in the US.
Or France or Germany, last I checked (as in, there are H.264 patents that have been granted by those countries; these are not _software_ patents but patents on the design of the codec). I haven't looked into detail for other countries, but I think you're making some unjustified assumptions here (like "h.264 patents are software patents").
> Or simply throw a decoder in, and block the Mozilla website to any IP originating from
> the US.
Given that Mozilla is headquartered in the US, this is not an option.
Or are you suggesting that they fire most of the employees and relocate elsewhere?
> the tax rates and benefits have not been adjusted, other than the max income subject to
> the tax to indexed inflation, since 1983.
I think you mistyped 1993. See http://www.socialsecurity.gov/history/pdf/t2a3.pdf
> The Social Security trust fund is *empty*
Citation please? Everything I can locate suggests otherwise. Now it happens that the trust fund holdings are US Treasury Bonds, but those are in fact assets.
Now it's true that redeeming these bonds will drain money from the general budget, but that's not exactly the fault of the SSA. What form did you expect the SSA to hold the funds in? Buckets of dollar bills? Gold bars? A NASDAQ index fund? They all have issues just as bad as Treasuries, if not worse.
> If social security were run by a private company instead of the government
Then you would still call holdings of treasury bonds "IOUs"? Seriously, the only one here applying a double standard is you.
I assume you did read the articles? They do discuss this, you know.
I don't think anyone's ignoring those facts. In particular, no one is under the illusion that ogg is a suitable replacement for h.264 in all cases. The hope is that a better codec than either will appear with more suitable licensing terms; in the meantime a premature standardization on h.264 would hurt the chances of that codec being adopted when it appears, no?
On the other hand, you seem to be ignoring the fact that Wikipedia, say, has no plans to put its video in H.264 (so Safari, say, can't very well view it).
> Time for Mozilla to face reality and pay up the license as Apple and Google have done.
As a side note, Apple and Google did not have to pay for a license separately here. They already had the licenses.
> Otherwise, watch Chrome really destroy Firefox
If that were to start happening (and it's nowhere close yet), the calculation might have to change, of course.
Google is not dumb. One major effect of a broadcast licensing fee for all web video is to make it harder to set up a Youtube competitor. Sure, Google has to pay the fee too. But it might well be worth it to them given the stifling of potential competition.
> I'm just wondering what makes the Firefox team certain they can write these codec
> implementations and players better than the teams who specialise in that field.
Nothing. That's why they're not writing the codec impl they're using; they're using an off-the-shelf theora decoder (though they've contributed a bunch back to it in the process of integrating it).
But the result is that the codec they're shipping they have the source for and have at least some people who can competently patch that source in the event of a security hole being discovered, while also sending the patch upstream.
As for the player... The player being used is pretty much off-the-shelf too, as above, but the method of feeding data into it had to be custom-written to deal sanely with HTTP, security restrictions in the browser, etc.
> no reason to believe that a volunteer for a browser project
I believe everyone working on the Theora support in Firefox was in fact a full-time employee whose job it was to make it work.
> I know Quicktime / ffmpeg / etc are all open to system flaws and attack, but what code
> isn't.
Sure. The question is what happens once such a flaw is discovered. If you're not Apple and you depend on Quicktime and a hole is discovered in Quicktime, what are your options? Have a security hole or stop playing videos until Apple patches it? The situation is, of course, better with ffmpeg.
For what it's worth, $54k does buy a 4-year education at most state schools (though not all). It buys about 1 year at most private schools nowadays....
Right. And more to the point, it's not realistic to have a browser support all codecs "supported" by the spec. Have to pick and choose somehow (if only by picking which system libraries one uses).
It's too bad the whole thing is such a mess.... :(
Right. So the key part is that at the moment all codecs are "supported" by html5...
> They are aware of the issue but they don't have a production ready solution.
"They" (we) are in fact aware of the issue, and feel that H.264 as the "standard" web video format is in fact detrimental to the long-term health of the web and to Mozilla's mission (which is not to make a web browser; the web browser is a means to an end).
> they will eventually have to support all of the codecs in the HTML5 standard
The standard doesn't specify any codecs.
> and make it "someone else's problem"
That can almost work ok until this someone else's code you have no control over ends up with a security hole that's being exploited. Then what courses of action do you have?
It would be legal for Mozilla to distribute Firefox if it did that. It would not be legal for anyone else to do so.
For example, if you put a copy of Firefox on your USB keychain and went over to your friend's house and installed it there (from that keychain) without paying the H.264 licensing fees required, you could be sued for damages. Not much in the way of damages, clearly, but you would in fact be liable for them.
Of course if you happened to be, say, Ubuntu, you would have to pay a pretty hefty fee (or be liable for significant damages) if you shipped Firefox as part of your distribution.
> I consider over a year of warning with no implementation in production 'unprepared'.
You're assuming that the goal was to support H.264. That's not in fact a goal at the moment, because it's seen as detrimental to the future of video of the web (though of course beneficial to several big companies today).
That's the subscription side of the licensing, you're correct. The big wildcard is the "broadcast" side, also known as "put that one video on my blog". It's free through the end of this year; after that we'll see what the licensing terms look like.
> I'm not sure if Google does (can't think which apps it would be)
The unit count is for decoders _or_ encoders. So Google is almost certainly already paying the licensing fees per unit for any machine involved in transcoding Youtube videos, say. They may well be hitting the cap with just that.
> where code that is written in any other codeshop is considered inferior
Not at all. I've written my share of code with security bugs in it and have no illusions about code I write.
But the key thing here is attack surface. Taking a shot at securing the decoder for the one codec that Firefox ships (by fixing the bugs fuzzers found in it, for example) took several man-months of work. This is work that has in fact not been done on most of the platform-default decoders, especially because new ones can be dropped in at any time. Firefox could whitelist codecs, but that's not what the proponents of using the system codec set are pushing for.
And since those system codecs would not be something Firefox can control the updating of, if there _is_ a security vulnerability in one... then what? Ship a Firefox update that disables that codec (blacklisting, effectively)? There don't seem to be any other options.
This isn't a theoretical issue, by the way; please count up the number of codec vulnerabilities patched in just Quicktime on Mac over the last year.
> Why should they license it when an embeddable player is available on every OS with
> noticeable marketshare?
Because those players tend to be security hellholes. Passing unsanitized data to them is a good way to get exploited...