Hacker News Reader

Comment by jpk | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com