Is Apple’s WebKit a patent minefield?

The news that the HTML5 specification will not specify a video codec is bad news for the open Web. What makes things worse is that a common, royalty-free codec was actually agreed on by all involved browser vendors, except one.

Apple. …

The company is concerned about possible patents and lack of hardware acceleration for Theora, it says. And surely not its QuickTime product line?

Apple's recent blocking of the new widgets specification through the use of patents shows that the company's commercial interests seem to be increasingly at odds with the open Web. And their response to Palm Pre sent a strong signal to the market. Apple is ready to "go after anyone who infringes on their patents". It can't be put any clearer than this:

We are ready to suit up and go against anyone. However, we will not stand for having our IP ripped off and will use whatever weapons we have at our disposal.

This is not particularly good news to those of Apple's competitors who have chosen to use WebKit as a browser engine.

While WebKit is open-source, that does not mean that Apple does not hold any patents related to their browser engine. With the strong signals from Apple regarding patents lately, competitors making use of Apple's engine could quickly find themselves in trouble if Apple decides to enforce browser related patents.

Yes, Apple certainly has the right to enforce its so-called "intellectual property". But what happens if the company gets in trouble and needs to raise money in order to survive?

Both current and future competitors of Apple (the company is entering new markets all the time) have decided to try out WebKit. But Apple continues down the path it has indicated that it is heading, those competitors could quickly find themselves in a patent minefield.

Companies that absolutely want to build their own browser may be better off using Mozilla's Gecko engine instead of WebKit. Yes, Gecko might be bulkier, more memory hungry, not as fast, and a bit more tricky to use than other engines, but at least Mozilla hasn't shown many signs of wanting to go on the offense with patents.

It basically seems to be less of an obstacle to the open Web and patent-free browsing.

Advertisements

24 thoughts on “Is Apple’s WebKit a patent minefield?

  1. Microsoft has not commented on their intent to support at all./

    lol. Typical Microsoft.It is sad. Opera will still go ahead and include support for video tag in it's mainstream build in the future right?Ogg Theora does need to improve as a codec though.Btw, why did everyone select Ogg Theora and not something like VP6? VP6 is also open source, isnt it? I think its included in libavcodec.

  2. I think Microsoft did not comment the video tag issue because it would lead to unexpected results. Just remember what happened to VML when it was proposed by Microsoft as open standard. No SVG at the time! Cool technology, tools were made for support, draft sent to W3C. And W3C did a very strange move, they rejected VML and after few years released SVG, which is almost the same VML (quite simple XSTL filter can convert between them).Actually, sometimes I think there are too many jerks at W3C. Imagine that they reject OGG if Microsoft tries to support it? And it MAY happen if we digg into W3C history.

  3. I hope all browers will support only at least 1 same codec in the end. I would hate it, if we had:- microsoft only supporting wmv and wma- apple supporting some quicktime format- opera/firefox supporting Theora- chrome pushing h.264(to be clear, the above is just an example)That would take a lot of time encoding a movie (once for each browser) and need lots of space on the hard-disk of the server when you have a lot of video's (certainly with all the HD stuff going on :eyes:). (And with lots of codecs for each browser to support, would end up with very big browsers downloads and installations)

  4. I never agreed with the creation and implementation of a < video > element. We already have a perfectly good means of embedding video into a page with < object >, and if browser vendors wanted to include the Theora codec by default, it would be as simple to use as < object type="video/theora" >.So while I'm disappointed with Apple for thumping about patents, I can't say I'm disappointed with the end result of the decision. I particularily agree with Ian's sentiments here:Originally posted by Ian Hickson:

    Originally posted by Robert J Crisler:

    The W3C is not only about web standards. It's also the road map. Right now, that road map, where video is concerned, says the following: "User agents may support any video and audio codecs and container formats." It might as well say "Here be dragons." …

    Why is this the case for video but not images? We don't require a particular image format for < img > either, but people know you can just PNG and JPEG.

    You can extend this argument to: Why is it even the case for images? IMHO, < img > is a grandfathered element that even I don't see us getting rid of, but it too could be replaced by the < object > element which already provides a excellent fallback mechanism. And with better content type auto-detection, even the "type" attribute of < object > could be made optional, and we have a totally generic means for including replaced content in webpages. < object > would also replace < iframe >, and has already deprecated < embed > and < applet >.As I see it, the whole HTML5 < video > argument boils down to whether or not a royalty and patent free video codec should be included with the browser download (just as JPEG, GIF and PNG decoders are now). Why this also requires the addition of a new and superfluous HTML element is beyond me.Edited because < object > without spaces causes message truncation ๐Ÿ˜ฆ

  5. freeek writes:Nokia is using Webkit and whatever Webkit supports, and is therefore in danger of being sued for patent infringement by Apple for using Webkit ๐Ÿ˜€

  6. I think you are not fair towards Apple right now. I mean lack of HW acceleration for Theora is a serious issue given the number of iphones and ipods out there.And as for your claims about Webkit being a patents-minefield: sorry, they look like a FUD to me. I love reading your blog but you shouldn't abase yourself to use this method like certain people from Mozilla do.

  7. Anonymous writes:Nokia uses lots of things. Nokia once had its own browser [1][2]. Nokia once licensed Opera [3] for various platforms. Today Nokia ships browsers based on both Gecko [4][5] and WebKit [6]. To claim that Nokia just uses WebKit is to be ignorant of the size and scope of Nokia. As for formats [7].As people aren't able to use google, I've provided a number of helpful links below.[1] http://www.forum.nokia.com/info/sw.nokia.com/id/d57da811-c7cf-48c8-995f-feb3bea36d11/Nokia_Mobile_Internet_Toolkit_4.1.html[2] http://en.wikipedia.org/wiki/Mobile_browser#Default_browsers_used_by_major_mobile_phone_and_PDA_vendors[3] http://lmgtfy.com/?q=nokia+opera+770[4] http://lmgtfy.com/?q=nokia+gecko[5] http://lmgtfy.com/?q=nokia+microb[6] http://lmgtfy.com/?q=nokia+webkit[7] http://lmgtfy.com/?q=nokia+ ogg

  8. lulz writes:Actually, Nokia is getting rid of Gecko.Also, how is it "FUD" to point out the fact that Apple is litigation-crazy. It's a huge risk to use webkit.

  9. WayOfTheBastard, what are differences between VML and SVG? In their draft version. Simply none.And no, I'm not working for Microsoft.

  10. Originally posted by GreyWyvern:

    Why this also requires the addition of a new and superfluous HTML element is beyond me.

    Orca, there are tangible benefits both for users and for implementers to have a dedicated video element. First, you can find video files with the very simple XPath expression '//video' or even via getElementsByTagName('video'). This has applications in server-side processing, user scripts and so on.Second, you can style video more easily. How do I easily style an image-object differently from a video-object or from an iframe-object, if we don't have separate elements?For implementors it's easier to have a separate element because you don't need to change the nature of elements dynamically based on what a URI referemce resolves to (assuming it resolves at all), and authors need not provide verbose MIME content-type hints to make the process smoother.Also, keep in mind that the video element has a considerable JavaScript API attached to it: it would make scripting more difficult than it has to be both for implementors and for script authors if the API of an element were to change unpredictably.If you ask me that's a lot of good reasons to have a video element.

  11. Justcu10us writes:Recently I have begun using Amazon Video On Demand and after signing up for NetFlix, their watch instantly feature.How do all these different codecs play into (or are affected by) the VOD features of these prominent websites?

  12. Originally posted by GreyWyvern:

    Why this also requires the addition of a new and superfluous HTML element is beyond me.

    Why do we need < P > when here is < DIV >?Generic not always good. HTML should be kept simple enough.

  13. Originally posted by MTKnight:

    Orca, there are tangible benefits both for users and for implementers to have a dedicated video element. First, you can find video files with the very simple XPath expression '//video' or even via getElementsByTagName('video'). This has applications in server-side processing, user scripts and so on.Second, you can style video more easily. How do I easily style an image-object differently from a video-object or from an iframe-object, if we don't have separate elements?

    Both of which are solved by hinging on the type attribute.body > object[type^="video"] { … styles … }XPath can search based on attribute names too. You might ask "how does this work for dynamically filled < object > elements, where the author does not know the type?" and that's simple too. Depending on the type of resource which ultimately get's loaded, the type attribute will be filled by the client automatically, allowing the appropriate CSS rules to act upon it. So, for example, if you have a single < object > tag which may randomly point to either a video, or an image, you can include CSS that handles both cases:body > object#random[type^="image"] { border:2px solid green;}body > object#random[type^="video"] { border:2px solid blue;}Originally posted by MTKnight:

    For implementors it's easier to have a separate element because you don't need to change the nature of elements dynamically based on what a URI referemce resolves to (assuming it resolves at all), and authors need not provide verbose MIME content-type hints to make the process smoother.

    Authors will have the same sorts of typing issues with < video >. Do you think that everyone who uses the element will want to use Theora? Of course not. The video element is going to have to jump through the same type-detection hoops as the < object > element.Originally posted by MTKnight:

    Also, keep in mind that the video element has a considerable JavaScript API attached to it: it would make scripting more difficult than it has to be both for implementors and for script authors if the API of an element were to change unpredictably.

    And what of the < input > element? Depending on the type attribute, its JS API changes, perhaps not as considerably, but still significantly. Why should it be any more difficult for users to understand when a similar system is employed for different types of < object >? Just check the type of the resource referred to by the element, and you know which API properties and methods are available. Alternatively, you can just test for the existence of the API methods and properties themselves before using them.Originally posted by FataL:

    Why do we need < P > when here is < DIV >?Generic not always good. HTML should be kept simple enough.

    Because < P > has semantic meaning in a document context: it denotes a paragraph. Replaced elements such as < object >, < img > etc. do not impart any semantic meaning to a document except through their "alternate" content. Which is why it also makes logical (but not practical) sense to deprecate < img > in favour of a single < object > element for all replaced content.

  14. Originally posted by FataL:

    I would say that < UL > and < OL > has very similar semantic, and can be styled via CSS in a way that OL will look the same as UL. But they still kept in HTML as separate elements.

    ๐Ÿ™‚ What they keep or remove from the HTML specification does not always have any bearing on whether it is "good" or logical. They deprecated a lot of font/text styling elements such as < u >, < center > and < font >, but they did not deprecate < b > or < i >. Why? These elements are replaced by CSS the same as the others. It is because they were too widely used at the time to make developers switch to using stylesheets instead. Effectively they are "grandfathered" into the specification.That being said, just because something was kept in the specification because of this "grandfathering" does not mean it is good, and that we should make more of these types of elements!Originally posted by FataL:

    IMG, VIDEO and AUDIO have much more different semantic meaning for end users than OL and UL.

    You are correct, IMG, VIDEO and AUDIO have much more different semantic meaning. In fact, in a document context, they have none. They are all "replaced elements" which means they have the same amount of meaning to the document as would an < iframe >. The current document doesn't know what information is imparted to the user via content loaded in an < iframe > therefore it is semantically empty.Originally posted by FataL:

    Also, as you say deprecating IMG is not practical, to keep things consistent there VIDEO and AUDIO have added to HTML5.

    That kind of consistency should not be the aim of HTML. Making it consistently generic so it applies in more situations, and is easier for different computer programs to generate the same byte-for-byte output is. But don't take my word for it; this was the original aim of Tim Berners-Lee when he came up with HTML and the world-wide-web. It was always meant to be a markup language which would be generated automatically by programs, never built by hand. Syntactic sugar like < video > in place of < object type="video" > is solely designed to be of benefit to hand coders and other developers who muck around with the source code of documents directly.HTML needs a more concise vocabulary, not a more verbose one.

  15. Originally posted by GreyWyvern:

    Because < P > has semantic meaning in a document context: it denotes a paragraph. Replaced elements such as < object >, < img > etc. do not impart any semantic meaning to a document except through their "alternate" content. Which is why it also makes logical (but not practical) sense to deprecate < img > in favour of a single < object > element for all replaced content.

    I would say that < UL > and < OL > has very similar semantic, and can be styled via CSS in a way that OL will look the same as UL. But they still kept in HTML as separate elements.IMG, VIDEO and AUDIO have much more different semantic meaning for end users than OL and UL.Also, as you say deprecating IMG is not practical, to keep things consistent there VIDEO and AUDIO have added to HTML5.

  16. Hey! :irked:. I'm a 'hand coder' :awww:.But I still find that the object tag is more sensible. It's certainly more versatile.

  17. Originally posted by GreyWyvern:

    Syntactic sugar like < video > in place of < object type="video" > is solely designed to be of benefit to hand coders and other developers who muck around with the source code of documents directly.

    Funny but HTML quickly become very popular owing to people that was mostly hand-coding.Nowadays people mostly hand-coding too, but instead writing static HTMLs they do templates.Added later:Just want to clarify that I fully understand your position. Your position just more pro XHTML 2 than HTML 5. ๐Ÿ˜‰

    < img > is goneIt was already on its way out in HTML4, and is replaced by < object > which provided much better capabilities for fallbacks and alternate text.< applet > is goneIt was already deprecated in HTML4, and is similarly replaced by < object >.

    Source

  18. Every single Quicktime file these days are actually standard mpeg files, based on mpeg specs. Quicktime is a container, not a codec itself.These days, people seems to choose h264 because of its efficiency which is actually mpeg4 part 10. Clever ones who wants to scale to mobile keeps mpeg4 sp streams since they are basis of 3g which is also a documented standard.If you want to flame Apple for not supporting a decade old proprietary standard which was supposed to be dead but donated to open source, fine. Just don't even dare to claim they don't support standards. They do. They supported mpeg4, 3G while nobody industry cared about and people actually got laughed at them.A good reason for confusion is, mpeg 4 _container_ was modeled after quicktime file standard. Why? Because it was the best and the most scalable on market that time. Other option was AVI and nothing else.Please talk to a TV or movie ''backstage'' professional about what would happen to actual standards if Apple didn't exist.Another funny fact. Apple supports the so called open codecs. How? The video element in Safari 4 is actually powered by Quicktime. Add codecs to quicktime (completely legit!) and you have Theora or even Dirac video element. While on it, I wish Dirac was brought up as a competitor to h264 because it is the only thing which has potential to be at same league as h264.

  19. Kenneth Pardue writes:Ilgaz, you hit the nail on the head in so many ways it's not funny. I'm sick and tired of the politicizing of Theora and the demonizing of H.264. Even as an advocate of open source, I can see that the only thing that this has done is introduce a new, unwanted element into the adoption of a single format… and one that everybody else is using and is perfectly happy with, from Bluray all the way down to Youtube. H.264 is not some single-vendor format out to lock me in to Apple's control, people need to stop treating it as such.

  20. Anonymous writes:"I'm sick and tired of the politicizing of Theora and the demonizing of H.264. Even as an advocate of open source"Except Theora vs. H.264 has to do with OPEN STANDARDS, not OPEN SOURCE. Open web standards MUST BE PATENT FREE.H.264 is full of patents, and costs a crapload of money if you want to license all those patents.Apple wants H.264 because they want their video format to win, and because they already paid for it.

  21. Originally posted by Aux:

    Actually, sometimes I think there are too many jerks at W3C. Imagine that they reject OGG if Microsoft tries to support it? And it MAY happen if we digg into W3C history.

    Yeap, too many lobbyists there, instead of engineers or thinkers…

  22. Originally posted by c69:

    Yeap, too many lobbyists there, instead of engineers or thinkers…

    Uh, no. If you knew anything about the W3C you would have known how wrong you are.No, the W3C will not reject Ogg if Microsoft tries to support it. That's the most idiotic comment I have ever seen in this blog.

Comments are closed.