No: the mobile version of WebCore is different, and for example comes with binary object blobs (which is sufficient for LGPL compliance) for source code that Apple refuses to provide as open source. I wish I had been here earlier to correct this misinformation :/ (though I'm also glad I've gotten in the habit of not checking Hacker News after I comment). Note the libWebCore_{Sim,armv7,armv7s}.a that is provided in the WebCore source repository at opensource.apple.com.
It is also simply not sufficient to say "here is a repository with a lot of code in it": you have to be able to specify what exact code was used for the build (which is what I care about, as I'm constantly trying to analyze the version of WebCore on the device: I have no interest in compiling my own copy or building my own browser), and it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.
But the LGPL requires you that you can (principally) exchange the LGPL shared libraries by your own ones. (source: http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Licen...: 'Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.'). Is this possible on iOS?
So, in practice, the LGPL doesn't actually let you change the code out, because the bootloader is allowed to make it impossible to modify the binaries, this being the reason for GPL3. On a jailbroken iOS device, though: yes, you can swap out WebCore if you manage to compile it (good luck ;P).
>It is also simply not sufficient to say "here is a repository with a lot of code in it": you have to be able to specify what exact code was used for the build
Does the LGPL really specify that? IIRC the license is pretty vague and that seems way too specific to hold up in court.
The LGPL references the terms of the GPL in the context of the library released under the license. For both versions 2 and 3 of the GPL, it states that build instructions must be made available [1].
> it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.
They're all at http://trac.webkit.org/browser/tags/. You can map from the LC_SOURCE_VERSION baked into one of WebKit's frameworks back to one of those tags.
OK, at some point I see they started adding AppleWebKit/# to the User-Agent. On a device running iOS 6.1, I am seeing "536.26". In WebCore.framework it reports "6536.26" (at some point they dropped the leading "6" from versions).
It looks to just be missing the final version component, as even versions of iOS 6.0.x have that same version. So, I went and got the code from opensource.apple.com and started bisecting for the version... the code is totally different.
I don't think you understand the situation here: the iOS version of WebCore is not developed in public, and lots of parts of it are redacted. Even in the code dumps from Apple on opensource.apple.com, some of the code is a .a file.
To demonstrate this, as maybe it still isn't clear what is going on, Apple released iOS 6.0 in September of 2012. Apple released the source code for the iOS 6.0 version of WebCore, and it includes a special "platforms/ios" folder.
This folder contains files like ClipboardIOS.h. If we look in the WebKit source code repository, this file did not get "upstreamed" until May of 2013. You simply can't tag something if it isn't even in the source code repository.
(Interestingly, when Apple did finally provide this source code, they also provided the corresponding ClipboardIOS.mm: they did not on opensource.apple.com, and instead provided ClipboardIOS.o as part of libWebCore_armv7.a.)
I hadn't considered that you were focused on historical versions of WebKit as I was thinking of the latest shipping versions. You're quite correct about this for historical versions of iOS. Since then the iOS port of WebKit has been upstreamed into the WebKit SVN repository, and the WebCore content in the tags correspond exactly to the source that's built.
http://www.opensource.apple.com/source/WebCore/WebCore-1640....
It is also simply not sufficient to say "here is a repository with a lot of code in it": you have to be able to specify what exact code was used for the build (which is what I care about, as I'm constantly trying to analyze the version of WebCore on the device: I have no interest in compiling my own copy or building my own browser), and it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.