Re: Interesting discussion on gcc about objc

[David Chisnall]

On 13 Sep 2010, at 22:42, Nicola Pero wrote:

> I'm sure David will state his position.  He'll probably say that he's 
> replaced most libobjc code,
> so the current code is mostly his and he can pick the license he wants.  I 
> have no idea of the
> legal validity of that assertion.  You should ask a lawyer.  I'm not a lawyer 
> so I'm not sure
> why you want me in this discussion.  The FSF have lawyers, and GNUstep is an 
> FSF project, 
> so you could ask them.

The GPL applies in two cases:

1) If your code is a derived work of GPL'd code, it must be GPL'd.
2) If it is not, but is distributed linked (or in some similar way closely 
tied) to GPL'd code, it must be GPL'd.

2 Initially applied to libobjc2 as a whole, because, as the commit log says, it 
contained code from GCC libobjc, libobjc_tr (the Étoilé runtime, which I 
wrote), and ObjectiveC2.framework (the Apple runtime API compatibility layer, 
which I wrote, with later contributions from others).  1 applied to those 
individual files, because they came from GCC libobjc.

Since then, every file from GCC libobjc has been replaced with a new file (or 
files) implementing similar functionality.  In some cases, these implement the 
same APIs (not covered by the GPL, as you can not copyright an interface), but 
in most they implement similar, but distinct APIs and - where required for 
GNUstep to work - wrap these in the GCC libobjc APIs (e.g. sel_get_name() 
wrapping sel_getName()).

The biggest parts of an ObjC runtime library are the selector-to-method 
mapping, the selector uniquing, and the introspection metadata handling.  All 
of these are implemented in quite different ways to the GCC runtime.  For 
example, there are two implementations of selector-to-method mapping in 
libobjc2.  One comes from the Étoilé runtime, using a denser sparse array 
implementation than the GCC runtime, and the other uses a NeXT-inspired 
approach of a small cache + linear search, for situations where low memory 
usage is more important than speed (although the Self-style IMP caching stuff 
that we can now do in the compiler can make the speed loss very small).  It 
uses hopscotch hash tables for all of the internal tables (I can't remember 
what the GCC runtime uses - some other form of hash table, I think, but 
possibly linked lists in a couple of cases).  

In terms of ABI support, libobjc2 includes support for two, compatible, ABIs.  
One is backwards-compatible with the GCC runtime, the other provides support 
for Objective-C 2 features, as well as some changes to support newer usage 
patterns.  For example, libobjc2 with the new ABI uses a method lookup function 
that is based on the Étoilé runtime, and allows us to implement 
-forwardingTargetForSelector: very efficiently (similar cost to two message 
sends, rather than to about 300 if you have to go via -forwardInvocation: - 
although that's also cheaper with libobjc2 because the new message lookup 
function also returns the type encoding, making -methodSignatureForSelector: 
much cheaper).

The point of this long explanation is to illustrate that libobjc2 is not more 
than superficially similar to GCC libobjc.  For backwards compatibility, it 
provides support for the GCC ABI, but internally it works in a very different 
way.

libobjc2 is developed in GNUstep svn, so I consider it to be part of the GNU 
project and, with the exception of one file that is owned by PathScale (who 
funded its development, although for their C++ runtime, and kindly allowed me 
to license it under the MIT license) and two that were contributed by Remy 
Demarest to Étoilé (under the MIT license), is owned by the FSF due to my 
copyright assignment.  

As it's an FSF project, they are perfectly at liberty to decide that the 
license should change, however that would cause me to simply take the last MIT 
licensed version, continue to develop it in Étoilé svn, and let someone else 
back-port the changes.  

Or, if they decided that using lawyers to prevent me from distributing it under 
a Free Software license was a sensible thing to do (I am confident that I would 
be legally in the right, but I could probably not afford to go to court over 
the matter, so I would have to cease and desist if so instructed), then I would 
start again from the Étoilé runtime and ObjectiveC2 framework and write a third 
runtime library, implementing libobjc2's ABI (the third one should be easy, and 
since libobjc is under 8,000 lines of code, about half of which come from 
Étoilé, should be quite quick...).

Given that the FSF's stated mission is to promote Free Software, this doesn't 
seem like it is very likely.  I believe that continuing to distribute it under 
the MIT license is the best way of achieving this goal for three reasons:

1) It encourages adoption.  FreeBSD, for example, will use clang as the system 
compiler in the next major release and will not ship GPLv3 code.  GPLv3 has a 
clearer runtime exemption, so the GPLv2 version is of no use to them.  They 
will either ship libobjc2 or no Objective-C runtime.  I would rather they 
shipped libobjc2.

2) It is a relatively small project.  GCC libobjc is about 13KLoC.  libobjc2 is 
just under 8KLoC.  A competent developer could probably re-implement it in 
under a week from the public documentation.  The less permissive the license, 
the more likely this is.  Reimplementing a project the size of GCC to get 
around the GPL is a massive undertaking and not commercially viable for most 
people.  Reimplementing libobjc2 to get around the license is trivial.  By 
using a license that places no restrictions beyond attribution, we encourage 
people to use it and (hopefully) contribute back - if they don't contribute 
back, we've lost nothing, if they do, then we've gained something.  

3) An Objective-C runtime library is largely useless, and libobjc2 is designed 
to be used in conjunction with something that implements the Foundation 
framework (well, it's designed to be used with GNUstep, but it can be used with 
something like GNUstep).  Using libobjc2 encourages you to use GNUstep, which 
is LGPL'd and so works as a gateway drug for an FSF-licensed project.  

If someone at the FSF disagrees with this, the I'd be happy to discuss the 
matter off-list.  Beyond that, as I've already said off-list to Nicola, my 
offer to work with anyone from GCC on supporting the new ABI is still open, and 
I look forward to working with Nicola to ensure that we have two (at least!) 
high-quality Objective-C compilers to choose from.  

Being dependent on GCC was a problem for GNUstep while GCC failed to support 
newer language features.  Being dependent on clang could, potentially, 
introduce the same problems.  Having both clang and gcc support all of the 
features that we want puts us in a much stronger position and lets us pick 
whichever compiler has a better optimiser this week.

David