IOS 4.3 sources are available | Hacker News Reader

IOS 4.3 sources are available

opensource.apple.com

Possible responses:

a) See! That was a lot of noise about nothing.

b) See! Without that noise they wouldn't have done anything.

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.

The title is a bit misleading since it's only sources of a few tools used in Apple's iOS.

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.

The release of this code should be an item on the product launch checklist.

All ice cream should be coffee flavored.

More like, "all legal requirements around the redistribution of code we used should be followed."

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.

What is this? Can someone give me an insight of these sources?

See http://news.ycombinator.com/item?id=2521488

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.

What is "WAK"?

WAK is a set of classes in WebCore. They are released in the Mac code releases, for example: http://opensource.apple.com/source/WebCore/WebCore-351.9/wak...

For some reason, Apple does not include them in the iOS releases, in a violation of the LGPL.

Uh, they did release it.

http://opensource.apple.com/source/WebCore/WebCore-955.66.1/...

The source is here: http://opensource.apple.com/source/WebCore/WebCore-955.66.1/...

EDIT: I'm probably missing something, but it appears that the wak code was present since 1.0.

Those are headers, not the implementations. If you find the .m files that go with those, that'd be awesome, but they do not appear to release them.

Ah, that's it.

Neither OSX or iOS release the implementation, though.

Wouldn't they only be required to provide the .m files if the WAK classes were statically compiled with the WebCore code?

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.

[0]: http://pastebin.com/GvFVfWHV

Interesting. Cheers for the concrete info.

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.

Only if it's it's statically linked.

If it's dynamically linked, all they need to do is release the source.

EDIT: There are also makefiles provided in the release.

There are also makefiles provided in the release.

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

How do you know that WebCore on iOS still uses WAK?

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

Reply on news.ycombinator.com