> "This license is fundamentally incompatible with software freedom. It requires developers to restrict how their software can be used, and to collect royalties in many situations."
According to the FSF's definition of software freedom. The FSF has quite a radical view in this regard. A Microsoft exec once described the GPL as "viral' [1] and it's a fair point. Many view licenses like MIT and Apache as being more free simply because they're not as restrictive.
This ambiguity is more pronounced when you use words like "open" because it means different things to different people.
So it would be more accurate to say that H.264 is incompatible with the FSF's idea of software freedom.
> if it gets entrenched
What do you mean "if"? It already has.
> Why wait until a fiasco?
Because anyone who writes software knows that writing code to solve problems you may never have is a recipe for wasted effort if not outright disaster.
It's a bit like the standoff between the (former) Soviet Union and the USA: not a single shot was ever (directly) fired between the two but the threat of escalating conflict kept them in check (resulting in proxy conflicts in Korea, Vietnam, Afghanistan, etc but I digress).
Think about it this way: MPEG-LA could announce tomorrow that licenses now cost $1 trillion. The result? Obviously no one would pay and a new standard would arise pretty quickly. What if it was $1 billion? $100 million? The point here it is simply a question of degree.
So what keeps (and will keep) MPEG-LA in check is market forces, the limits of what people can and will pay and the threat of a free or cheaper alternative... much like any market. Switching formats is a process that can be automated so the transition cost isn't really that high.
> So it would be more accurate to say that H.264 is incompatible with the FSF's idea of software freedom.
It depends on how you define "compatible", but H.264 is only sort of compatible with MIT-style licensing as well. It's compatible in the sense that, if you start with MIT-licensed software, you can slap on the required H.264 license and not violate any laws (MIT-licensed software can be relicensed under more restrictive terms). But it's incompatible in the sense that you can't actually choose to ship your software under the MIT license and the MIT license alone. In that sense, H.264's license is viral: any software that supports H.264 in any form must incorporate the the H.264 license.
Ok, here is how I define minimal software freedom - I give you a piece of software, along with source code, you are free to use it in anyway you please, or make your modifications and distribute it to as many people as you like. With H.264 bundled with a piece of software, that is not possible.
> This ambiguity is more pronounced when you use words like "open" because it means different things to different people.
I never once used the word in my post.
>What do you mean "if"? It already has.
You're arguing for the status quo. Everything seems entrenched until an alternative comes along.
You seem to completely ignore that the H.264 license is directly opposed to free software. There's a reason Chromium never supported H.264, while only Chrome did. Nobody except the patent holders benefits from a de facto patent-encumbered codec.
With H.264 bundled with a piece of software, that is not possible.
The decision to only support bundled codecs and refuse to let the user use anything else was made by Mozilla, Google, and Opera. It is not a spec requirement or technical necessity. The idea that a browser would be forced to bundle h.264 is quite evidently mistaken, as the browsers that do support it don't bundle it.
The browsers that do support it run on the platform by the same vendor. IE9 runs only on Vista/7, where MS provides H.264 decoder. Safari runs only with Quicktime, where Apple provides H.264 decoder. So although the browsers do not come with decoders, they use their vendor's decoder and nothing else.
On the other hand, if Mozilla/Opera/Chrome used third party decoder, that would be support nightmare ("It works on my computer, but not on friend's! Please fix it!").
The browsers that do support it run on the platform by the same vendor.
I don't understand the significance. The same APIs are accessible to any other browser. If someone has evidence that Mozilla, et al. have been technically locked out of using the media APIs on Windows or Mac OS X, I'd be interested in the details, and if someone has evidence that they've been locked out of using the media APIs on Linux, I'll eat my hat.
they use their vendor's decoder and nothing else
I'm not sure what you mean. If you mean something like "Windows will only support h.264 and you can't use anything else", then that is exactly wrong.
It is not only about APIs, but also about control.
Microsoft can always rely, that IE9 will supports whatever formats they want it to support. They know, that it will play H.264, because they ship H.264 with Vista and 7 and IE9 supports only Vista and 7.
Apple can also always rely, that Safari will display formats they want it to display. They know, that Safari will play H.264, because Quicktime ships with H.264 and Quicktime is bundled with OSX, or with Safari for Windows.
If Mozilla/Google/Opera outsource this to OS, they lose control. They will not know, what the browser will display (imagine handing off control about HTML/CSS/JS to Microsoft, when IE6 was going down and Firefox up. It would be like Firefox using IE HTML control to display HTML).
Another problem from the control perspective is inconsistent support among platforms. Platform A, it will play formats X and Y. On platform B, formats Y and Z. On C, X a Z. Do you see problem here?
For IE9 and Safari (except Safari for Windows) is is exactly the case. And because the OS vendor is the same as browser vendor, the effect is the same as bundling with the browser.
That is not the case for browser vendor without their OS. They cannot achieve the same effect.
If all browsers did that, web codec development would move at the same glacial pace as Windows version updates, not to mention losing any semblance of uniformity and all possible hope of changing the status quo in any meaningful way away from patent-encumbered codecs.
web codec development would move at the same glacial pace as Windows version updates
I'm not convinced that that is the case, but even if it were, the state of things with bundling codecs is being limited to what Google and Mozilla say is ok for them. You, the user, have no say in what you can view. This might be acceptable if you have supreme confidence in them (where is the next free codec going to come from, anyway?) but frankly I don't think they've earned it.
not to mention losing any semblance of uniformity
I find this extremely dubious. The incentive to publish in a format viewable by the widest audience applies regardless of what format that happens to be. Flash became ubiquitous for web video precisely because it was the most useful at achieving this aim, not because any browser decided to forbid other plug-ins. I see no reason to think that this incentive would dissolve if codec support was left open-ended.
changing the status quo in any meaningful way away from patent-encumbered codecs
This is is an ideological demand, not a spec requirement or a technical necessity. Which is my point: that is why these browser vendors are doing this. Not because they are forbidden from supporting h.264 (compare Epiphany) but because they're trying to push an ideology under which h.264 is heathen.
The whole point of moving things to the browser was to remove any lockin advantages a specific platform might have. That is the reason Flash gets so much hate from anybody who doesn't use Windows. Going back to OS-specific codecs would limit codec choice to what the OS vendor considers kosher. And lest we forget, its far harder to switch operating systems than it is to switch browsers. If you don't like Chrome, Firefox or Opera, nobody's stopping you from using IE or Safari.
> bundling codecs is being limited to what Google and Mozilla say is ok for them
What you are suggesting merely takes the power out of the hands of browser vendors and puts it in the hands of the os vendors. I trust Mozilla, and to a far lesser extent Google, more than I ever will trust Microsoft.
Using operating system facilities to support video codecs, font rendering, image decoding, etc. is an unnecessary security risk. Independent browser vendors don't want to be blamed for someone else's bad code.
> A Microsoft exec once described the GPL as "viral' [1] and it's a fair point.
It's not. Plain old copyright is viral. A derived work's copying can only be done with permission of original and deriving author. If you use a commercial library, the license you paid for is that permission. If someone then creates a new work from yours, permission is needed from all three authors unless the original library came with those particular redistribution rights.
According to the FSF's definition of software freedom. The FSF has quite a radical view in this regard. A Microsoft exec once described the GPL as "viral' [1] and it's a fair point. Many view licenses like MIT and Apache as being more free simply because they're not as restrictive.
This ambiguity is more pronounced when you use words like "open" because it means different things to different people.
So it would be more accurate to say that H.264 is incompatible with the FSF's idea of software freedom.
> if it gets entrenched
What do you mean "if"? It already has.
> Why wait until a fiasco?
Because anyone who writes software knows that writing code to solve problems you may never have is a recipe for wasted effort if not outright disaster.
It's a bit like the standoff between the (former) Soviet Union and the USA: not a single shot was ever (directly) fired between the two but the threat of escalating conflict kept them in check (resulting in proxy conflicts in Korea, Vietnam, Afghanistan, etc but I digress).
Think about it this way: MPEG-LA could announce tomorrow that licenses now cost $1 trillion. The result? Obviously no one would pay and a new standard would arise pretty quickly. What if it was $1 billion? $100 million? The point here it is simply a question of degree.
So what keeps (and will keep) MPEG-LA in check is market forces, the limits of what people can and will pay and the threat of a free or cheaper alternative... much like any market. Switching formats is a process that can be automated so the transition cost isn't really that high.
[1]: http://en.wikipedia.org/wiki/GNU_General_Public_License#Vira...