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

[Havoc Pennington]

Hi,

On Thu, Apr 23, 2009 at 4:11 PM, Robert McQueen
<robert.mcqueen at collabora.co.uk> wrote:
> The LGPL makes a clear distinction for a "work that uses the Library"
> and allows all manner of things which the GPL does not. Other than that,
> the terms of the LGPL are broadly similar to those of the GPL. In the
> case of an LGPL library that relies on libdbus to do its job, libdbus is
> definitely /not/ a work that uses the library.

I see where there could be an issue here, though I'm reading LGPL and
as usual discovering that it's the vaguest most obfuscated license on
earth.
In LGPL 2.1, section 2 would raise the problem you're talking about
here, but section 7 may mitigate it. Not clear to me. I think the same
situation of "possible LGPL-incompatibility" probably exists in
various other cases on most Linux distributions ... don't think this
is something people normally think to avoid. Anyway yes, we should try
to unpack this.

> In their definition of a derivative work, they say that you are allowed
> to rely on external functions or lookup tables, but that if they are
> missing, the library must still operate and its purpose remain
> meaningful.

That part is trying to avoid a case where an LGPL library is modified
to require some big blob of proprietary stuff provided by the app...
which is not really much like our case, arguably what we're doing is
more that the app links to an LGPL library, and also links to another
non-LGPL library. (Especially if EggDBus itself were licensed to
explicitly allow libdbus linking.) However I think I'd need to read
and think for a while before feeling like I knew the answer.

First question in my mind is basically, how will
libdbus-used-from-gbus-in-glib be different from
libdbus-as-currently-used-from-dbus-glib-using-apps.

> Hence I'd like to better
> understand their rationale and check with our own lawyers before
> dismissing it.

That definitely seems wise. I would not agree that any objection from
any lawyer anywhere should hold us up, but if clueful ones with the
right motives in mind see an issue, we should pay attention to that.
We need to understand the issue though.

> The AFL (all versions through v3.0) is incompatible with the GPL
> according to the FSF due to requiring distributors to seek the assent of
> the recipient:
> http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses
> http://opensource.org/licenses/academic.php (clause 9)

I guess the issue here is that the text "a reasonable effort under the
circumstances" is too vague. I would imagine (and most people
distributing libdbus seem to imagine) that it does not require a
click-through on a file server, since everyone is proceeding along
providing libdbus on file servers. Certainly I think that is the
intent of both the copyright owners and the license, that in the
circumstances of a file server, a click through is not reasonable. But
I agree it would be better if we didn't have to interpret "reasonable
effort under the circumstances."

> Protocol versions aside, I believe Ryan wished to propose new types, and
> nobody has really worked out how you're meant to achieve this. Even
> given a bus daemon which can speak two versions of the protocol and
> convert between them, we'd need to do some kind of pairwise capability
> negotiation.

I think it could be OK here with the right bus smarts:
 * bus could convert "v1 compatible" v2 messages (no v2 types) for the
benefit of v1 clients
 * if you tried to send a "v1 incompatible" message to a v1 client,
bus would return you an error reply

But definitely a lot of work. Evolving the protocol just _is_ a lot of
work, I think is the bottom line.

> However, in the case of a binding, the binding is forced to do a lot of
> ahead-of-time checking to make sure the application hasn't screwed up,
> and then report the error in the appropriate way for that language. In
> general that isn't abort(), and nor is the Java/C#/Python/Vala/etc
> author going to know what to do with that error anyway. Strictly
> speaking this is a binding bug, but it's one that libdbus makes it
> really hard to avoid.

In the glib/gtk context, of course, the whole glib/gtk stack have this
same policy and behavior...

I'd say the solution is to just have a little wrapper that prechecks args.
Proposed here for example:
http://lists.freedesktop.org/archives/dbus/2007-October/008677.html

Simple enough, and avoids making the C API even more confusing.
(Avoids leaving it unclear when an error in fact needs handling.)

> Most bindings /except/ dbus-glib are forced to not use the shared
> connection for similar reasons, because if you try and register the same
> object path component from two bindings you just get aborted, so it's
> not trivial to co-habit two service-exporting bindings on the same
> libdbus.

I thought this was fixed:

2007-10-10  Simon McVittie  <simon.mcvittie at collabora.co.uk>

        * dbus/dbus-errors.c, dbus/dbus-protocol.h: Add new error
        org.freedesktop.DBus.Error.ObjectPathInUse
        * dbus/dbus-object-tree.h, dbus/dbus-object-tree.c,
        dbus/dbus-connection.c, dbus/dbus-connection.h: add new functions
        dbus_connection_try_register_object_path and
        dbus_connection_try_register_fallback, which raise ObjectPathInUse
        rather than asserting, to make object path registration less painful
        for bindings

> Further to this, the OOM stuff is simply not of interest to (m)any other
> apps other than the daemon

I certainly agree with that, but it's just the price of sharing the
implementation with the daemon. (Which I think is very valuable.)

> It seems that if you're not using libdbus directly, or you're not the
> bus daemon, its a pretty hostile library to write bindings with,
> especially if the language is dynamically typed. People hacking on both
> bindings at Collabora have lost hair and screamed and sworn they would
> rewrite them to not use libdbus given half a chance, and I honestly
> don't think we're alone in this sentiment.

I'm not saying it isn't kind of annoying. I just think you aren't
considering just how hard it would be (and how many downsides there
would be) to actually not using libdbus.

Basically it's very clearly far less work (overall, for a whole Linux
distribution with Qt, GLib, Python, dbus-daemon, plain C programs,
etc.) to fix up the libdbus issues, than to try to drop libdbus.

Reimplementing libdbus may be more *fun*, but it just _isn't_ less
work, overall. The 3 problems you mention are inconvenient or annoying
at most, solving them should be a tiny fraction of the overall work to
reimplement libdbus, port the daemon, and port all the apps.

> Sure, in general I think we're stuck with it for stuff that currently
> uses it, but the wire protocol is small, so the effort of writing a
> library that speaks/parses the protocol is really quite small.

Reimplementing the client side of the protocol I agree is not that
hard, which is why people have done it.

The extra work I think is in two cases:
1)  whenever you want to add any features: auth mechanisms;
transports; protocol extensions; selinux support; ports to Windows;
autolaunch; etc. These are all real feature examples that have been or
are being added. Now you have to do N-times the work to add any of
those.

Say we did feature negotiation to allow protocol v2; this is fairly
tractable to do in libdbus, but a total nightmare if we had several
more reimplementations!

2) if your goal is to remove libdbus from the system entirely, you
have a lot more work than people have been doing for the
reimplementations

As you go on to say, nobody is really adding tons of new features
these days anyway, but I do think there are lots of things that could
be added (SASL, X11 transport, Windows port, protocol extensions) that
would be nice.

Not sure we disagree that fundamentally. I generally agree that it's
not _that_ big a deal if people want to do their own dbus client
library, but I do think if the ambition is to stop using libdbus
anywhere on the system, it's sort of a fantasy that would take a
decade (or, a lot of work and money to speed up). And as long as
libdbus isn't removed entirely, every feature that you want to use
(new auth mechanism, new transport, new protocol) has to be
implemented in libdbus anyhow. So at that point, reimplementation is
not a solution to very many problems. And in some ways having other
implementations is bloat, since the system will have libdbus on there
anyway.

It just kinda feels like people have this "maybe libdbus will go away"
kind of hope, that's keeping them from improving the code that's
there. But I don't think it's a very realistic hope if you start
looking at it from the perspective of here's a whole Linux OS, now I
have to get it working sans libdbus without regressions. And if you
start looking at the highest-value work that could be invested in such
an OS.

Havoc