Apple's Selective Contributions to GCC [LWN.net] (original) (raw)

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please considersigning up for a subscription and helping to keep LWN publishing.

Recent discussions on the GCC mailing list have made it clear that Apple won't be assigning copyright to the FSF on its work porting Objective-C 2.0 support to GCC compiler. Apple has published its changes, but has not assigned copyright to the Free Software Foundation (FSF) or pushed its changes to the FSF server for some of its work. We may be seeing the next steps in Apple's apparent plan to move away from GCC and GPLv3-licensed software in general.

Apple has clearly been working to reduce its dependency on GCC. The company has been sponsoring work on clang, a front-end for the LLVM Compiler Infrastructure that supports (at the moment) C, C++, Objective C and Objective C++. The developer preview of Xcode 4.0 seems to replace GCC with LLVM and clang.

At one time, Apple was content to build on GCC for its developer tools and assign copyright to the FSF. What has changed? Apple's use of GCC for Mac OS X was compatible with the GNU GPLv2, even if the company didn't have any particular love of the FSF's principles.

The launch of the iPhone and GPLv3, just a few hours apart, put Apple at odds with the GNU Project. The FSF has notedthat the GPLv3 and iPhone are incompatible. Specifically, the requirement for apps to be signed to run on the iPhone runs counter to section 6 of the GPLv3, which says that signing measures cannot prevent apps from running on a device merely because they've been modified. The FSF has also been openly hostile to Apple's iPad launch and App Storeas of late. Justifiably so, perhaps, but it's still not the sort of behavior that will encourage Apple to be any more cooperative than it has to.

It would appear that Apple is being exactly as cooperative as it has to. The code is being published under the appropriate license - GPLv2 or later - but Apple isn't taking the next steps of pushing its changes to the FSF or assigning copyright as required to be shipped as part of an GNU project like GCC.

In theory, the GCC project could pluck the changes out of Apple's sources and integrate them into GCC, but Apple employee and primary author of LLVM Chris Lattner notes that this would go against the FSF policy of requiring copyright assignment:

Be aware that none of the changes that haven't been committed to the FSF trees are copyright-assigned to the FSF. In practice, since the FSF cares about copyright assignment, this probably means that you can probably merge whatever is in the apple branch on the FSF server, but you can't take things out of llvm-gcc or the apple gcc tarballs that get pushed out on opendarwin.

I'm not a lawyer, so this isn't legal advice, just my understanding of FSF policies and the mechanics of how the copyright transfer works.

Richard Guenther points out that some code in the GCC test suites is not FSF-owned, and that GCC/GJC uses libffi, which has Red Hat as the copyright owner. Guenther suggests that the steering committee be asked for an exception to merge the Apple-owned code. This is not, however, an apples to apples comparison. Steven Bosscher notes that the test suites and runtime libraries are not part of the compiler itself, and that the policy has been different for non-compiler components. Further, he says that the "risk of 'leakage'... would be too big", to merit inclusion.

And is it really worth the effort anyway? It may be irritating to some developers that Apple will not assign copyright for its contributions to a project that it benefits from, but is it really a major loss for the GCC project? Bosscher suggests that it is not, saying that it may hurt the project more than it helps. "GNU ObjC has so few users that it seems hardly worth the effort to upgrade the GNU ObjC front end to ObjC 2.0." He also points out that Objective-C 2.0 is not a documented language standard, and that Apple's branches may not be the current Objective-C 2.0 that Apple is shipping. Even if the GCC project were to merge the code, it would likely be out of step with the most popular Objective-C 2.0 implementation and would be chasing a small audience that may not be very interested.

The final word seems to be that Apple has no interest in contributing the Objective-C changes back to GCC. When asked about a contact at Apple to discuss assigning copyright to the FSF, Lattner responds that "Apple does not have an internal process to assign code to the FSF anymore. I would focus on the code that is already assigned to the FSF."

Whether that can be construed as "blocking" contributions to GCC is another question. Apple's motives may not be pure, but it has published the code under the license required and it's the FSF's own copyright assignment policies that block the inclusion. The code is available and licensed appropriately for the version of GCC that Apple adopted. It might be nice if Apple took the further step of assigning copyright to the FSF, but the GPLv3 was not part of the bargain that Apple agreed to when it first started contributing to GCC.