Hacker News Reader

Comment by Xuzz | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com