This is a step forward, but they are still violating the license. Those releases do not have the necessary information to build a new copy, as required by the LGPL: no project IDE (Xcode) files and no makefiles for the iPhone.
And, as saurik mentions here (http://news.ycombinator.com/item?id=2523786), they do not even release the full source code! Even if you ignore the point about building your own copy, they are still violating the LGPL: releasing the code to those "WAK" classes is not optional.
Are you sure there's a working build system included? There's a file named "Makefile", but it just includes "../Makefile.shared", which--as far as I can tell-isn't included. There's no XCode project file to be seen, so the build directions on webkit.org don't seem operative. Are you actually able to build this?
It appears that there is a "make-generated-sources.sh" script that appears to kick off DerivedSources.make. That looks like it's actually the makefile for the entire thing.
Unfortunately, I don't have access to my mac at the moment to actually tell you if this works.
The 'make-generated-sources.sh' script does exactly what its name says. It creates source files. Take a closer look at DerivedSources.make: all of the (non-phony) targets (start of a line, before a colon) are .c and .h files. It never even invokes a compiler or linker, and doesn't even reference the vast majority of the code, so it certainly isn't a makefile for the entire thing.
Also, you can run 'make-generated-sources.sh' on pretty much any Linux or UNIX (probably including Cygwin).
Inspection of the provided WebCore binaries and the libraries that use them, Objective-C runtime information (often via Cycript; http://cycript.org/), and the fact they include headers (but not implementations) in the iOS releases.
The WAK header you linked to looks reminds me of a primitive version of NSStringDrawing.h. It is entirely possible that WAK is legacy and/or the drawing for WebCore is handled outside of WebCore itself.
Or maybe there is some common code within WebCore that is shared between Mac and iOS, and one of the files needs to import the WAK headers to compile correctly?
While it is fun to get worked up into a frenzy, I doubt this is an LGPL violation.
It is definitely a violation. For example, here's (http://pastebin.com/GvFVfWHV) an iOS crash log (found via a quick google) that shows (on line 77) that the WAKWindow code is, in fact, inside the WebCore binary (statically linked in).
As static linking is covered by the LGPL, the source code for that (and other) classes must be made available, yet they are not. How is that not a LGPL violation?
(You can also see via the "class-dump" utility that there are many more WAK classes inside the WebCore binary. No source code has ever been released for those classes.)
Do we know they are LGPL? The copyrights in the headers don't seem to list any years earlier than 2005, which could indicate they are all files that were completely written by Apple and thus can be under whatever license Apple wants.
They are. For example, in this[0] crash report (found with a quick Google search), on line 77, it clearly shows that the WAKWindow function is inside the WebCore binary (statically linked). You can also find this by running class-dump on a copy of WebCore from iOS: there are many linked-in WAK classes do not have source code released as the GPL requires.
And, as saurik mentions here (http://news.ycombinator.com/item?id=2523786), they do not even release the full source code! Even if you ignore the point about building your own copy, they are still violating the LGPL: releasing the code to those "WAK" classes is not optional.