I agree that b) is the correct interpretation of events. And I would add that they shouldn't be let off the hook if they are late again. However, if corporations see that:
a) the community's response to non-release is complaining
b) the community's response to remedying the non-releasal is more complaining
then the community is not giving very strong incentives for corporations to change their behavior. I think Apple should get some praise for releasing the code. Not because they were right all along, but because I would like the corporate world to see that there are good will benefits to playing by the rules. Stick, yes. But also carrot.
Good job for fixing the situation, Apple. We all like things much better this way. Let's not go through this again, okay?
If you aren't sure what they are - javascriptcore and webcore have their origins in KHTML, no matter how much of it has been replaced by Apple it's still from that, gcc and gdb are well known GNU parts. CCtools seems to have Darwin origins, they chose to open source it.
These sources are the same ones that Apple released for 4.2, 4.1, and so on.
Maybe Apple just didn't modify any of the other tools/libraries used in iOS (or the other tools/libraries have a license that doesn't require the modifications to be released.
Most of it(especially the javascript and webcore libraries) were present in iOS 1.0, and Apple was fairly quick on releasing the source then, so it was odd that Apple took their time releasing the source. The 4.3 releases took almost 2 months to get out.
Yeah, you're wrong. Apple's acceptance of paragraph three of the GPL (assuming version two) doesn't require that "the release of this code should be an item on the product launch checklist." That's all I was saying: "Should" is a word handy for brow-beating. In usages like the above, it expresses an opinion, often one with little support.
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.
a) See! That was a lot of noise about nothing.
b) See! Without that noise they wouldn't have done anything.