[tolmasky]

WebCore/JSCore for iOS are indeed open source, but yes certain pieces are released as .o's that you just link with it, and additionally it is released as source dumps instead of nicely managed versioning. If you go to http://www.opensource.apple.com/release/ios-61/ and download WebCore you will see plenty of source in there. The point is that you could for example meaningfully edit WebCore (for example adding python scripting support, or perhaps even putting in ogg support, whatever), link it with the .o pieces, and have an interesting new product, but still not be able to release it on iOS due to the rules.

[saurik]

(edit: This comment's first paragraph is wrong, as pointed out in the reply below; in fact, this functionality is not in WebKit, it is in WebCore. However, it is still closed source, and it is not available on the website that was linked to: you cannot find the source code for anything that makes WebKit on iOS work on iOS, as it is all closed. The point stands.)

WebCore != WebKit. You were saying that WebKit was open source and forkable: no, WebKit isn't. There is a library used by WebKit called WebCore that is, but WebCore doesn't provide most of the juicy iOS functionality; Apple actually seems to actively avoid touching WebCore, lest their lives become more difficult due to it being under LGPL.

The reason, then, that I brought up WebCore was as a demonstration that even for things where Apple must release at least some source code (as WebCore is under LGPL), they still weasel around it: WebKit, which is under BSD, has no such protection, and you will note that there is simply nothing available for it on iOS at all.

(Trust me: I routinely download all of opensource.apple.com, to find not just new packages but redactions, and have scripts to reconstruct git repositories out of the various tarballs for key projects, which I then export for others in our community to more easily be able to work off of; you forward me there as if I haven't heard of it... ;P.)

[tolmasky]

No, trust me: I was on the original iPhone team and was responsible for Mobile Safari and "WebKit" on iOS, and you are pretty confused about the project.

For starters, "WebKit" is an overloaded term. There is "WebKit" the framework, which is a bridge between the actual gears (WebCore and JSCore) and applications. In other words, it is an API: an increasingly thin Obj-C layer on top of all the C++ that does the real work. Then there is the "WebKit Project", which is an umbrella term for all that stuff together (WebKit/WebCore/JSCore). Chrome for example neither uses WebKit proper if I recall correctly, nor the engine in JSCore (opting for v8 instead), and yet it is still considered a "WebKit browser". That's because what makes you "behave" like WebKit is WebCore, which actually handles DOM, rendering, CSS, etc etc. So saying that Apple releases WebKit for iOS is perfectly acceptable terminology, even if you are wanting to be pedantic about it. Now I don't know what you define as "juicy functionality", but I can assure you that WebCore is not just some helper library or something, WebCore more or less IS WebKit. It is certainly enough for you to be able to build your own custom browser for iOS. In fact, even if the iOS version was completely closed source, you could still take the desktop 100% open source WebKit and port it to the phone (just like Nokia and Google did for their phones).

So I guess I'm missing the relevancy of your point. If you just wanted to rant that Apple doesn't open source as much as it should, then I sympathize, but it really has nothing to do with the point I was making that due to the separate restrictive nature of the App Store policies, it doesn't matter if WebKit is or isn't open source because you aren't allowed to ship a custom browser engine anyways (at least not one that runs JavaScript).

[saurik]

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?

[tolmasky]

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