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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
