[whatwg] several messages regarding Ogg in HTML5

Ian Hickson wrote:
>> At least with Theora we can avoid any known ones.  All codecs have a 
>> risk of submarine patents (though with extensive having been done for 
>> Theora, at least that risk is lowered, if not eliminated completely), so 
>> that argument is a wash, its on both sides of the equation, so it 
>> cancels out.

> Not for companies that have already taken the risk of one of the codecs 
> already. 

And this is exactly the way that Apple, Nokia, et al are hijacking this
process.  They throw out some nebulous business reason for why they
don't want to use Ogg et al, and it gets bought, hook line and sinker.

Maybe there is some legitimacy to that argument, even, but, I really
don't care.

The w3c should be about making the best free and open standard they can,
and right now that means Ogg...if Apple and Nokia don't want to
implement that, then that's their problem.

If HTML5 doesn't get traction as a result, then you point at Apple and
friends and point out that they refuse to implement a perfectly good and
easily implementable spec and let the marketplace figure it out.

> There's no point putting a MUST in the spec if we _know_ that it won't be 
> followed. We're not writing specs to satisfy a theoretical need, we're 
> trying to get actual interoperability across all browsers.

Then you've decided to allow any big company to torpedo this process
based on some nebulous claims of "business risk".

So much for the w3c being relevant.  I thought the w3c stood for more
than this.

>> If you want a baseline that everyone can implement without being 
>> encumbered, then the answer is Theora.

> We have been told that Theora is not something everyone can implement. 

And that's a bald faced lie.  Everyone *can* implement it, though they
may choose not to.  No way should the w3c be held hostage to that.

>>> Small companies aren't targetted by patent trolls. Only big (really 
>>> big) companies are. It's a big-company concern, just like "no per-user 
>>> licensing" is a small-company concern. That's just the reality of the 
>>> situation, it's not intended to be a bias.
>> Except that it very clearly is biasing the decision making process so 
>> far.  The language was changed because the big companies weren't 
>> comfortable with it, moving in the direction of screwing the little guy. 
>> That is bias.

> I'm sorry you believe that. It really isn't supposed to be. We're trying 
> to find a solution that works for everyone.

Then revert the text, even if only as a show of good faith.

>> If you really want this to be a baseline codec that everyone can 
>> implement, revert the text and then change it to MUST.

> Making it a MUST doesn't make it possible for everyone to implement. If 
> only standards development worked that way! It would be far easier.

No, what makes it possible for everyone to implement is that its a free
and open codec without encumbrances.  Making it a MUST in the spec
encourages people to implement and allows the market to bring more
pressure to bear on it.  This is a "Good Thing(tm)".

>>> and that is not an additional submarine patent risk for large 
>>> companies.
>> You've created the bias in the premise.  By including the word 
>> "additional", there, you have artificially limited the field to codecs 
>> which are already implemented by the large companies.  That is not 
>> progress, that is one great big, huge, gigantic step backward.

> We have to take into accounts the needs of everyone. This includes large 
> companies. If large companies will only accept codecs that they've already 
> implemented, then that may have to be one of the criteria.

That is absurd in the extreme.  Its a new spec, any new spec involves
new risk.  If you aren't willing to take on new risk then HTML5 becomes
nothing more than an XSLT transform away from HTML4.

>> But since we're in a standards setting venue, non-standards-compliant 
>> browsers (now or future) and, by definition out of scope.

> Actually, all browsers are in scope to the WHATWG work. It would be short 
> sighted in the extreme, for instance, to ignore IE, since they have a 
> controlling position in the market.

That just doesn't make any sense.  If a browser decides that its not
going to be standards compliant, then there's nothing that the standards
body can do to affect what that browser does.

The hope with IE is that MS at least makes noises about making IE
standards compliant, and with IE7 at least made it less badly broken
with respect to standards.  I'll give them the benefit of the doubt and
say that they're at lesat trying.  If a browser maker isn't even going
to try, then we can't worry about them.

>>> Ogg is _a_ choice, which provides freedom for some but not everyone. 
>>> We need a codec that works for everyone.
>> Then you might as well give up on HTML5 right now.

> I hope we can find a solution that doesn't involve giving up. :-)

If you continue to let the big companies hijack the process like you
have on this issue, then there's no hope.

> On Tue, 11 Dec 2007, Jeff McAdams wrote:
>> A decision was made to move away from using the ogg family of 
>> technologies.  While not a final decision, it is a threatening decision 
>> to those of us that value freedom and openness and don't appreciate 
>> being screwed by big companies.

> Whatever solution we find will be one that is royalty free and open. That 
> is not in any doubt.

Then as a show of good faith, revert the text until the discussion happens.

To be blunt, I've seen far too many instances where big companies have
gamed the standards making process by getting little changes made here
and there until the standard ends up screwing the end-user.

I'm sure you mean well, Ian, but this change was a *HUGE* step away from
protecting the end-user.

> On Tue, 11 Dec 2007, Jeff McAdams wrote:
>>>> A decision was made to move away from using the ogg family of 
>>>> technologies.
>>> No.
>> Yes.

> As the person who would make that decision, I assure you that no decision 
> has in fact been made. That is, in fact, the entire crux of the issue.

But the fact is that the text was changed away from specifying free and
open codecs, even if as a default position.  And that's offensive.

>> If things are up in the air, then why change it?

> Because the SHOULD-level requirement on Ogg did not represent the actual 
> status of the spec and of the current consensus. The spec should reflect 
> reality -- that, if anything, is an underpinning principle of the WHATWG.

But the spec, as it currently exists, is a working document, why change
the text to something that you know will have to be changed again.  If
that's an underpinning principle of the WHATWG, then that's just nuts.

>> If the text is changed to move away from a free and open solution to 
>> something that is going to be encumbered, you better believe I'm going 
>> to be up in arms about it, and I will not apologize for it.  This change 
>> is exactly that sort of change.

> No, the change here is from a free codec that not everyone will implement 
> to an open issue that describes what we need, which is, amongst other 
> things, a free codec.

Then, again, revert the text as a show of good faith.

If you want to stop this firestorm, do that as a show of good faith.
-- 
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
                                       -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20071212/22efc792/attachment.pgp>

Received on Wednesday, 12 December 2007 01:57:37 UTC