D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)

[Robert McQueen <robert mcqueen collabora co uk>]

Havoc Pennington wrote:
> Hi,

Hi Havoc,

> Just for the record, my comment on this has always been that the
> license issues were not earth-shattering to begin with, and the
> relicensing was just throwing a bone to people who cared. Not sure
> "large chunk" is super accurate, either. As a practical matter this
> topic is highly overblown.
> 
> Nobody has yet explained (to my satisfaction anyway) how the libdbus
> license has an issue the LGPL does not have. Perhaps we should get
> Luis or SFLC on the case, but I'm not sure it's worth their time.

My belief is that the problem is that under certain implementations of
LGPL, the stuff you link the LGPL library to must also be LGPL
compatible, and that the AFL patent clause is not. The alternative
interpretation is therefore that you make your LGPL code GPL, and take
libdbus under the GPL, but this is unacceptable for a proprietary
application which cannot link GPL libraries.

Yes, this is handwavy and I'm not sure what I'm talking about, but I'm
sure of one thing: I have run into clients who due to this issue have
either a) applied a handwavy "system library" defence for this problem,
b) adjusted their software architecture to have a GPL isolation daemon
with an additional IPC hop, or c) refused to consider our software
(Telepathy) for this reason.

So this possibly overblown / hypothetical legal issue is still a genuine
cause for concern (and hence time/effort/money/perceived risk) for our
clients, and therefore a concrete commercial issue for Collabora, hence
my reluctance to just handwave it away like you if we're pushing it into
Glib itself.

I'd like to see it sorted out, so I'm doing the following:
 * seeking legal advice from Collabora's advisors on whether the above
   is a genuine issue, or what other concerns might be
 * endeavouring to find out from our would-be clients above what their
   specific concern was
 * trying to track down the Codefactory code (again) so we can actually
   complete the license change and move on with our lives

> http://log.ometer.com/2007-07.html#17.2
<snip>
> btw, I believe we were going to add a notice to COPYING in libdbus to
> the effect of "all new code is also MIT/X11, and most code is MIT/X11,
> but a few bits are GPL/AFL" so that new contributions are MIT/X11 and
> we don't have to redo the relicensing mass email if we ever solve the
> codefactory code. It doesn't look like this has been done, however.

I'd appreciate if this could be done (if it hasn't already). Meanwhile,
I'm going to try again to track down the Codefactory stuff, and ideally
we can relicense it and be done with the whole issue. If anyone has any
information they believe would be helpful for my quest, I'd appreciate
that too.

Pending the outcome of my enquiries, if if *is* a real concern, and
we're unable to find where the Codefactory stuff really resides, I'd
much rather get someone at Collabora to rewrite the code than handwave
and pretend its fine. (Its not an unthinkable amount of code, though of
course if the effort to rewrite it is more than the effort to port
EggDBus to GVariant/GBus, that might make more sense anyway. Although
now Qt is LGPL rather than GPL+proprietary, they now have the same
potential issue.)