[go: up one dir, main page]

LWN.net Logo

Apple's Selective Contributions to GCC

September 15, 2010

This article was contributed by Joe 'Zonker' Brockmeier.

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 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.


(Log in to post comments)

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 1:57 UTC (Thu) by elanthis (subscriber, #6227) [Link]

I'm confused why the GPLv3 has anything to do with this at all. Is it because Apple only stopped playing nice because it refuses to touch GPLv3 code?

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 4:38 UTC (Thu) by branden (guest, #7029) [Link]

Indeed. The author offers us not a single quote supporting the implied notion that Apple's decision constitutes GPLv3 backlash.

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 15:06 UTC (Thu) by atgreen (subscriber, #33284) [Link]

I don't know about Apple's opinion of the GPLv3. My opinion, however, that there's a real problem with GCC's GPLv3 Runtime Library license exception. For instance, does the exception apply to a separate libgcc.so? The FAQ suggests that it should, but try coming to that conclusion from the exception language itself. IANAL, but I believe that this would make it impossible to build many kinds of closed systems with GCC even if there was no other GPL'd code on the box. I know for sure that issues like this are scaring people away from the v3 licensed compiler.

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.

Apple's Selective Contributions to GCC

Posted Sep 17, 2010 21:35 UTC (Fri) by daglwn (subscriber, #65432) [Link]

It's pretty well known. There was a lengthy discussion about it on the LLVM mailing list when the libc++ project was announced. libc++ is a direct reaction to GPL v3.

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 10:49 UTC (Thu) by jwakely (subscriber, #60262) [Link]

Apple stopped contributing changes back to GCC at the time when GCC switched license to GPLv3, many people think the timing is not a coincidence :)

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 policy not to accept code without copyright-assignment.

The reason the changes are not in upstream GCC is because of FSF/GCC policy, 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 policy.

For the record, I think the copyright assignment policy 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.

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 2:22 UTC (Thu) by ncm (subscriber, #165) [Link]

I'm finding it really, really hard to care about whether Apple's ObjC changes end up in FSF's, or anybody's, GCC. Is anything useful written in ObjC that runs on something not Apple? If Apple wants to make it easy for developers to code in ObjC, they know what to do; if they don't care, why should we? This just seems entirely intramural.

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 7:05 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, there's oolite and GNUstep. But not a lot else that I know of.

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 7:05 UTC (Thu) by PhilippeRoussel (subscriber, #23227) [Link]

Well, maybe GNUstep, which is a GNU project, could be considered as useful. And GNUstep runs on a lot of plaforms.

Who's using GNUstep?

Posted Sep 16, 2010 7:50 UTC (Thu) by ummmwhat (guest, #54087) [Link]

Let's be honest here, who's really using GNUstep for day-to-day computer use?

Who's using GNUstep?

Posted Sep 16, 2010 8:03 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> Let's be honest here, who's really using GNUstep for day-to-day computer use?

And perhaps even those people will find a way to continue working if Apple's code is not merged.

Who's using GNUstep?

Posted Sep 16, 2010 8:28 UTC (Thu) by PhilippeRoussel (subscriber, #23227) [Link]

I am !
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.

Apple's Selective Contributions to GCC

Posted Sep 16, 2010 15:04 UTC (Thu) by TRS-80 (subscriber, #1804) [Link]

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 framework 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

Posted Sep 16, 2010 16:03 UTC (Thu) by jimparis (subscriber, #38647) [Link]

I'm not a fan of the copyright assignment policy. It means that someone like me can't take existing compiler ports (for example, Microchip's port of GCC for dsPIC/PIC24 architectures) and start working it into upstream -- I'd need Microchip to assign copyright first and they definitely don't want to do that, because they like having it be a hard-to-build out-of-tree thing that they can turn around and sell.

Apple's non-existent contributions to GCC (under GPLv3)

Posted Sep 17, 2010 14:18 UTC (Fri) by faramir (subscriber, #2327) [Link]

I think Bosscher's suggestion that the shipping ObjC 2.0 binaries may not match the publicly visible sources would be a legally risky action on Apple's part. As I understand it, Apple has assigned copyright to FSF in the past, so there is a good chance that SOME of the code in the 2.0 release is legally owned by the FSF. Apple would be setting themselves up for legal action under GPLv2 requirements. This assumes that I understand how the code has flowed in the past. Hopefully someone closer to the code can correct me if I'm wrong.

Apple's non-existent contributions to GCC (under GPLv3)

Posted Sep 23, 2010 13:46 UTC (Thu) by Wol (guest, #4433) [Link]

But the FSF's copyright assignment is akin to joint copyright. If Apple wrote it and assigned it to the FSF, then Apple can do what they like with it as well.

About the only thing Apple *can't* do with Apple-written, FSF-owned, code, is to give a third party an exclusive licence.

Cheers,
Wol

misleading article

Posted Sep 17, 2010 16:28 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

I think the GPLv3 discussion made a lot of people think twice about copyright assignment. The wikipedia exception also made people think.

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 policy 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?

misleading article

Posted Sep 18, 2010 5:50 UTC (Sat) by drag (subscriber, #31333) [Link]

What I've seen in the past is that GNU project is more flexible then others (like, say, Apache) when it comes to dealing with code licensing issues.

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.

GNUstep and Cocoa

Posted Sep 23, 2010 17:00 UTC (Thu) by tjc (guest, #137) [Link]

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.

Actually, Cocoa compatibility is a primary goal of the GNUstep project. From the GNUstep.org home page:

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.

If they added "less ugly" as a goal, I think they would do better.

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds