Posted
by
CmdrTaco
on Monday May 09, 2011 @11:01AM
from the hey-now-wait-a-minute dept.

jfruhlinger writes "Ever since Apple forked the KHTML project to create WebKit, the rendering engine at the core of Safari, the company has been a good open source citizen, releasing the code back to the community after updates. But that suddenly stopped in March, with no code releases for the last two updates to the iOS version of the browser, for reasons unknown. This might remind you of Google's failure to release the Honeycomb source code. But at least Google announced that it was holding the code back, and Android is under a license that allows for a delay; the LGPL'd WebKit isn't."Update: 05/09 21:21 GMT by S: Reader Shin-LaC points out that Apple has now released the relevant source code.

Other than some underlying systems bits that's copyleft (Linux kernel, Bluez, some system utils), or BSD licensed, Google generally own most of the Android code outright. So Google don't ever have to release Honeycomb. It's their code, they don't have to give source if they don't want to. (That said, I reckon their bluetooth stack depends sufficiently on BlueZ that their userspace becomes derived from that GPL code - stuffing IPC between your code and GPL code does NOT, of itself, mean your code escapes from the GPL; but that still doesn't mean they'd have to release their code).

Apple OTOH started WebKit/WebCore as a fork of KHTML, which is LGPL. So it wasn't their code at all to start with and, unless they're rewritten ALL the code since the fork AND gotten appropriate grants from the other contributors to WebKit, Apple are obliged to honour the *other* copyright holders and follow the LGPL licence.

No, it doesn't matter. Legally, under the GPL, they are required to distribute (upon request) the source to everyone that receives the binary. At this moment, due to Apple's non-response, someone who has received the binary could initiate legal action against Apple, as could the original authors of the code.

Now, there is a grace period under the GPL (for example, Apple can choose to mail the source code to you, and of course that could take a week or even a month for processing), and if Apple can show intent to release the source code, and actually does it within the next month, it is doubtful there would be any punitive action taken by the court.

The real question is why the delay from Apple. It is unlikely they intend on keeping the code secret (since that would be insanely idiotic). A possible explanation is that the person who was responsible for maintaining the link to the open source code on the Apple website has quit or been fired, and his replacement doesn't yet know everything he was doing. Something like that. Or it could be that Apple hates the open source community and wants to spite them in every way possible. Although I find that less likely.

The fact that they are holding back is consistent with the fact that Apple only releases what they absolutely must release.

All you need to do is recall the shitstorm it took for Apple to release "the preferred form of the work for making modifications to" instead of huge blobs of code that no-one in their right mind would work of off for Webkit in the first place.

If you remember the first release of their changes way back in the early days of Webkit was received very poorly because it was not well documented and didn't mesh well with the existing project (something they have since changed, and now things are smoother).

Who knows why there's a delay here?

In terms of "releasing only what they have to", I'm not sure I fully buy that - Apple is a pretty good open source citizen in terms of project contributions and has even opened up some of its own projects and put them out there when they really had no need. Their work on things like LLVM while clearly very important for their own success, is benefiting the community at large. Projects like the quicktime streaming server, address and calendar servers, Webkit and Nitro, just to name a few.

I don't buy that they're suddenly turning turtle, especially on something as powerful for them as Webkit. Sure they're not the "do no wrong" golden child and they do plenty that is questionable, but I don't thin they're going to shoot the goose that lays their platinum encrusted eggs - they have been *extremely* successful with a combination of open and closed software with OS X (and by extension, iOS). They have carved out a little niche between the two opposing models (Windows on one side, Linux/BSD on the other) that mixes the benefits of both approaches. I see no reason they'd risk that.

No one has actually got any confirmed information that they are *not* releasing anything, and given the track record with Webkit to date (excellent with a bumpy start) they're not just going to ignore something as obvious as the LGPL code restrictions - they'll definitely release those code changes, since they are legally required to do so.

Am I the only to see a very simple explanation that the author has missed? To recap here is what the author is saying:

WebKit is LGPL so updates should be released

Apple has released iOS 4.3, 4.3.1,4.3.2, and 4.3.3 without any updates to WebKit

Therefore Apple is holding back WebKit updates.

Am I the only one to see the major flaw in logic? iOS updates may include Safari updates which may include WebKit updates but iOS updates are not necessarily WebKit updates. If you look at the actual 4.3 updates [slashdot.org] that the author describes, the vast majority of changes have nothing to do with Safari. Even if they did, remember Safari is WebKit + Apple's browser code just like Chrome = WebKit + Google's code. The few changes around Safari seem to imply fixes to Safari not WebKit. Also if the author did any deep analysis, in 4.2, Apple updated Safari to use WebKit 533.17.9 whereas the newest stable version if WebKit is 534.20.

Nobody seems to have been clear on what is supposed to be published but isn't. The WebKit source [webkit.org] has had checkins as recently as 2 minutes ago, so it doesn't look like Apple have stopped publishing the source to me.