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

[Havoc Pennington]

Hi,

On Thu, Apr 23, 2009 at 1:24 PM, Robert McQueen
<robert.mcqueen at collabora.co.uk> wrote:
> 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.

This doesn't make much sense to me (the whole point of LGPL over GPL
is that there isn't a compatibility thing; LGPL should not
"contaminate" and require AFL to change).

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

Not sure system library is handwavy... the GPL is (relatively) clear
on the system library point. However, the problem with system library
exception is the text "unless that component itself accompanies the
executable" i.e. it can't be used by someone shipping both the app and
the library.

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

Certainly seems sensible to ask what people are worried about. Note,
there was a lot of uproar about AFL 1.0 patent clause, but we aren't
using that, this is AFL 2.1. I don't think AFL 2.1 requires anything
more than LGPL/GPL, with respect to patents. And I think AFL phrases
the requirements in a clearer way than LGPL/GPL.

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

Certainly open to this, if anyone wants to invest the effort.

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

Not to go on a tangent, but I think there's real value to a shared
"least common denominator" implementation of dbus.

One of the big reasons is precisely the protocol extensions people are
talking about. e.g. the "protocol v2" work in gbus/gvariant; it's
great and all, but basically useless because dbus-daemon does not
speak this new protocol v2. To make it useful someone has to extend
libdbus to speak v2 anyway, and then what was the value of creating a
non-libdbus implementation?

Most of the objections to libdbus seem to be around how it's low-level
and least-common-denominator, which makes it sort of annoying, but,
that was the whole intentional tradeoff when writing libdbus, and I'm
not sure people are considering the _value_ of being able to change
one implementation and suddenly have a new auth mechanism or new
protocol feature that _everything_ (all apps, all desktops, bus
daemon, etc.) has support for...

Switching dbus-daemon away from libdbus seems like a pipe dream at
best, and deprecating libdbus is a herculean task, and I just am not
sure people are thinking pragmatically and realistically on this
subject.

To add a Windows transport or SASL authentication or protocol v2 do we
really want to run around having to fix the Python implementation, the
Qt implementation, the GLib implementation, etc.? The pain seems
mildly worth it with the managed languages (C#/Java) but largely pure
pain for the other languages that rely on C modules anyway.

Not to mention that libdbus and dbus-daemon are quite well tested,
with probably the highest unit test coverage of any library in the
open source desktop stack that I can think of, and years of real-world
testing. This is not a benefit to sneeze at.

Havoc