WebCore and JavaScriptCore are LGPL, so they can't stop providing the source code for their mobile builds. I sent Apple a request for disclosure a couple days ago. In a week or so if I haven't gotten anything I will start escalating.
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.
Yeah, you can get the webkit source through the webkit repo.
however, since it's under lgpl, any source you write that uses webkit must also be shared. this is why some of EA's code is published: http://gpl.ea.com/
I still haven't got a clue what needs to be done if I used a component with, say MIT license which in turn uses a dependency lib that is LGPL licensed.
That components vendor of course then has to make the source of the LGPL dependency available on request. But what about me?
What would I need to do if I wanted to sell a closed source product that uses this MIT licensed component which is of course totally permitted my the MIT license.
Would I have to stop using this MIT licensed component unless I also want to provide the source code of a dependency lib that I might not even be aware of?
If your distributed object code includes a library that is under the LGPL, then you must also make the source of that LGPL library available on request, and users should be able to change that LGPL library in your project with their modified version of that LGPL library. So, if I remember well, you can either (a) use dynamic linking so that the user can replace your version of the LGPL library with their modified version, or you can (b) provide object code that can be linked with their modified version of the LGPL library.
IANAL, but are at least two cases of "was not aware of": if that MIT licensed package mentioned the LGPL dependency, you could and should have been aware of the dependency, and I think you must mention it in your license, and provide the source on request.
If, on the other hand, the MIT licensed product doesn't mention the dependency, and you cannot be expected to have learnt of it elsewhere, you should be of the hook, both ethically and as far as damage lawsuits go. As soon as that "expected to know of" changes, you must change your license and provide the source on request (or remove the dependency or stop shipping your entire product)
Of course, that is an opinion and just theoretical. In practice, who knows what will happen? That is one reason large companies are/used to be worried about using any source that doesn't ship with extensive disclaimers. Large companies are expected to spend more effort researching these things. That lowers the threshold for "should have known". They generally also have more money. That makes them more open for lawsuits if they are found to walk in a gray area.
