[saurik]

I'm sorry, are you serious? Apple chose, of their own volition, to modify, compile, and then distribute a derivative version of WebCore, a project clearly licensed under the LGPL. In order to be compliant with this license, all new/modified code statically linked to the code they took must be cleanly separated from the rest of the binary in a fashion that would allow a working replacement to be compiled and used in its place. So, whether they want to cough up the code for WAK* or "just" give us un-linked clean object files so I can link their work together myself, as it stands they are simply violating this license, and the only thing "in doubt" is their right to use and modify WebCore.

[jws]

Out of curiosity… Why would someone use a locally modified WebCore in iOS?

[saurik]

Normally, developers are able to get away with monkey-patching the compiled code in memory; but, in some cases, you simply need drastically different settings. A while back (important, as Apple now added this feature... at least I think) some developers managed to sort-of-almost recompile WebCore (with some horribly reverse engineered hack for the redacted parts) in order to add RTL (right-to-left text rendering) support: their goal was to get Hebrew better supported (a goal that was mostly successful, and was used by a large number of people in Israel, with nearly everyone in Israel using it).

Even when you take the monkey-patching route I generally prefer (as it allows you to more easily stack patches from multiple developers/vendors), modifications to a C++ library like WebCore are much much harder if you don't have the original source code. In my case, I add a new <script language=""> handler for "text/cycript", a dialect of JavaScript that allows inline Objective-C syntax (similar to Objective-J) that bridges to native code, so it can be used by people developing HTML desktop widgets.