GLib plans for the next cycle

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
On Sun, 19 Apr 2009, Havoc Pennington wrote:

> I think my arguments are compelling. If someone else thinks
> differently, they can say so, and explain their reasoning...
>
> The bottom line is that dbus has an MIT/X11-equivalent license, with
> the addition of a *weaker* patent clause than LGPL/GPL already have.
> The license was written by a lawyer and is perfectly sane.

"Sane" and "written by a lawyer" are surely orthogonal to
desirability from the point of view of free software.

Havoc wrote in his blog:

"I believe if you distributed D-Bus under GPL or LGPL, you would
be making a patent grant of any patents affecting D-Bus. The AFL
patent clause does not require you to make a patent grant; it
still allows you to sue. You just have to stop distributing D-Bus
while you do it. With the GPL or LGPL, you can never distribute in
the first place, without giving up the right to sue at all. Unless
I'm missing something, there's no way the AFL patent clause can be
a problem unless LGPL or GPL would be a problem in the same
context."

IANAL, but... Hypothesis: Monster Corp distributes D-BUS under
AFL, while believing that DB in fact violates patents held by
Monster Corp.  MC then sues users of DB.  MC can no longer
distribute DB under AFL, but they don't care!  They have succeeded
in causing trouble.  But as Havoc says, if Monster Corp had
distributed DB under *GPL they would have effectively made a
patent grant and given up the right to sue, making this scenario
impossible.

OK, maybe there's no Monster Corp associated with D-BUS right now,
but we know there _are_ such monsters around.  This seems to me a
_major_ reason to see *GPL as superior to AFL from the p.o.v. of
free software.

Allin Cottrell

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-2
Hi,

On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell <[hidden email]> wrote:
> On Sun, 19 Apr 2009, Havoc Pennington wrote:
>> The license was written by a lawyer and is perfectly sane.
>
> "Sane" and "written by a lawyer" are surely orthogonal to
> desirability from the point of view of free software.

The contrast is with things like the Artistic 1.0 license, which is a
legal mess written by a non-lawyer. That is not desirable because the
license ends up vague (from a legal perspective) and difficult to
enforce in court.

AFL was written by an open source advocate (and lawyer) with input
from a lot of other open source people.

The point is, it's not some off-the-wall license made up over beers.
It was written by someone competent to do so and vetted by quite a few
others. It is an "approved license" on opensource.org.

> IANAL, but... Hypothesis: Monster Corp distributes D-BUS under
> AFL, while believing that DB in fact violates patents held by
> Monster Corp.  MC then sues users of DB.  MC can no longer
> distribute DB under AFL, but they don't care!  They have succeeded
> in causing trouble.  But as Havoc says, if Monster Corp had
> distributed DB under *GPL they would have effectively made a
> patent grant and given up the right to sue, making this scenario
> impossible.

Yes, you're right that the AFL imposes fewer restrictions than GPL,
just as any other MIT/X11 type of license imposes less restrictions
than GPL.

> OK, maybe there's no Monster Corp associated with D-BUS right now,
> but we know there _are_ such monsters around.  This seems to me a
> _major_ reason to see *GPL as superior to AFL from the p.o.v. of
> free software.

The discussion is not about whether AFL (or MIT/X11 type licenses in
general) are superior to GPL-type licenses philosophically. The
discussion is about whether there's a licensing "problem" with libdbus
that keeps GLib and GTK+ from relying on it. Last I checked, GTK+ at
least linked to quite a bit of code under MIT/X11 sort of licenses,
such as libX11.

You aren't saying anything here that doesn't also apply to libX11.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
In reply to this post by Allin Cottrell
On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote:

> On Mon, 20 Apr 2009, Alexander Larsson wrote:
>
> > gvfs needs a session bus, not a system bus, so you're falling back to a
> > non-gvfs system. Thus no http support.
>
> OK, I suppose I can get this working on my own system, but my main
> point is: why does GTK include a function such as gtk_show_uri
> which depends on a big stack of unspecified stuff?  At least this
> should be mentioned in the documentation.  As I said before, up
> till very recently one has been able to rely on GTK functions
> "just working" so long as the compile-time dependencies are
> satisfied.

Thats not totally true, there are optional dependencies in gtk+ before
gvfs. Things like shared memory, cups backend, etc.

But, all the gio calls *do* work even with gvfs totally absent. The only
thing that doesn't work is things involving non-local files, and I don't
understand how you expect that to ever work without depenencies.

gtk_show_uri() for instance is an excellent function to use to launch
the users default app to open a specific file, based on its mimetype.

It just feels like you want to have a cake (non-local file i/o) and not
pay for it (supply dependencies).


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Brian J. Tarricone
Alexander Larsson wrote:
> On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote:
>> On Mon, 20 Apr 2009, Alexander Larsson wrote:
>>
>>> gvfs needs a session bus, not a system bus, so you're falling back to a
>>> non-gvfs system. Thus no http support.
 >>

>> OK, I suppose I can get this working on my own system, but my main
>> point is: why does GTK include a function such as gtk_show_uri
>> which depends on a big stack of unspecified stuff?  At least this
>> should be mentioned in the documentation.  As I said before, up
>> till very recently one has been able to rely on GTK functions
>> "just working" so long as the compile-time dependencies are
>> satisfied.
>
> Thats not totally true, there are optional dependencies in gtk+ before
> gvfs. Things like shared memory, cups backend, etc.
>
> But, all the gio calls *do* work even with gvfs totally absent. The only
> thing that doesn't work is things involving non-local files, and I don't
> understand how you expect that to ever work without depenencies.
>
> gtk_show_uri() for instance is an excellent function to use to launch
> the users default app to open a specific file, based on its mimetype.
>
> It just feels like you want to have a cake (non-local file i/o) and not
> pay for it (supply dependencies).

No, he just wants a sane default implementation.  If the CUPS backend
isn't compiled, the print dialog still comes up, and you can at least
print to a file.  A dialog that presents "Operation not supported" to
the user is pretty poor, IMO.  As Allin suggested, it would be nice if
there was at least a default fallback implementation that tries the
BROWSER env var, and if that doesn't work, tries a list of known browser
binary names until one succeeds.

        -brian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
In reply to this post by Havoc Pennington-2
On Tue, 21 Apr 2009, Havoc Pennington wrote:

> On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell <[hidden email]> wrote:
> > IANAL, but... Hypothesis: Monster Corp distributes D-BUS under
> > AFL, while believing that DB in fact violates patents held by
> > Monster Corp. �MC then sues users of DB. �MC can no longer
> > distribute DB under AFL, but they don't care! �They have succeeded
> > in causing trouble. �But as Havoc says, if Monster Corp had
> > distributed DB under *GPL they would have effectively made a
> > patent grant and given up the right to sue, making this scenario
> > impossible.
>
> Yes, you're right that the AFL imposes fewer restrictions than
> GPL, just as any other MIT/X11 type of license imposes less
> restrictions than GPL...

> You aren't saying anything here that doesn't also apply to
> libX11.

OK, that's a fair point.

--
Allin Cottrell
Department of Economics
Wake Forest University


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
In reply to this post by Brian J. Tarricone
On Tue, 2009-04-21 at 11:38 -0700, Brian J. Tarricone wrote:

> Alexander Larsson wrote:
> > It just feels like you want to have a cake (non-local file i/o) and not
> > pay for it (supply dependencies).
>
> No, he just wants a sane default implementation.  If the CUPS backend
> isn't compiled, the print dialog still comes up, and you can at least
> print to a file.  A dialog that presents "Operation not supported" to
> the user is pretty poor, IMO.  As Allin suggested, it would be nice if
> there was at least a default fallback implementation that tries the
> BROWSER env var, and if that doesn't work, tries a list of known browser
> binary names until one succeeds.

You only get "operation not supported" when you're trying to access a
non-local file. The default implementation handles all local files and
file types. I don't see this as not sane.

However, sure we could select a few uri types and add special case
things like looking at env vars. I wouldn't mind a patch for this, but
its hardly a major thing.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Robert McQueen-2
In reply to this post by Havoc Pennington-3
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.)

From a commercial perspective for Collabora, our clients choosing not to
use our software for even what we consider fairly hypothetical/unlikely
legal issues is still a real issue. Extending this to every
consumer/reseller of the GNOME platform seems a pretty poor idea.

For everyone else, my nightmare scenario is that this code /is/ acquired
by some SCO-like copyright/licensing troll who starts trying to sue our
clients for using GNOME and D-Bus based technologies.

I'll report my progress on any fronts back to the list.

> Havoc

Regards,
Rob

--
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Robert McQueen-2
Havoc Pennington wrote:

> Hi,
>
> On Thu, Apr 23, 2009 at 1:24 PM, Robert McQueen
> <[hidden email]> 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 speak v2 anyway, and then what was the value of creating a
> non-libdbus implementation?

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. The client on the other side can't even parse the
introspect of the v2 client, let alone deciding what you do if you get
messages which use contain types that the daemon knows the other end
doesn't understand. So yeah, it's useless not because of libdbus, but
because the boat has well and truly set sail on changing the type
system, and the protocol is good enough that nobody sees fit to bother
changing it for its own sake.

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

In my experience this isn't why people are annoyed with libdbus and so
quick to suggest/endorse alternatives. Yes it's low-level and incredibly
verbose in use, partly due to API design and partly due to the OOM
checking, but I'm really not that convinced that it actually represents
the lowest common denominator, nor that it's a very good API for writing
bindings.

It's fine for the daemon and for apps that directly implement/consume
/really/ simple D-Bus APIs, but pretty tedious if you have any
substantial type recursion going on. (I'm of the opinion (as you can
tell from Telepathy, I guess :D) that you should just have good bindings
and let rip with the types you really want, otherwise what's the point
of having a recursive type system?)

One major issue of the libdbus API for bindings is the aborting stuff.
In general I agree with the principle that the application developer
should know what they're doing, and the library is well within its
rights to stab them in the face if they don't. We actually take this
approach in Telepathy, and most internal functions use return_if_fail
and our Telepathy applications enable fatal criticals.

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.

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.

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.

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. It was deemed too much of a hassle in both the Python and Qt
bindings so they just open private connections.

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.

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.

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

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. I'm
really not that averse to implementing the protocol for new bindings.
I'm almost certain it will be a net reduction in code size, enhancement
in maintainability, and performance benefit (no double-allocator dance,
dbus-glib *REALLY SUCKS* because of this) in every case.

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

I don't think the D-Bus wire protocol is large or complex enough to make
this argument for long. Once you've learnt the secret of the ASCII to
decimal and back again authentication, and been admitted to the secret
D-Bus implementor cabal (the spec /really/ should explain that), you can
write a working implementation in a few days. I'm pretty sure I've seen
finished or at least partly started: one other C reimplementation, two
Python ones, Ruby, Java, C#, and some guys in Collabora just did a
Haskell one too.

Given that, and the rate of change of the D-Bus protocol (~0?), it's
really not that hard to go and patch your D-Bus protocol implementation
with anything new that comes up. Frankly for the past 3-4 years, nothing
new has come up in a way that excited anyone into changing the protocol
or solving issues with pairwise feature negotiation / message
reformatting in the daemon.

I'm also quite certain that dbus-python has way more code to not trigger
hidden landmines in libdbus than it would if it actually spoke the wire
protocol itself. It's only a matter of time availability that has caused
us not to excise the final hidden abort-able code paths by just ripping
libdbus out.

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

Fair, but the ongoing maintenance effort and grey hairs of people who
work and maintain/implement bindings isn't insignificant either, from
the perspective of people at Collabora who've done it at least. Bindings
need just as much test coverage anyway.

If GVariant is on track for Glib inclusion anyway, and if making EggDBus
use GBus is less effort than rewriting bits of libdbus if it proves
necessary, it might not be such a bad option. Any new users of EggDBus
will quickly run into any bugs, and if we port telepathy-glib to it, the
not insubstantial test coverage in that and various Telepathy CMs will
smoke out issues pretty rapidly.

Anyway, I'm not necessarily saying we're going to run around porting
stuff away from libdbus just for the sake of it, just that I don't think
the value of sticking with libdbus is as great as you make out. There
are of course arguments in both directions, but the legal issue is my
current focus.

> Havoc

Regards,
Rob

--
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Tommi Komulainen-4
In reply to this post by Robert McQueen-2
On Thu, Apr 23, 2009 at 6:24 PM, Robert McQueen
<[hidden email]> 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                                 [hidden email]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-6
In reply to this post by Robert McQueen-2
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 fully expect would have been another net reduction in
dbus-python code.

Havoc writes:
> > 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.

As an aside, only one of the four Python implementations I'm aware of
(CPython, IronPython, Jython and PyPy) relies on C modules. True, CPython
is the one that in practice everyone uses, but that won't necessarily be
true forever.

> I'm pretty sure I've seen
> finished or at least partly started: one other C reimplementation, two
> Python ones, Ruby, Java, C#, and some guys in Collabora just did a
> Haskell one too.

dbus-java is an interesting one, because dbus-java 1.x was a binding. Matthew
Johnson watched Alp's progress on ndesk-dbus (the C# reimplementation) and
decided that being an implementation would actually be easier. As a result,
dbus-java 2.0 is a reimplementation. It might be worth talking to Matthew about
how easy/difficult this was (bearing in mind that Java isn't exactly the most
agile language...)

> I'm also quite certain that dbus-python has way more code to not trigger
> hidden landmines in libdbus than it would if it actually spoke the wire
> protocol itself. It's only a matter of time availability that has caused
> us not to excise the final hidden abort-able code paths by just ripping
> libdbus out.

As mentioned above, dropping my use of libdbus' "helpful" object path mapping
and just using a filter function was a net code reduction. As a bonus, most of
the deleted code was rather subtle C (the sort with more comments than code,
explaining why this particular implementation is the only one that can work),
and most of the added code was relatively simple Python.

Regards,
    Simon
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Havoc Pennington-3
Hi,

On Fri, Apr 24, 2009 at 6:56 AM, Simon McVittie
<[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
1234