Apple not providing LGPL webkit source code for latest iOS 4.3.x | Hacker News Reader

Apple not providing LGPL webkit source code for latest iOS 4.3.x

laforge.gnumonks.org

274 pointsgnufs112 comments

For iOS 4.1, which came out in September 2010, absolutely no GPL code for it (or later versions, like 4.2) was posted until March 2011. That's not 8 weeks: that's about 6 months.

When comex (http://twitter.com/comex) and saurik (http://saurik.com/) asked for it (via emails to opensource@apple.com and copyright@apple.con) around last November, I don't think they got any response from Apple —until this year. Then, Apple let them know that it would be up "within a week". I think the iOS 4.1 and 4.2 code actually went up about three weeks after they received that email.

saurik has even more examples of them not releasing the [L]GPL'd code near the top of this post: http://www.saurik.com/id/4 — "Frankly, I wouldn't be surprised at all if Apple ends up on the bad end of a GPL-related lawsuit."

(In my opinion, the fact Apple has posted any code for iOS 4.3 at this point is a big step in the right direction: they're not perfect yet, but at least they've got 8/10 of the projects up.)

> In my opinion, the fact Apple has posted any code for iOS 4.3 at this point is a big step in the right direction: they're not perfect yet, but at least they've got 8/10 of the projects up.

The truly weird part, to me, is that with as much (L)GPL code Apple releases they don't seem to have an automatic, systematic system in place to handle that. Even for a project as big as iOS.

I think the problem is that doing so is a zero-revenue effort. Why spend man-hours putting together an automated workflow for source release when you can just do it manually (and lazily) every time someone complains? That doesn't justify it, of course, but looking at it that way makes it seem not-weird.

This is risky, because lawsuits can have damage awards. If you decide not to comply with a contract you've agreed to because "it's a zero-revenue effort", that could look bad in court.

Legality aside, it looks pretty bad from a human interaction perspective: "we took thousands of man-hours worth of code from the community, but we were too lazy to spend even one man hour to upload a tarball to our website and follow that community's wishes". The fact that they are legally-obligated to not act like that just makes it even worse.

But is it really an hour? I doubt that Apple uploads the code they actually used: it's likely that code, and then lots of removed components that would reveal too much about how something works (e.g. there are no build scripts or Xcode projects for JavaScriptCore releases, only the code itself).

At least, they would need to make sure that none of their proprietary code slips out. That likely involves more than "svn checkout; tar; ftp", maybe even lawyers to check it.

there are no build scripts or Xcode projects for JavaScriptCore releases, only the code itself

Not true. See JavaScriptCore.xcodeproj in ...

http://www.opensource.apple.com/source/JavaScriptCore/JavaSc... http://svn.webkit.org/repository/webkit/trunk/Source/JavaScr...

... and if Xcode isn't your thing, just run the script "build-webkit" ...

http://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/

... build instructions in plain English here ...

http://www.webkit.org/building/build.html

That's true for standard WebKit, and even the Mac OS X version, but not for iOS.

For example, the latest iOS JavaScriptCore release (4.2, http://www.opensource.apple.com/source/JavaScriptCore/JavaSc...) has no Xcode files like the one you linked does.

I haven't read the LGPL lately, but is that a violation? Do they have to provide enough information to build your own copy?

Yes, it is.

"For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library."

It has Makefiles. Assuming those build a binary, why would you think they are hiding Xcode project files?

They don't. Well, they might, but not an iOS binary. There's Makefiles for Android and (I believe) the desktop, but nothing setup for use with the iPhone SDK.

In addition to what openbear pointed out, it should be noted that the GPL requires build scripts to be included with the source. (What good would source do anybody without the three-bajillion-line Makefile that builds it?) GPLv3 also extends this to stuff needed to run the code on the hardware it's intended for (like tools to sign binaries so they'll run on locked-down embedded platforms like phones or DVRs).

There's a practical aspect to the GPL, here. The spirit of the license is, "if I can't view, modify, build, use, and redistribute the software, it's a violation."

components that would reveal too much about how something works

It is a significant violation of the spirit of open source to try to keep others from understanding how things work. Mobile Safari may be a competitive advantage for Apple, but the advantages are in the UI, not JavaScriptCore. Google already has a pretty decent JS engine of its own, after all.

For sure, I'm not defending them. I'm just trying to drive home the point that Apple is going to do what's good for Apple. Unless the community makes the promptness of source releases a business concern for Apple, they have no incentive to improve their process. Contracts are only binding insofar as they are enforced, in this case either by litigious means or by negative PR that impacts Apple's bottom line.

> Why spend man-hours putting together an automated workflow for source release when you can just do it manually (and lazily) every time someone complains?

Because doing it manually every time ends up costing more man-hours than having an engineer or two bang up some check/upload script in a morning.

It's not that hard, I don't think.

E.g.,

All GPL repositories live in this /gpl/ directory; it gets tarballed and gzipped and dumped into the /other/ location immediately prior to creating the build image.

Maybe Apple's got some whacked-out approach to code management brought on by some funky OS Classic approach, but I doubt it, they are smart people over there.

Apple seems to have a lot of odd processes with respect to code and development tools. One super annoying one is having to re-download the entier Xcode bundle (4GB+) every time they make a minor change.

Yeah, Apple is chronically unable to ship diff updates (or more generally updates). They just can't do it apparently. iTunes update? Download everything. Xcode update? Download everything. AppStore app update? Download everthing. iOS firmware update? Download everything.

Complete, non-diff updates have predictability on their side; if something was corrupted on the user's end, the update will overwrite it, whereas a diff will leave it in an unpredictable state.

I suspect Apple prefers the simplicity and explainability of "here's the update, same thing for everyone" to "well if this smaller update didn't work in any of a huge variety of ways, you could optionally try this other update"

we have a way to detect if it's broken.

Do it by checksum. If the checksums don't match, then redownload the changed parts. This is also fully predictable, but it's also far faster.

This can easily be automated. You could send a hash of the binary and have a custom patch either pulled from cache or created (the largest "patch" being the whole binary). You'd end up with a fairly complete cache very fast though. Binary diffing is a mostly solved problem. This assumes that there's a list of hashes that correlate to known historical binaries. If the hash doesn't match you fall back to sending the whole thing.

> "well if this smaller update didn't work in any of a huge variety of ways, you could optionally try this other update"

Not once has Chrome botched itself during an incremental upgrade of itself.

It's a trade-off between the size of a download and having to prepare, test against and support multiple configurations.

You sound like the only person who's dealt with this problem before :-)

I remember the Visual Studio setup team and their stories about the woes of trying to make downloads as small as possible. You're fighting with:

- wanting the file download to be one step

- what version (or sets of versions?) can you upgrade from? Does this include the one-off patches you were mandated to provide to top-tier (guaranteed bug turnaround time) Fortune 100 partners?

- how do you handle corrupted files or munged bits of the installation that were unchanged between versions?

The list goes on. You'd think things like Setup are boring, but trying to make the experience smooth and good requires and incredible amount of amazingly unglamorous work. It's one of those pieces of the product that nobody notices until it is slow/buggy/has picture of people who are way too happy to be using your product flash during installation.

All their other updates done through Software Update use a very sophisticated binary diff setup using Colin Percival's bsdiff — the updater checks the current state of your filesystem, hashing the files covered by the update manifests, and downloads the smallest possible update.

The only downside is that the "Checking for new software…" dialog takes fucking forever.

I'd love if that dialogue would give more feedback about what it's doing. I've always just assumed that there's an issue with my connection or their update servers.

6 mo. is ridiculous but I roll my eyes @ GPL lawsuit.

It is actually worse than that, as Apple has /never/ been in compliance with this license: I want the code to WAK*. It is simply not possible to compile a copy of iOS WebCore with the incomplete code that Apple has chosen to provide.

Apple, as with many other companies, does not understand that it has to release the source simultaneously with the program using it.

Despite the articles claim, Apple has not released the source in s timely manner for previous versions of iOS, instead waiting for it to be pointed out or for version N+1 or N+2 to be released first.

They are only required to provide the source upon request. If they are rejecting those requests, that is another matter, but that doesn't seem to be the case here.

The problem is when they take 6 months to respond to such requests. What if they decide to wait a year next time? The ambiguity of "timely manner" in the license isn't helping, perhaps it's time for an improved version of the license.

Doesn't say anything of "timely manner" in the license text. It just says that besides distributing the sources with the binary it's sufficient to accompany "a written offer to give any third party the source code".

Thus, they're on clear only if they give the source code to anyone who asks. Apparently they don't: giving it "soon" is not giving the source code but merely stating a promise to do so which is not allowed by the license. Ditto for not responding.

You are right, I can't find "timely manner" there. I was reading through various comments and it was mentioned multiple times so I didn't check.

See this thread: http://news.ycombinator.com/item?id=2521911

"You may obtain a complete machine-readable copy of the source code for the LGPL-licensed portions under the terms of LGPL, without charge except for the cost of media, shipping, and handling, upon written request to Apple."

My point is that if it takes a year to "process" such requests, it renders their promise to share the source kind of useless. Now we can argue about how many months would be acceptable, but I'm not sure there's much of a point in that. So a license that has some more specific rules regarding how such requests should be handled, would be an improvement.

Nothing about the GNU family of licenses requires simultaneous -- or "timely" -- release of source for a binary. Just because it's usually done that way in the OSS operating system world doesn't mean that it must be done that way. (In fact, it's usually the other way around for OSS: the source precedes the binaries.)

Nor, by the way, are they required to release it to any random user out there; they are only required to release it to people who receive the binaries (it's not clear if this must be honoured if the binaries aren't received legally, but I suspect it does).

I'm not a lawyer, but I'm pretty sure it implicitly requires reasonably timely release of source for a binary. There's nothing in the license about any period of time that you're allowed to leave it before providing source, so I assume it's supposed to be fairly immediate. To put it another way, the license would be useless if they were allowed to wait 100 years before providing source. Since that's clearly not okay, why should waiting 6 months be okay either?

Fairly immediately?! What the hell does that mean? We all need to spend less time talking out of our asses, playing armchair lawyers, and more time either heads-down coding or going to law school.

... and maybe we all need to spend less time being aggressive asses.

They made it pretty obvious that they were speculating, and were not trained in law. What, is that illegal now? Is it bad form? Is it offensive? They make a fairly good point about allowing an infinite period of time, which adds to the discussion.

You, by insulting the poster needlessly and grossly missing the point of the post, have added nothing to the discussion.

I usually try to refrain from doing this, since I'm also adding nothing to the discussion, but this is becoming an alarming trend.

Yes, speculating i.e. talking out of your ass is offensive. It wastes everyone's time. It's a dangerous trend. Baseless speculation forms the bedrock of the vast majority of content that appears on CNN, MSNBC, and Fox News. It is dangerous because it's "facty" but has no value.

You and your sanctimonious defense of people's right to spout what you admit is nonsense are part of the problem. Part of a healthy culture, whether it's our culture at large or "hacker culture" is a respect for facts and thoughtful, informed opinions based on knowledge and experience. The "victim" of my comment is pissing all over a set of ideals that we should all hold sacred.

Civility plays an important part in effective communication. You may feel that you are merely stating your opinion directly and with force. But an argument is only as strong as its ability to persuade. When you put people on the defensive--when you force an emotional rather than rational reaction--you rob an argument of its power.

Aside from that, there are two other reasons to be more civil. One is that it's just a nice thing to do to treat people respectfully even (or especially) when you're telling them they're wrong. But if that doesn't persuade you, it's worth remembering that civility is explicitly required in the HN Guidelines.

Good points. I, however, am dispirited by watching comments devoid of value not getting subjected to the same sort of enthusiastic down-voting as comments that reflect exasperation at those very vacuous, time-wasting comments.

A culture that prefers polite nonsense to harsh truth-telling is a weak culture. At the very least, both should be punished, but I don't see that here.

Do you think that maybe you're being a little bit oversensitive about this? I wasn't pissing all over anything, simply offering my opinion that I don't think it's okay to wait to release the source code. I have plenty of respect for facts, knowledge and experience; if Eben Moglen pops into this thread to offer his opinion I'm happily going to defer to him.

If it's so essential to hold our tongues unless we're formally qualified experts on a topic, there wouldn't be much discussion on HN. That would kind of suck.

It means immediately. If the binary is available so the source should be available. Simple.

From section 6 of http://www.gnu.org/licenses/gpl.html:

"You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source"

Unless you provide the source, you cannot provide binaries. That means that, unless the source is conveyed (or conveyable) Apple cannot offer binaries based on it.

All we need it a copyright holder to oblige Apple to obey the conditions under which the software is generously provided by the community for Apple to build their very successful products. Apple is free to use the free and open source software other people and companies offer provided they respect the licenses.

That's the GPLv3; Apple ships no code licensed under the GPLv3.

The GPLv2 reads: You may copy and distribute the Program ... provided that you ... Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.

Apple does provide access to the code upon request, though it's often not very timely ...

> not very timely ...

I wonder how untimely would it be to extend their delay forever.

Sad to say, but this is what I would expect from Microsoft, not Apple.

This is true unless you are the copyright holder, in which case you can do whatever you want.

They aren't "the" copyright holder.

As a hardcore Apple fan, I strongly hope one of the non-Apple contributors to Webkit sends a source request to Apple with the implicit threat of lawsuit.

Big companies don't treat others with kid gloves when it comes to licensing and copyright, so why should we take it from them?

You can send the request yourself. Any third party is allowed.

While in all likelihood it's a legal and bureaucratic issue causing delay, I can see how this is considered bad form.

However, I've made an attempt at understanding the source release obligations under the GPL and all I get from it is: When you release to the public, you've got to release the source. But at no point have I found a "it has to be released immediately."

http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePos...

The only clause I can see Apple potentially hiding under is Section 3.B of the GPL. ie. as long as they have the door open for written requests all is well.

http://www.gnu.org/licenses/gpl-2.0.html

Can someone please clarify for me how the "well intended" spirit of the license works versus the real world legalities and requirements ?

Copyright law prohibits distribution of derived works. The LGPL is a license which gives permission to distribute software if certain conditions are met. In this case the license is from the many authors of Webkit and it permits Apple to distribute a derivative work (the iOS browser). If you think about it that way then "immediately" doesn't really come into play. If Apple provides a copy of the source when asked, they're complying with the license. If they don't they have no license. Technically, they are infringing copyright every time they distribute a copy of iOS.

If someone sues, would a court award damages for the copies distributed or enjoin distribution of iOS until they comply? I doubt anyone knows because AFAIK no case has ever made it that far. Typically (L)GPL disputes are settled long before they make it to court, because the cost of litigation for both sides is high compared to the remedy desired (release of modified source).

I wonder if there's a role for "Copyleft Trolls", i.e. litigators who acquire copyrights to GPL or LGPL source, then sue license violators with the intention of collecting damages rather than just compelling release? US copyright law allows statutory damages of up to $150,000 per work infringed.[1] If each source file is a separate work, there could be a lot of money at stake. In other words, the Righthaven strategy[2] applied to source code instead of newspaper pictures. Perhaps I should apply for a business method patent on that idea.[3]

[1] http://en.wikipedia.org/wiki/Statutory_damages_for_copyright... [2] http://www.google.com/search?q=righthaven+site%3Anews.ycombi... [3] http://en.wikipedia.org/wiki/Business_method_patent

Merci.

I'm still waiting for that "open" FaceTime specification.

Are you sure about that?

http://trac.webkit.org/browser/trunk/Source/WebCore

Edit: I would greatly appreciate an explanation of what is inappropriate about the above link.

Could downvoters explain what's wrong with link to webcore trunk?

I didn't downvote, and IANAL, but I believe I know the difference.

When releasing a product with GPL/LGPL source, the requirement is to provide either the source or an offer to provide the source which corresponds to the exact version of the source code used in that product "on a medium customarily used for software interchange".

So, if there were tags in the webkit repository that said "iOS-4.3.2", "iOS-4.3.3", etc. then Apple could take a tarball of it and someone requesting source could be provided with the tarball and optionally a link to the correct tag in the repository.

However, waving in the general direction of the source repository and saying "it's all in there somewhere" doesn't constitute compliance. Even if one of the Safari versions tagged in that repository happens to be the exact source that ships in some iOS 4.x, Apple has to make that relationship clear because (AFAIK) iOS is the "product" in this case, not Mobile Safari, given that the two are indivisible from the end user's perspective.

(Again IANAL, so this is all mostly based on lurking the Gpl-Violations.org list, reading their Vendor FAQ, and dealing with some reluctanctly GPL compliant companies.)

This is what I'm guessing as well, but unless Apple uses heavily customized versions of WebCore for their iOS releases, this seems like a decidedly trivial violation. Doesn't excuse Apple, but hardly worth all this fuss.

Also, seriously, downvoting both GHFigs' and xentronium's comments is pretty lame, folks. (Feel free to downvote mine: I'll never see the score.)

I was under the impression that they do use a heavily customized version of WebCore.

The LGPL requires that I am able to take Apple's provided source code, make my own modifications, and somehow compile/link the result into the program that is using the binary build.

And, for the record: Apple's provided source code (which /is/ heavily modified for the iPhone), when they do provide it, isn't even complete enough to compile (it is missing a bunch of code for the WAK* classes), so Apple has simply never been in compliance with this license.

WebCore trunk is neither the complete code nor the exact version that Apple ships in iOS. For that, you have to go to their "release" pages like this:

http://www.opensource.apple.com/release/ios-43/

You just need the copyright owners to sue now. The copyright holders can also ask the SFLC do it for them, I'm sure they would love it.

It's a hard place. If they sue, they will be blamed as hardcore radicals. Remember most of the tech journalists depend on advertising.

If you hold copyrights on your software, it's not radical to ask people to refrain from republishing it without a license. That's the central goal of copyright law, and not a new idea invented by the FSF.

Mr. Welte's approach so far has been to talk to the companies first, and only sued if there has been absolutely no (or negative) response.

I think the blog post is part of the "not yet suing" process too, it tries to build a bit of pressure on Apple in the hope that no lawsuit will be necessary.

One doesn't have to start with a lawsuit. One starts with a nice polite letter, on actual paper, to Apple's legal department reminding them of their LGPL obligations and pointing out that they're past deadline and perhaps they should poke the relevant engineering team?

Then if that gets no satisfaction you have your lawyer send the same letter. Then a nastier letter. Only then do you begin to think about preparing a lawsuit, which is expensive and probably overkill.

What you don't do is put up a passive-aggressive blog post. This post doesn't even tell us how many letters have been sent, or by whom, or to whom, or when. Have we even asked the support folks or the engineers, let alone Apple legal?

I can barely find the stomach to blame Apple's engineering team for prioritizing strict and timely license compliance somewhere below: Making their boss Steve Jobs happy, releasing features that paying customers care about, and sleeping. Fortunately, it is not my job to blame them. It is the job of Apple's legal department to blame them. Has anyone asked Apple's legal department?

"I can barely find the stomach to blame Apple's engineering team for prioritizing strict and timely license compliance somewhere below: Making their boss Steve Jobs happy, releasing features that paying customers care about, and sleeping."

Sleep is an important function the brain and body must perform to survive; I would never advocate sleep deprivation.

However, no, Mr Jobs and everyone else can wait as there is a legally binding license governing the release of the code. This is a rare completely black and white issue. The binary is released without the source -> license violation.

If they don't want to spend their time complying with the software license, then they're free to not use open source licensed code in their products. Microsoft do just that, and they never have to worry about compliance issues.

I don't think Apple would appreciate it if I downloaded iWork and instead of paying them said "Promoting strict and timely license compliance falls somewhere below sleeping".

It is true: Apple will not appreciate it at all if you pirate iWork. But will they sue you?

Does anyone have a news story about Apple suing the (many, many) Apple software pirates? So far as I've heard, they don't even send very many nasty letters. Presumably not because they don't believe in paying for software, but because it's strategically unwise.

Anyway, if Apple fails to respond in timely fashion to a series of inquiries they can, indeed, eventually be sued, and maybe that will even be the best move. Perhaps a suit against Google will proceed at the same time:

http://www.electronista.com/articles/11/03/25/google.not.sha...

Though in that case, as well, I doubt it will come to that.

(One of the many virtues of starting your own business is that you soon learn all about the practical limitations of contract law. People violate the letter of your contracts all the time. What are you going to do about it? The law is a relatively blunt instrument; it is expensive and difficult to bring it into play, often more difficult than your unpaid invoice is worth.)

Perhaps a suit against Google will proceed at the same time

Indeed. It seems like applications that have code from non-Google employees have changed, as well as the Linux kernel itself.

FUD : every GPL bit of Honeycomb has been released since January.

Yes, you're right.

So is the issue here that they have not packaged it up for people and put it on opensource.apple.com? Is the source not available in the official repository at webkit.org?

No, it isn't: Apple uses a modified version of WebKit and WebCore for iOS that is not present in trunk. For WebKit they are allowed to hold back these changes, but for WebCore they are not. They do anyway, however, and have actually /never/ provided a copy of WebCore for iOS that is complete enough to compile (in particular, the code for WAK* is redacted).

Who holds the copyright on that webkit source code in question?

We have an update! http://news.ycombinator.com/item?id=2530086

Knowing how evil and secretive Apple is, I would not expect them to care much about open licenses.

This only becomes a real issue when one of the KHTML copyright holders makes it an issue

which they haven't.

Anyone else find this to be a bit over-dramatic?

They have released every other version and just haven't released the 4.3.x one yet. There is no indication that they refuse to release it ever, the site still says "Coming Soon" and it has still been < 2 months since 4.3 was released.

Yes, I understand that under the GPL they're supposed to release it simultaneously with the launch, which they failed to do, but is this really front page news?

Yes. I take license violation very seriously. Imagine if Apple was violating a Microsoft license in this way. They'd be sued in a heart beat. Companies need to realize the (L)GPL is serious. It's not something you can just ignore because it's convenient.

But surely openness is a spectrum, and if they've released versions in the past, and they claim they will be releasing this one, then that still counts as being "open"?

Anything related to Apple is always a good source for some sensationalist piece.

But the conditions of the (L)GPL is that they are _required_ to do so when they release the source at the same time. Releasing it later is more open than not releasing it, but it's still not allowed with the (L)GPL.

It's not about being "open". Its about following the terms of the license. And I believe the only way to enforce a license is through litigation so a lawsuit should be expected.

I don't know what situation is now, but Apple used to be the main contributor to Webkit. Who should sue Apple?

The other contributers whose copyrighted code they are distributing illegally.

Wow. I am pretty sure anyone with this kind of attitude would not work on any project together with guys from Apple.

Apple forked Webkit from KHTML. Google contributes to Webkit. Should the original KHTML and the contributors from Google be deprived of the rights that the LGPL gives them, simply because Apple "owns" the project?

If Apple wants to own Webkit, then answer is simple: require a copyright assignment letter with each patch. Then they can relicense the code whenever they want.

  Apple forked Webkit from KHTML. Google contributes to Webkit.

So? I don't get, why this "forked form KHTML" comes up so often, and how is it relevant. Did Apple ever claim to invent Webkit? Not to my knowledge. What I do know, that a few years ago when Google had no Android and no Chrome Apple was already making Webkit the best rendering engine out there.

But that's completely besides the point. I just cannot imagine someone working on the same project and ready to sue fellow developer's company just because they did not release the source on the same day.

  Then they can relicense the code whenever they want.

If other comments are right, LGPL does not say they must release the source together with a product.

What I'm saying is that the people who wrote KHTML have copyright over Webkit. They released their code under the LGPL, and its Apple's obligation to honor this license until they remove all the original code or get contributers to sign a copyright assignment form. That's how open source projects work: either all the code is owned by some central entity, or the code is owned by the various contributers. When the code is owned by the contributers, your patch is considered a derivative work (for the purpose of copyright) of the other copyright holders' work, so you have to follow the license. On the flip side, if every patch has documentation saying that the central authority (the FSF, the Apache Foundation, etc.) has copyright, then that central authority can relicense however they want. For example, Emacs is now GPLv3, even though most of the code was written well before the GPLv3 existed.

In the case of Webkit, Apple does not require copyright assignment. The code was not originally theirs - their version of Webkit is a fork of KHTML, and so the copyright from KHTML is in force. They have to follow the LGPL, because otherwise they have no legal right to use the code in their products.

That's all I'm saying: the question was "who has a legal claim over Webkit", and my answer was "everyone who's contributed".

The LGPL allows Apple to keep the rest of their stack that links against Webkit proprietary. However, they have to release their changes to Webkit.

Here is the exact wording from the LGPL v2:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

>That's how open source projects work

Just to clarify, that is how GPL licensed software works. There are a lot of different open source licenses that do not require anything.

This is not specific to the GPL. You can't change the license unless the copyright owners agree. That applies for any software license or really anything copyrighted.

Some things are easy because the license specifically permits it: you can GPL a BSD-licensed project, for example. In that case, the agreement from the copyright holders comes in the form of the terms of the license.

Exactly. BSD/MIT/Apache != Public Domain.

But you cannot relicense a BSD-licensed project as GPL because only the original rights-holder can do that. You can apply the GPL on top of the BSD license because the GPL is more specific than the BSD license (ie GPL is a restricted subset of the BSD license, kinda). You must still make the original BSD-licensed code available under the BSD license.

The LGPL allows Apple to keep the rest of their stack that links against Webkit proprietary. However, they have to release their changes to Webkit.

Quite right, but for this point of pedantry: Apple's fork of KHTML is known as WebCore. That part is LGPL. WebKit (the encompassing project) is BSD and always has been. Safari (the browser) is proprietary.

As far as I can tell, Apple's changes to WebCore are in the public repo. e.g.

http://trac.webkit.org/browser/trunk/Source/WebCore/renderin... Revision 85964, 48.1 KB (checked in by hyatt@apple.com, 63 minutes ago)

It comes up because Apple is violating the license they agreed to when they started distributing the KHTML sourcecode under the name webkit. And yes, the LGPL requires you to release the code, not wait weeks or months.

They have to be made available. You can ship a binary with a link to the code for example. But I do believe it's supposed to be available from the day the binaries are out.

  But I do believe it's supposed to be available from the day
  the binaries are out.

So, does anyone knows for sure?

http://lmgtfy.com/?q=GNU+LGPL&l=1

And this helps how exactly? I know what GPL and LGPL is, I was asking, why few there "believe" and "think" instead of quoting.

"4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange."

"Accompany it" is the key phrase. The source needs to be released at the same time as the binaries.

Apparently you stopped reading to soon.

Section 6 states: " As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:"

And 6B specifically says: "b) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution."

So, since Apple is not distributing just the library binary on its own, but rather as part of Safari, Section 6 excepts Section 4. And all they must do, according to 6B, is accompany the work with a written offer (which it does, see Settings/General/Legal) to provide the source. Since no one has specified that they've written to Apple and been denied, they are not in violation of the license.

I think you are misinterpreting section 6. Section 6 is about the requirements for software that use the library. Specifically section 6 is about software that statically links to the library (section 5 is about dynamic linking). If you statically link to the library, the resulting binary contains the library and you are required to provide object files so that a user can relink with a different (and hopefully compatible) version of the library.

In the case of Apple, they have made modifications to the library itself. They are then using the library, with modification, in Safari. Safari can be released under any license as outlined in section 5/6 but not the modifications. Those need to be released.

Without looking I think Google is probably the #1 contributor at this point, with Apple being #2.

Curious why you say that, as Chrome is definitely a different project than WebKit (obviously they use it, but they defer rendering issues to the main WebKit tracker), and I’m not sure how much Google throws at WebKit. Also, do you me currently, or cumulatively?

If you measure by number of commits (whatever that's worth), data is at http://neugierig.org/software/chromium/notes/2010/02/webkit-...

So the answers for "currently" and "cumulatively" differ at least by this metric. And the metric itself is questionable, as the blog post says.

Just curious, is source code for Webkit used in Honeycomb available?

Yes. While Google hasn't open sourced much of the Apache licensed bits of Honeycomb, they have posted all of the GPL/LGPL code as required by the licenses:

http://groups.google.com/group/android-building/browse_threa...

If you take license violations very seriously, then I imagine that an audit of your computer would reveal no movies, songs, fonts, or applications that are not properly licensed, right?

Is Apple out of compliance with the license? Perhaps. Is this on my list of the ten thousand things I'm most concerned about? No.

And as for your assertion about Microsoft suing Apple in a heartbeat over a similar compliance issue, I think you don't know what you're talking about. Microsoft, to the best of my knowledge, hasn't sued anyone over the hundreds of MS patents they claim Linux violates. It took Apple a few years to get around to suing Samsung.

In other words, Companies' legal teams are usually subject to adult supervision by their CxOs. They don't just go around suing willy-nilly. Many lawyers see conflicts that lead to lawsuits as failures.

Reality is so surprisingly messy.

If an audit of his computer revealed unlicensed movies, songs, fonts and applications, I (and probably he) would fully expect him to be litigated against -- such discoveries and resulting lawsuits are quite commonplace nowadays, it seems like. That doesn't make it right for anyone, even a large corporation, to violate intellectual property law.

To put another way: if I were found to be pirating Mac OS X, Apple would be in the right to sue me for intellectual property violation. If I found them to be using my code outside of the license I provided it to them (and the rest of the world) with, I should be in the right to sue them for intellectual property violation. Is this not correct?

(EDIT: fixed problematic grammar)

Microsoft sued TomTom in 2009 for patent infringement[1]. One aspect of the suit concerned infringement in the implementation of the FAT filesystem in TomTom's Linux-based GPS navigation devices.

The two parties eventually settled[2].

[1] http://arstechnica.com/microsoft/news/2009/02/microsoft-sues...

[2] http://arstechnica.com/microsoft/news/2009/03/microsoft-and-...

Actually no, under the GPL they don't have to put the source code on the web. They just have to make it accessible when you request it. If no one requests it then they really don't have to put anything on the web. From a community karma perspective it is good to put up the source when new binaries go out.

Slightly wrong, when distributing the binaries you either have to:

     (a) distribute the source code immediately, 
         along with the binary
     (b) provide a written offer in which you promise 
         to distribute the source-code to anyone 
         who asks in a timely manner

(b) is important because if you fail to provide that written offer as soon as you start distributing the binary, then you're not complying with the GPL.

I'm not in the know if Apple provided such offer, HTC on the other hand ...

And I'm pretty sure somebody requested it by now -- it's not like they are the only contributers to WebKit that would want to merge Apple's changes in master.

In the case of a lawsuit you also have to explain what took you so long to release the source-code -- timely manner is very relative, and in software when things move so fast a couple of months is not soon enough.

I do feel that Apple is somewhat morally justified and should be granted benefit of the doubt, in this particular case, since they invested in WebKit so much. But WebKit got so valuable precisely because it is open-source such that it can be a defacto standard for mobiles. Apple is also not the sole contributer, and they benefited from the work of others, so I don't see why they aren't playing nice.

Also, lots of double standards floating around -- I'm seeing some people that cried wolf on Google's actions regarding postponing the release of Android 3.0, although they are complying with the licenses involved and although they had perfectly understandable business reasons for doing so -- those people are actually trying to justify Apple's actions right now.

I don't know why we treat these stories like some kind of sport, in which everyone cheers for their favorite, but we do, although there isn't anything to gain unless you're a shareholder.

I'm not in the know if Apple provided such offer

They do. In settings, General -> Legal one finds:

The WebKit, WebCore and JavaScriptCore software is open source software [...] You may obtain a complete machine-readable copy of the source code for the LGPL-licensed portions under the terms of LGPL, without charge except for the cost of media, shipping, and handling, upon written request to Apple.

Reply on news.ycombinator.com