Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
On Thu, 23 Apr 2009 at 21:11:13 +0100, Robert McQueen wrote:
dbus-python has had to duplicate a lot of the checking that libdbus does
to validate calls before calling methods in libdbus, because whilst
libdbus requires the application programmer gets stuff right at all
times, dbus-python can be tricked by the python programmer into causing
libdbus to abort. These checks are not in general exported as public
API, and even with many checks in the Python code, its still possible
for the Python programmer to assert libdbus from Python code in various
corner cases.
Various libdbus functions will (default-fatally) warn if you pass them an
invalid object path or bus name, but libdbus doesn't give you a way to check
whether a Python-programmer-supplied string is a valid object path. Yes, this
is programmer error, but it's programmer error that, in Python, should be
reported in the Python way, by raising ValueError.
In both dbus-python and telepathy-glib, I've ended up implementing a set of
functions that raise an appropriate language-specific exception (an Exception
or GError respectively) if an object path/bus name/error name is bad. I'd be
happy to place either of these under the MIT/X11 license proposed for libdbus
(indeed, the Python one is already under that license) if anyone is interested
in porting them to raise DBusError.
On the other hand, because of libdbus' privileged roles as the implementation
of dbus-daemon and a library from the dbus-daemon source package,
having a hard dependency on a newer libdbus is not necessarily a decision to
be taken lightly. Backporting a mere library like dbus-glib or dbus-python
is easy, but backporting dbus-daemon to an older distribution is less popular.
If nothing else, because (as its maintainers are so keen to remind us) the
system bus is a Critical System Service, correctly installing a new
dbus-daemon requires either a reboot, or a risky and discouraged system bus
restart, neither of which is a desirable action.
There are silly cases like half way through packing a struct where the
application has provided the D-Bus type, but later a value that doesn't
fit that type. You can't close the struct because you'll abort libdbus.
Unless you implement two-pass validation and check the types before
building the message, there's no way out of this other than to fill the
struct with nonsenense, /then/ close the iter, /then/ discard the
message. If it was Python code you could just throw an exception back to
the app author and get on with life.
dbus-python does suffer from this. It does throw exceptions wherever needed,
but I haven't had the spare time to implement either two-pass validation or
the fill the struct with zeroes unwinding, meaning that passing {'foo': None}
to a D-Bus method that takes an a{sv} or a{ss} will either warn to stderr then
throw an appropriate exception anyway (in Debian-derived distros where
libdbus has been patched to have non-fatal warnings by default), or just abort
(in e.g. Fedora).
Further to this, the OOM stuff is simply not of interest to (m)any other
apps other than the daemon and the X server, and indeed if you write a
D-Bus implementation in your native language/VM/style then you almost
certainly get this for free, rather than wiring it up every other line
of code.
Right, in GLib you conventionally just abort on OOM, and in Python you raise
MemoryError (which is easier than it sounds, because in the CPython API,
basically anything is allowed to raise an exception - so CPython programmers
already have to deal with them - and in Python, exceptions are syntactically
special in the expected way).
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.
dbus-python has a branch called 'purity' (as in pure Python) which I've never
dared to merge; it stops using libdbus' object-path-registration mechanism
entirely, and catches method calls by using a filter instead. This was, perhaps
unexpectedly, a significant code reduction, because I no longer had to keep
a separate registry of objects in dbus-python (in order to be able to raise an
exception on double-registration rather than letting libdbus abort me).
(It also fixed an isolated piece of OOM misbehaviour in which dbus-python would
exacerbate an OOM at precisely the wrong time by leaking a string, because
there was nothing else I could safely do; see the source code if interested.)
If I'd had time to continue on that path, the next step was going to be to use
dbus_message_[un]marshal() to get the binary blob containing the message
payload and parse it into Python data structures myself rather than using
DBusMessageIter, which I
Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
Hi, On Fri, Apr 24, 2009 at 6:56 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: As mentioned above, dropping my use of libdbus' helpful object path mapping and just using a filter function was a net code reduction. Getting pretty off-topic, but the object path mapping in DBusConnection isn't intended to be a convenience/helpful thing. The purpose of it is to ensure that introspection includes objects registered by all bindings in the process. So say for example gvfs exports an object, or libunique exports an object; and then some python code exports an object; Introspect() needs to merge all those nodes and return a single list of nodes. The other possible solution is that every binding has its own private socket (appears to be a separate app on the bus), which is kind of fine, but a little bloated/weird. With a private DBusConnection there is no real reason to use the object path registration. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
Havoc Pennington wrote: Hi, On Thu, Apr 23, 2009 at 1:24 PM, Robert McQueen robert.mcqu...@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). 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. 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. In the case of EggDBus (or telepathy-glib), the library is rendered totally useless by the lack of libdbus, so I think this doesn't count. So - if you're linking libdbus into Glib and distributing the result as LGPL, you could be violating the GPL-incompatible terms of the AFL which require additional actions that the LGPL does not. It's not open and shut by any stretch of the imagination, and furthermore I'm not even certain that this is even the line of reasoning behind our clients' concerns. However, I'm not a lawyer, but have definitely have come across clients (who have presumably asked their lawyers) who have decided this combination of LGPL + GPL/AFL is unsound. Hence I'd like to better understand their rationale and check with our own lawyers before dismissing it. 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. Yeah, that's why I said it was a handwave in the context. :) * 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. 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) 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. If it proves necessary, I think we'll try and do this. In the case of dbus-glib and the daemon itself, there's quite a lot of code there, but in the restricted case of libdbus (assuming EggDBus) it seems more tractable. We can just port telepathy-glib to sit atop EggDBus then (hopefully very thinly), and be shot of the problem after an ABI bump. (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. stop reading here if you just care about the legal issue This /is/ a big tangent. :) I'll bite and try and give you a little more understanding based on the past few years at Collabora, but don't be too offended if I'm not able to reply much beyond this, as I'm pretty busy at the moment. 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
Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
On Thu, Apr 23, 2009 at 6:24 PM, Robert McQueen robert.mcqu...@collabora.co.uk wrote: Havoc Pennington wrote: 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. IANAL etc. This issue was once described to me having to involve multiple applications linking to libdbus: * (L)GPL application is incompatible with AFL so libdbus falls under GPL (as does the application) * proprietary application is incompatible with GPL so libdbus falls under AFL Now as long as you're not mixing (L)GPL and proprietary applications all is fine. However once you mix both you get a system where dbus license can't satisfy both cases. The argument being that dbus as distributed/running on a system can have only one license, not GPL when used from app A, but AFL when the same library/daemon is used from app B Then again, the system library exception would allow dbus to be AFL while remaining (L)GPL compatible. -- Tommi Komulainen tommi.komulai...@iki.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
