So, I just spent some time digging around in these libraries, to figure out where I might be wrong about this, and it seems like this is my mistake: a bunch of functionality I thought was in WebKit is actually in the closed-source parts of WebCore. Specifically, I'm talking about the tiled rendering (TileCache.mm) and all of the multitouch logic (PlatformTouchEventIPhone.mm). Even simple things like the copy/paste support are redacted, as is scrolling (yes: scrolling). For other platforms, all of this code is available.
This closed source part contains tons of simply critical things, such as how to interact with the iPhone's memory management notification system, how to manage the network state transitions, how to interact with embedded video... pretty much everything about MobileSafari that makes it MobileSafari as opposed to a less-than-half-operational desktop version of Safari with a touch screen (which would suck) is closed source.
I'm therefore quite sorry that I thought that this stuff was in the other library, but my point about the "open source and forkable" stands, and I think it stands pretty well: I can't fork WebCore and make meaningful changes to it for this system. In fact, even for people who have access to the system's internals (we jailbreak users), the few people who used to recompile WebCore for it (the Hebrew community) gave up and moved to writing Substrate extensions instead.
To be clear: I consider these iOS-specific things to be "the juicy parts" of MobileSafari: if you want to compete, you have to have really strong compatible answers for them. It isn't sufficient to take a desktop copy of WebKit and recompile it, because if you did that you'd just have a totally unusable browser experience... you wouldn't even have as much functionality as embedding a UIWebView in your application and attempting to externally script it.
So, yes: you are right that these are in WebCore, and that my complaint about "WebCore != WebKit" was wrong. The reason I made that argument was to try to reconcile your insistence that WebKit for iOS was open source with the reality that there really is no source code available from Apple for anything but "something that renders HTML (slowly, and missing features)"; my reconciliation was wrong, but the reason for it is still correct: WebKit for iOS, including WebCore, is not "open source and forkable" enough to make a web browser.
To the extent to which one can then put in the elbow grease to add back all of these missing parts in order to make a web browser, honestly one may as well be starting with any other rendering engine that isn't yet ported to this platform. Therefore, if WebKit for desktop systems is relevant to this discussion, then Gecko being open source is equally as relevant and libcurl in general being open source is largely as relevant. You can also build web browsers out of those.
Given this, I'm having an increasingly difficult time trying to figure out where your correction to kenjackson's argument was: you tried to give him a different way to think about it (in a way that might undermine his argument that WebKit is a defacto implementation due to an inability to install your own copy on iOS), but it is starting to seem like you just agree with him? Am I simply misunderstanding why you were responding to him?
Yes that is the misunderstanding, I do agree with him (you can see another response to him here where we continue agreeing: http://news.ycombinator.com/item?id=5214213 ). I was not correcting him by saying "Here's another way to think about it", I was offering another interpretation of why kenjackson is right by looking at the case of mobile in particular.
I chose to focus on mobile for iOS precisely because here you have the greatest example of how open source is helpless and irrelevant. Even if Apple were to satisfy all your requirements for WebKit being open source, you still would not be allowed to compile it and ship it in your app, let alone modify it and ship it. Even if I write the best browser ever for iOS, I am not allowed to ship it on iOS. This is why I keep coming back to it not mattering whether you can or can't fork WebKit for iOS, just like it doesn't matter whether you can or can't write a completely new engine from scratch for iOS, just like it doesn't matter whether you can or can't fork FireFox for iOS: due to the nature of the platform, the web is closed on iOS PERIOD. Apple is THE gatekeeper of all features that enter the iOS web. Continuing to agree with kenjackson, that is why he is right that a better runtime or plugin system are ultimately more important for the web to be open than source code being released: as long as I can have a direct relationship with the user where they can install a plugin and modify the behavior of their browser, then there is a shot for non-dominant market players to always influence the direction of the web (the same way Adobe created the video revolution of the web without needing to own a browser or a cell phone or any other way of forcing people to use their tech).
I was really confused why you kept arguing with me about how open source WebKit is when my point was "whether or not its open source and you can fork it, it doesn't matter because the web is closed on iOS for deeper reasons".
This closed source part contains tons of simply critical things, such as how to interact with the iPhone's memory management notification system, how to manage the network state transitions, how to interact with embedded video... pretty much everything about MobileSafari that makes it MobileSafari as opposed to a less-than-half-operational desktop version of Safari with a touch screen (which would suck) is closed source.
I'm therefore quite sorry that I thought that this stuff was in the other library, but my point about the "open source and forkable" stands, and I think it stands pretty well: I can't fork WebCore and make meaningful changes to it for this system. In fact, even for people who have access to the system's internals (we jailbreak users), the few people who used to recompile WebCore for it (the Hebrew community) gave up and moved to writing Substrate extensions instead.
To be clear: I consider these iOS-specific things to be "the juicy parts" of MobileSafari: if you want to compete, you have to have really strong compatible answers for them. It isn't sufficient to take a desktop copy of WebKit and recompile it, because if you did that you'd just have a totally unusable browser experience... you wouldn't even have as much functionality as embedding a UIWebView in your application and attempting to externally script it.
So, yes: you are right that these are in WebCore, and that my complaint about "WebCore != WebKit" was wrong. The reason I made that argument was to try to reconcile your insistence that WebKit for iOS was open source with the reality that there really is no source code available from Apple for anything but "something that renders HTML (slowly, and missing features)"; my reconciliation was wrong, but the reason for it is still correct: WebKit for iOS, including WebCore, is not "open source and forkable" enough to make a web browser.
To the extent to which one can then put in the elbow grease to add back all of these missing parts in order to make a web browser, honestly one may as well be starting with any other rendering engine that isn't yet ported to this platform. Therefore, if WebKit for desktop systems is relevant to this discussion, then Gecko being open source is equally as relevant and libcurl in general being open source is largely as relevant. You can also build web browsers out of those.
Given this, I'm having an increasingly difficult time trying to figure out where your correction to kenjackson's argument was: you tried to give him a different way to think about it (in a way that might undermine his argument that WebKit is a defacto implementation due to an inability to install your own copy on iOS), but it is starting to seem like you just agree with him? Am I simply misunderstanding why you were responding to him?