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

2009-04-24 Thread Simon McVittie
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)

2009-04-24 Thread Havoc Pennington
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)

2009-04-23 Thread Robert McQueen
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)

2009-04-23 Thread Tommi Komulainen
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