
No double standards: supporting Google's push for WebM  - tjr
http://www.fsf.org/news/supporting-webm
======
commandar
I was discussing this with some people yesterday. I find it incredibly
frustrating that the Grubers of the world have spent months attacking Google
for supporting the evil, closed Flash, but then manage to spin Google dropping
a closed format in favor of an open one as evil and using it as a roundabout
way of continuing to hate on Flash.

The fact of the matter is that Flash is an entrenched, defacto standard and
isn't going away any time soon. HTML5 isn't anywhere close to completely
replacing Flash even if it were to disappear in a puff of logic right this
moment.

HTML5 <video> is in its infancy, and isn't being perpetuated by sheer momentum
like Flash. Further, H.264 was a complete non-starter for Mozilla, and Firefox
holds nearly 20% of the market. Using H.264 for HTML5 <video> would have
_guaranteed_ market segmentation and hurt the chances of a truly open future.

This argument about dropping H.264 propagating Flash in the short term is just
insanity to me. Flash is _already_ here for the short term. We need to focus
on our _long-term_ options for moving to something more open, and the whining
about this decision strikes me as totally myopic at best and blind fanboyism
at worst.

~~~
neild
_I was discussing this with some people yesterday. I find it incredibly
frustrating that the Grubers of the world have spent months attacking Google
for supporting the evil, closed Flash, but then manage to spin Google dropping
a closed format in favor of an open one as evil and using it as a roundabout
way of continuing to hate on Flash._

Your argument turns on Gruber hating Flash for being closed. He doesn't: He
hates Flash because he thinks it's crap. Gruber is not an open source
advocate. He has no objection to open standards, free software, or open source
software, but they aren't his passion.

You're right that Flash is an entrenched, defacto standard. It is, however,
_much_ less of one than it was three years ago, and that's pretty much
entirely due to one factor: iOS doesn't support it. The HTML <video> element
has traction entirely due to the fact that it's the only way to play video
from a web page on an iOS device. You don't have a choice between <video> or
Flash: It's <video> or nothing.

Chrome dropping H.264 support isn't going to push adoption of the <video>
element, because Flash continues to be a perfectly valid alternative method of
providing video to Chrome. If Chrome dropped H.264 _and_ Flash, that'd be a
different story.

Gruber's position is entirely consistent: He supports moves that reduce the
usage of Flash, and doesn't support ones that increase it. Google's choice to
drop H.264 in Chrome will, in the short term at least, result in the latter.
Acknowledging this fact is neither myopic nor fanboyism.

~~~
commandar
>You're right that Flash is an entrenched, defacto standard. It is, however,
much less of one than it was three years ago, and that's pretty much entirely
due to one factor: iOS doesn't support it. The HTML <video> element has
traction entirely due to the fact that it's the only way to play video from a
web page on an iOS device. You don't have a choice between <video> or Flash:
It's <video> or nothing.

So is this debate about what's best for the future of open standards on the
web, or is it about what's best for iOS?

>short term >myopic

S: (adj) short, shortsighted, unforesightful, myopic (lacking foresight or
scope) "a short view of the problem"; "shortsighted policies"; "shortsighted
critics derided the plan"; "myopic thinking"

<http://wordnetweb.princeton.edu/perl/webwn?s=myopic>

Sounds like exactly what I meant. It's focusing on short term consequences at
the expense of long-term benefit.

As I said, dropping H.264 may result in the already entrenched Flash being
used more in the near-term; in the long term it could help HTML5 <video> see
better overall adoption.

~~~
rimantas
> So is this debate about what's best for the future of open > standards on
> the web, or is it about what's best for iOS?

Dropping support for h.264 means slower adoption of <video> How's that better
for the open standards? The most infuriating part of this is, that FSF and
Google are so busy with their own agenda, that they forget users.

~~~
commandar
>Dropping support for h.264 means slower adoption of <video> How's that better
for the open standards?

20% of the browser market was _never_ going to adopt H.264. That's a fifth of
the market cut out from using <video> entirely.

How in the world is that possibly good for web standards?

>The most infuriating part of this is, that FSF and Google are so busy with
their own agenda, that they forget users.

That majority of the market has the entrenched Flash until HTML5 <video> gets
sorted out as a standard everyone can use.

~~~
evgen
_20% of the browser market was never going to adopt H.264. That's a fifth of
the market cut out from using <video> entirely._

20% and dropping... Should we also stop the <video> train in its tracks
because IE6 does not support it?

~~~
sid0
Dropping?

~~~
evgen
All lists for browser share that I have seen show FF as having either
plateaued or started to drop by small percentages. If you add mobile browsers
into the mix then even the plateau becomes a small drop.

~~~
sid0
And you really think that going to continue once Firefox 4 and Firefox for
Android are released? Firefox is going to be relevant for a long while, so
comparing it to IE6 is pretty disingenuous.

------
spiffworks
"free standards"

I'm glad somebody finally figured out how to accurately describe webm. All
this hand-waving talk of 'openness' and 'open standards' was debate poison.

~~~
9oliYQjP
Except it's not "free" in the Free software sense. Google specifically
addresses why they didn't use a GPL license but rather BSD. They want to
promote WebM in proprietary, closed, products.

<http://www.webmproject.org/about/faq/> "One of the goals of having this code
licensed as liberally as possible is to encourage adoption by as many users as
possible. This includes both proprietary and free software. Using the GPL
license would not be a good match for this goal."

The WebM issue is far from black and white. I still haven't figured out which
side I agree with more. What I do know is that a lot of people are arguing
tactics. This is a battle between corporations and everybody should be taking
100 steps back to try to figure out the strategies at work on both sides.

Edit: What I'm alluding to in my last point is a lot like Paul Graham's point
in this essay from a while back: <http://www.paulgraham.com/submarine.html>

~~~
spiffworks
No, clearly it's not Free as in FSF, but 'free as in beer' is the only thing
that separates it from H.264, it's definitely the most accurate description
I've seen yet.

~~~
hakl
It's compliant with FSF's definition of free software
(<http://www.gnu.org/philosophy/free-sw.html>) and Debian's guidelines
(<http://www.debian.org/social_contract>).

Stallman himself agreed that it was a good thing for Xiph to relicense their
libraries from the LGPL to a permissive free software license
([http://lists.xiph.org/pipermail/icecast-
dev/2001-February/00...](http://lists.xiph.org/pipermail/icecast-
dev/2001-February/000005.html)):

In response to the change of license, Richard Stallman of the Free Software
Foundation says, "I agree. It is wise to make some of the Ogg Vorbis code
available for use in proprietary software, so that commercial companies doing
proprietary software will use it, and help Vorbis succeed in competition with
other formats that would be restricted against our use."

~~~
spiffworks
Well, we're talking about two things, really- the webm reference
implementation and the license under which the patents covering the spec are
licensed. I guess the reference implementation is free as in freedom, and the
spec is free as in beer to re-implement. This is why 'free standard' is such a
pithy and accurate description.

------
cmister
Or in summary: if you support a free Web, you support WebM and FSF's call for
killing H.264. If you don't care, then H.264 seems just fine.

~~~
tzs
So, to watch a video using H.264, you use a patent encumbered codec, running
on a patent encumbered CPU, accelerated by a patent encumbered GPU. The video
came over patent encumbered network hardware, or from patent encumbered local
storage, over patent encumbered interfaces and patent encumbered connectors.

If we switch to WebM, we have one less "patent encumbered" in there (maybe).
I'm not impressed with the "free Web" argument.

------
bonaldi
The _content_ is all in h.264 because it works in 99.9999% of places. You can
make _every_ browser support webM tomorrow and that still wouldn't be a
compelling reason for publishers to add WebM in favour of the status quo.

The only thing that could achieve such a thing would be a device with iOS
levels of popularity that a) doesn't support h.264 b) doesn't support Flash.
Who is going to make such a device? A: Nobody, because it won't support any
web video at all apart from maybe YouTube.

You can grouse about open principles all you want, but the big video producers
don't care; they will not be a factor. Audience demand is the only thing that
matters, and they won't demand WebM when h.264 is already working "fine".

~~~
Teef
Android if not today will be more popular device than iOS soon. I was thinking
the combination of Android + Chrome would be enough to motivate publishers to
encode using Webm?

~~~
mikeryan
I'm not yet aware of an Android device which supports WebM hardware decoding.
Virtually all of them support H.264 hardware decoding.

This is not an iOS vs Android argument (though many have tried to make it so),
all of the current devices chose H.264 as their primary codec because when
they were being designed and developed that was the only logical choice.

------
weixiyen
If Firefox wasn't supporting h.264, it was kind of pointless for Chrome to
support it as well. As a developer, I have to have to resort to flash for
h.264 anyways as Firefox has a much bigger market share than Chrome.

------
tzs
H.264 is the standard for video compression. Period. It is what almost all
professional hardware and software supports. It's how video is distributed on
disc, via cable, via satellite, and via digital broadcast. It's what consumer
hardware supports.

Someday it will be replaced, but it will take a technically better standard.
WebM is not technically better. Take a time machine and send WebM back about
10 years, and it has a shot. Without a time machine, it is too late.

The problem Google and the FSF face is that very few _really_ care about
having everything be free in the FSF's sense of free. Heck, even among Linux
users, who you'd expect would be the most receptive of wanting everything to
be free, very few run the truly free distributions, with no non-free modules
or drivers. The vast majority are not even on Linux. They are on Windows and
Mac, and so have no qualms about using non-free stuff.

To convince people they need to switch to something that is technically
inferior, they need to be shown a problem that actually affects them. H.264
being subject to patent licensing in those countries that recognize software
or codec patents is not a problem that can be shown to affect most web users
or most web video producers, at least in a way they care about. The royalty
free license for distributing free video on the web, and the high thresholds
before license fees kick in for video producers, ensure that the vast majority
of us never do anything that requires coughing up any money, and that takes
the problem off most people's radar.

~~~
varjag
A huge part of the business and consumer world now takes benefit from fruits
of free software movement. Your Android smartphone, your $49 Taiwanese wifi
router, that Heroku service in the cloud you use - all of them would not exist
as they are otherwise.

So like it or not, those freedom freaks are entitled to have a say to how
things should work. They are too big part of an ecosystem to be ignored.

------
pacifika
This article would be correct if Google dropped flash together with H.264. The
practical result of playing H.264 to Chrome users via Flash instead of through
a native open source implementation (Chromium) is surely a net negative for
free standards supporters? After all it's "proprietary, nonstandard software."

~~~
bryanlarsen
I don't understand this position. Dropping H.264 is aligned with the FSF's
goals, so of course they should support it.

To me, Google's move is an indication that Google will eventually drop and/or
downgrade Flash support.

You encourage institutions to do the right thing by applauding when they do
the right thing. Not by saying "you suck because you didn't take it far
enough". You say "Good move doing X. And when you do Y you'll be doubly
awesome."

~~~
rimantas
I fail to see how this move is good for end users.

~~~
bryanlarsen
The FSF has always been about the long term. This move is actually much less
short-term user-hostile than many of their other moves.

~~~
joesb
In long term, H.264 patent will expire.

------
cletus
A few points:

> We applaud Google for this change; it's a positive step for free software

Except that it further entrenches Flash in the short to medium term, possibly
longer.

> Most of it is delivered with Flash, which is proprietary, nonstandard
> software.

Exactly. H.264 isn't going away anytime soon so having a Web browser without
Flash gets that much harder. With no native support for H.264 in Firefox or
(soon) Chrome, bizarrely the most Flash-unencumbered browsers are Safari and
_Internet Explorer_.

Consider that for a moment: _Internet Explorer_.

> Free software alternatives like GNU Gnash are available, but the user
> experience isn't always as seamless as it ought to be.

This is a key point but not in the way the author intended and it's worth
parsing this statement. The FSF is driven by philosophy here but most users
aren't. If you want to attract a plurality of users a necessary precondition
is to have the experience be as good _if not better_ than what you're
contesting.

There is a cost to switching: finding new tools, learning a new process and so
on. Users need a reason to switch and ephemeral arguments about "openness" of
video on the Web just don't cut it for the majority, at least not while such a
choice comes with a subpar experience.

> In order to make sure the Web stays free for everyone, we need a free codec
> to prevail as the de facto standard with HTML5.

Like most future specters I believe this one is overblown too. Everyone points
to the GIF fiasco. The net result? PNG was born. If the screws are ever put to
us on H.264, you'll see exactly the same thing, only quicker. Computing power
being what it is today, the effort of re-encoding every video that exists on
the Web is actually not that hard of a problem, and is certainly in the realm
of what Google can do today, let alone 5-10 years from now.

> WebM can be that codec: Google provides a patent license with the standard
> that is compatible with free software licenses

But it should be noted, there is no indemnity against H.264 patent
infringement. I'm not saying WebM violates H.264 patents. The reverse may even
be true (or both). But the point is that it is a risk.

> We can only be free if we reject data formats that are restricted by
> patents.

The elephant in the room here is that the fundamental problem is _software
patents_. They need to be completely abolished.

> But the issue's not settled yet.

No but it's a bit like iPad vs the rest of the tablets. The issue isn't
settled yet, but the iPad has a whopping lead and the smart money is on it for
some time to come. H.264, like it or not, is more mature and has more hardware
and software support than WebM, which is far less mature.

~~~
spiffworks
You missed the most critical point, which is

"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."

And that is what it is all about. H.264 imposes end-user licenses and if it
gets entrenched, freely redistributable browsers would lose. The argument
against dropping H.264 is basically "why switch formats when what we have
works?". H.264 does not work for free software. It's as simple as that. If
HTML5 video suffers in the short term, that's the price we'll pay - at least
that's the FSF's position.

>Everyone points to the GIF fiasco. The net result? PNG was born. If the
screws are ever put to us on H.264, you'll see exactly the same thing, only
quicker.

Why wait until a fiasco?

> Computing power being what it is today, the effort of re-encoding every
> video that exists on the Web is actually not that hard of a problem, and is
> certainly in the realm of what Google can do today, let alone 5-10 years
> from now.

Seriously, you're arguing against yourself here. Besides, what of the
omnipresent 'hardware decoders' we keep hearing about?

~~~
cletus
> "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.

[1]:
[http://en.wikipedia.org/wiki/GNU_General_Public_License#Vira...](http://en.wikipedia.org/wiki/GNU_General_Public_License#Viral_Nature)

~~~
spiffworks
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.

~~~
GHFigs
_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.

~~~
vetinari
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!").

~~~
GHFigs
_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.

~~~
vetinari
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?

~~~
ezalor
The handling of a <video> _is_ outsourced to the OS.

~~~
vetinari
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.

------
marckremers
But isn't it too late? <http://techcrunch.com/2010/05/01/h-264-66-percent-web-
video/> This is from May last year, I bet it's even higher now. Say by some
miracle that webm takes over, even though it's free, it's a Google run
project, and we now that Apple chooses stability over availability (i.e. their
rejection of Flash)

From my experience building a HTML5 video playback portfolio for a client,
playing high quality webm/ogg is just not doable yet, even via Amazons CDN.

And what i don't get, on a very basic level, are these companies that own
these file formats really ever going to cash in on all those files out there?
I mean GIF, JPG, PNG are all patented formats, and they are everywhere.

Why doesn't Google announce for example that they will also stop supporting
JPG/PNG/GI in favor of their open source WebP format? If they were really
drawing bold lines they should be honest about it.

~~~
jarek
PNG is not a patented format. In fact, the patent wars surrounding GIF were a
major, perhaps the overriding motivation for development of PNG.

------
luigi
Ehh, all of a sudden the pro-WebM side got really lame now that the FSF joined
the party.

------
xutopia
I always saw this as a problem with the FSF. They are urging web site
operators to use WebM right away when there isn't even support for them.

They simply sound so naive when they say "Today, we're also urging Web site
operators to distribute videos in the WebM format, and abandon H.264". What
they should be saying is "Prepare your web sites to transition to WebM".

~~~
drdaeman
"Prepare" is way too lax. Many will treat it like stick-it note "oh, I have to
make sure someday, shall the transition come, my code won't require major
rewrites". Like "preparation" for IPv6 support frequently ends with adding
more bits to DB fields and adding several stub functions.

Unless you actually get your hands dirty and start _doing_ something, not just
preparing, there won't be any _significant_ results.

Sure, FSF is quite radical with "and abandon H.264" part, but "distribute
videos in the WebM format" part is perfectly fine.

