libdbus dual licensing

[Simon McVittie]

(Response to private mail sent to the list with permission)

On Tue, 05 Jun 2018 at 17:20:37 +0000, Sriram G. wrote:
> In one of our products based on Linux, we are using libdbus for D-Bus based
> IPC. Further there are two D-Bus bound services both using libdbus. One of the
> service (A) is licensed under GPL, whereas the other is Proprietary (B).   From
> the D-Bus FAQ (1), we understand that libdbus is dual licensed. We want to know
> if in this situation, we can apply different licenses of libdbus to A and B
> separately.

Please note that I am not a lawyer, and I cannot speak for all of the
copyright holders of libdbus.

My understanding is that, yes, you can do this.

> I.e. For A we would like to go with GPL and For B, we would prefer
> the AFL . If so, what are the obligations?

See the licenses for full details of the terms you must comply with. If
you need legal advice on how to interpret and comply with those licenses,
please ask a qualified lawyer for your jurisdiction.

The requirements you are most interested in are probably the GPL's
copyleft provision and how it affects derivative works, and both
licenses' requirement to release source code.

If you have chosen the GPL, you must comply with the terms of the GPL
version 2, or any later version of your choice (in particular you must
distribute complete corresponding source for your version of libdbus,
and also release any derivative works of libdbus[1] that you have made
under a GPL-compatible license).

If you have chosen the AFL, you must comply with the terms of the AFL
version 2.1. libdbus is the Original Work and your proprietary service
B is probably a Derivative Work[1]. In particular, you must distribute
complete corresponding source for your version of libdbus, but you do
not need to release source code for your derivative work unless another
relevant license requires you to do so. There are some other terms
and restrictions, particularly around patents: see the license itself
for details. <https://spdx.org/licenses/AFL-2.1.html>

As far as I understand it, you can choose to use libdbus as though it
was under the GPL for service A and also use it as though it was under
the AFL for service B, which would mean you have to release source code
for libdbus (under its normal dual-license), service A (under the GPL)
and any other modules linked into service A (under the GPL or a less
restrictive GPL-compatible license like LGPL or MIT/X11), but you do not
have to release source code for service B. You don't have to release
two separate copies of source code for libdbus.

Evidence to support this interpretation: Nokia (a large corporation
with many lawyers) released Maemo, a Linux distribution that contains
libdbus, on their 770, N800, N810, N900 and N9 products. Maemo contained
proprietary software that used libdbus (in particular the in-call UI), and
I think it also contained GPL software that used libdbus (it definitely
contained LGPL packages that used libdbus, some of which I wrote).
Nokia released source code for libdbus and for the LGPL packages that
used it, but they did not release source code for the in-call UI.

If you used GDBus (part of GLib) or sd-bus (part of systemd) instead
of libdbus for the client side of your D-Bus IPC, that might simplify
the licensing situation, because they are both licensed under the
LGPL. Another package that is licensed under the LGPL is glibc,
the standard GNU/Linux C library, so you are probably required to
comply with the terms of the LGPL already. GDBus and sd-bus are also
better-designed libraries than libdbus. However, if you already have
a lot of libdbus-based code, I realise porting away from it is not a
trivial task!

I hope this helps,
    smcv

[1] Whether linking an executable to a library creates a derivative work
    is a question about copyright law, not a question about the licenses
    involved. The Free Software Foundation asserts that it usually does
    create a derivative work.