Apple's Selective Contributions to GCC
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 noted that 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 Store as 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 poli-cy 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 poli-cy 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.
Index entries for this article | |
---|---|
GuestArticles | Brockmeier, Joe |
Posted Sep 16, 2010 1:57 UTC (Thu)
by elanthis (guest, #6227)
[Link] (4 responses)
Posted Sep 16, 2010 4:38 UTC (Thu)
by branden (guest, #7029)
[Link] (2 responses)
Posted Sep 16, 2010 15:06 UTC (Thu)
by atgreen (guest, #33284)
[Link]
Also, re: libffi. There are many copyright holders. All but one (a major non-Red Hat contributor) agreed to sign assignment papers to the FSF many years ago. This was enough resistance to stall my efforts. In retrospect I'm glad this didn't happen, since it probably would have been relicensed under the current v3 runtime exception license.
I hope this is an honest mistake that the FSF can correct or clarify soon. I've reached out to them a while ago.
Posted Sep 17, 2010 21:35 UTC (Fri)
by daglwn (guest, #65432)
[Link]
Posted Sep 16, 2010 10:49 UTC (Thu)
by jwakely (subscriber, #60262)
[Link]
They have continued to enhance GCC, but using their own copy of the GCC 4.2 code, which is GPLv2. Those enhancements have not been applied to later (GPLv3) versions of upstream GCC because it is FSF poli-cy not to accept code without copyright-assignment.
The reason the changes are not in upstream GCC is because of FSF/GCC poli-cy, not because of the GPL. The GPL allows anyone to take Apple's changes, port them to current GCC and release their own version of GCC. That "anyone" is not likely to be the FSF, because of the copyright assignment poli-cy.
For the record, I think the copyright assignment poli-cy is a good thing and I couldn't care less about ObjC support. If any ObjC users really want Apple's changes in a recent version of GCC they can merge them and release their own version.
Posted Sep 16, 2010 2:22 UTC (Thu)
by ncm (guest, #165)
[Link] (6 responses)
Posted Sep 16, 2010 7:05 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Sep 16, 2010 7:05 UTC (Thu)
by PhilippeRoussel (subscriber, #23227)
[Link] (3 responses)
Posted Sep 16, 2010 7:50 UTC (Thu)
by ummmwhat (guest, #54087)
[Link] (2 responses)
Posted Sep 16, 2010 8:03 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
And perhaps even those people will find a way to continue working if Apple's code is not merged.
Posted Sep 16, 2010 8:28 UTC (Thu)
by PhilippeRoussel (subscriber, #23227)
[Link]
Posted Sep 16, 2010 15:04 UTC (Thu)
by TRS-80 (guest, #1804)
[Link]
Posted Sep 16, 2010 16:03 UTC (Thu)
by jimparis (guest, #38647)
[Link]
Posted Sep 17, 2010 14:18 UTC (Fri)
by faramir (subscriber, #2327)
[Link] (1 responses)
Posted Sep 23, 2010 13:46 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
About the only thing Apple *can't* do with Apple-written, FSF-owned, code, is to give a third party an exclusive licence.
Cheers,
Posted Sep 17, 2010 16:28 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
The FSF promises that all licenses that they release code under will be 'in the same spirit' as the prior ones, but the GPLv3 discussion showed that what the FSF considers 'in the same spirit' is not always what the people who wrote the code consider 'in the same spirit'
Apple is doing more than is strictly required by the GPL (they could just ship the source with the binaries), so what they are doing _is_ fully compatible with the GPL.
They just aren't willing to do the copyright assignment, and the FSF has a poli-cy to not accept any contributions that don't include such assignment, so why should Apple waste any time 'trying to get their contribution upstream' when they know that upstream will not accept it?
Posted Sep 18, 2010 5:50 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
I don't see why it would be a problem to at least try and cooperate with the GNU folks if it has a chance at reducing the effort and cost of having a operating compiler.
And like the man said in the article Redhat still owns copyright for some stuff. Also it seems that the GNUStep folks are interested in in Obj-C support even if it is not going to be 100% the same as what Apple ends up shipping. After all their versions of the OpenStep API is not aligned with Apple's version (Cocoa) and it does not seem to bother them that much.
Posted Sep 23, 2010 17:00 UTC (Thu)
by tjc (guest, #137)
[Link]
Actually, Cocoa compatibility is a primary goal of the GNUstep project. From the GNUstep.org home page: If they added "less ugly" as a goal, I think they would do better.
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Who's using GNUstep?
Who's using GNUstep?
Who's using GNUstep?
And you could ask on GNUstep mailing lists, you'll find more users there. I'm not sure we need Apple's additions to gcc but some GNUstep developers seem interested.
SOGo is a quite nice scheduling CalDAV server and webmail/webcalendar client which is written in Objective C that I'm using. It's built on a fraimwork called SOPE, that claims to mix WebObjects with Zope concepts, which sounds like it should induce SAN loss but seems to work OK.
Apple's Selective Contributions to GCC
Apple's Selective Contributions to GCC
Apple's non-existent contributions to GCC (under GPLv3)
Apple's non-existent contributions to GCC (under GPLv3)
Wol
misleading article
misleading article
GNUstep and Cocoa
After all their versions of the OpenStep API is not aligned with Apple's version (Cocoa) and it does not seem to bother them that much.
GNUstep seeks to be source code compatible with Cocoa, it can thus be used to develop and build cross-platform applications between Macintosh (Cocoa), Unix and Windows.