Licensing issues with dbus and dbus-glib

[Christian F.K. Schaller]

>Christian F.K. Schaller wrote:
>> People using GPL+exception licensing is quite common, so it would be nice to get
>> it solved once and for all by having dbus AFL/LGPL  dual licensed instead of getting each 
>> application developer to have to relicense. In the case of RB they would have to restart 
>> a process they already spent Months on to fix this solution.
>
>Do you think this is in any way easy for dbus? Look at AUTHORS...

I know, but if we do it for dbus it is a one time job for all apps instead of
doing it once for every application.

>Also, the LGPL plain sucks, so we should have some bias against.
Agree that the LGPL is very hard to read and understand, but it is very
common and what we depend on for major components of our system like glibc, 
gcc, GNOME etc.

>> Having dbus LGPL would also make it more conform to the rest of the library stack,
>> ie. fit the GNOME library licensing policy of using the LGPL. I think that is also KDE's
>> policy even if they have a very noteable exception in the heart of their stack.
>
> If it isn't easy to just do the exception, I think we should explore 
> whether GPL+AFL is really different from GPL+LGPL when a GPL app is 
> involved. I think with a GPL app, in both cases you must use the lib 
> under GPL, not under the alternative. If you read the LGPL at least that 
> is my impression. I don't understand how GPL+AFL is different. LGPL is 
> *not* GPL compatible except it gives you a GPL option, as libdbus also does.

The FSF was of the opinion back in the day that the only thing compatible 
with the GPL was the GPL itself and thus the only way for another license to 
be GPL compatible was to be re-licenseable to the GPL. As time went by and
other legal experts chimed in they changed their position and now agree that 
any license that do not add any restrictions beyond those of the GPL is GPL 
compatible (which is reflected in the list of GPL compatible licenses:
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses. 

With this interpretation of the GPL the LGPL is GPL compatible and
thus a AFL/LGPL licensed dbus library would solve the problems of things like 
Totem and Rhythmbox. I am unable to find the link now, but Eben Moglen actually
commented on this specifically in an interview about GPL3 and license 
compatibility, where he explained the change of understanding that had happened
over time and how they had updated the wording in the GPL3 to more exactly 
reflect how people today interpreted the GPL2.

>Also, does the "viral" work in the app->library direction? If an app 
>builds on libdbus, saying the app is a derived work of libdbus makes 
>sense to me, but saying libdbus is a derived work of the app I find 
>somewhat odd. Thus, it may be possible to use the lib under the AFL or 
>LGPL and not have to choose the GPL option.

There are no directions and it is the combined work of libdbus plus the app that is
the derived work.

>Havoc

> Thiago wrote:
> If libdbus is considered part of the system libraries -- and it is heading 
> in that direction in Linux -- GPL can link to it even if it's licensed 
> AFL.

This might be true, but it is one of the big grey areas of the GPL. I tried to get the
FSF to improve the definition of system library for the GPL3, but it is still quite murky IMO.
Of course the 'truth' in the context of contract interpretation is defined by common perception 
and I guess a good litmus test to this understanding would be if KDE for instance came out 
and said that now that Qt is part of the LSB it is to be considered a system library and thus 
there is no need anymore to pay TrollTech to develop closed source Qt applications for Linux.
If that ends up uncontested by TrollTech it would set a mighty precedent.

Personally I prefer not to rely on system library clause for anything not specifically listed
in the GPL which for the GPL3 means glibc and xlib as that is the only way currently to not
get your lawyers into panick mode.

Christian