Re: GLib plans for the next cycle

[Havoc Pennington <havoc pennington gmail com>]

Hi,

On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie <desrt desrt ca> wrote:
> - How does it fit with gobject-introspection?
> - Do we need code generation?

I'm on the same page with you here, but I think the fix is to split
the object mapping from the other pieces (as outlined in my long
manifesto previously). Then go ahead and get the other pieces stable
and usable, and give the various object mapping ideas and codebases
some more time to settle.

> - What of the license issues?
>  GLib is LGPL.  libdbus-1 is not.  The recent attempt to relicense
>  libdbus-1 failed spectacularly due to copyright in a large chunk of it
>  having been acquired by a bank (or something?) when CodeFactory AB
>  folded.

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.

http://log.ometer.com/2007-07.html#17.2

3 points here.

1. AFL+GPL is the same as LGPL+GPL in the case people are complaining about.

LGPL is a dual-license - the part that's the LGPL itself, OR you can
choose GPL. The part that's the LGPL itself is not GPL-compatible -
it's a totally different license. That's why it gives you the choice
of GPL instead. libdbus is the same way, but it's choice of AFL (much
less restrictive than LGPL) or GPL.

Remember, when you link a GPL program to an LGPL library you are using
the library under GPL. Same if you link a GPL program to dbus.

The difference between dbus and an LGPL library arises only if your
program is *not* GPL.  You have to choose whether you want LGPL or GPL
when using GTK, and AFL or GPL when using libdbus. You can't say your
program is using both choices. You have to choose.

If a program is GPL+Exception, I don't think you can choose GPL for an
LGPL library. You have to use the LGPL terms. This means, however,
that your program must, in its exception, allow linking to the LGPL
library. It could also allow linking to an AFL library, if so. If your
exception doesn't allow this, then your program's GPL terms require
that the library be distributed under GPL... but if the library is
GPL, you can't have the exception. So GPL+exception is not compatible
with an LGPL library unless the exception includes LGPL libraries.


2. It's unclear that the AFL2.1 is GPL-incompatible.

GPLv2 is hard to understand on this topic, so it's hard to know. GPLv3
may be clearer. But as generally understood, if you distributed
libdbus under either GPL version, you'd be licensing your patents
under GPL. All AFL2.1 requires is that if you sue *with respect to
libdbus* claiming libdbus infringes your patents, you can't distribute
libdbus. But distributing libdbus under GPL requires you not to sue
with respect to libdbus. So in practice, there is no situation AFL
adds further restrictions over GPL. The GPL already prevents you from
suing for infringement claiming that libdbus infringes your patents,
*while distributing libdbus yourself*, because distributing libdbus
yourself necessarily licenses your patents.

There is no way, under either GPL or AFL, to distribute libdbus while
simultaneously suing users of libdbus saying libdbus infringes your
patents. The licenses agree on this. As does LGPL for that matter.

So the situation where 1) AFL keeps you from doing something and 2)
GPL allowed you to do that same thing, does not ever exist. As a
result, I don't think there's a "further restriction." To me "further
restriction" means "prevents something the GPL allowed me to do" and
the AFL does not do so. AFL is pretty much an MIT/X11 license and an
extremely liberal and toothless patent clause (compared to the GPL's
patent requirements).

3. There's no practical issue, even if there's a theoretical one
(which I don't think there is)

_Even_ if I'm wrong on the theory (IANAL), the case where it even
_matters_ is that some non-software company who owns the assets of a
small business (codefactory) that went bankrupt years ago, somehow
opens a musty old file, cross-references it with open source forums on
the Internet, realizes they could disrupt the distribution of
something called "Rhythmbox," goes to lots of legal time and expense
to do so... and then we either rewrite the Anders-written code in
libdbus, or add an exception to the GPL in Rhythmbox, or relicense
Rhythmbox to GPLv3, or some other solution, and we solve the problem.

There are many things to worry about in life, but this is not one of them.


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.

Havoc