License auditing your code

I’ve already said that I’m working on a new device, whose firmware is Gentoo-based, and it goes easily said that it’s a partly-closed source software. That’s just the way it is: while probably the most part of the software within the device is Free Software, the business logic is behind closed doors. People are getting used to this, and I don’t think it’s entirely a bad thing. I mean, we’re giving back to Free Software in this context in many ways: Luca is working on libav and Aravis me I’m working on Linux drivers and together we’re working on Gentoo so the environment as a whole is gaining something.

Of course, when you are dealing with this kind of devices, you have to take care of auditing the licenses of the software you’re bundling up in the firmware, which is what I’m doing today (well, yesterday for you who read me I guess). It’s not my first time at this game, and as usual my starting point is an UML package diagram.

*For those not used to UML, a package diagram is a decent way to identify who makes use of what; thanks to the way the UML is specified you can use two different “stereotypes”, called import and access which show you the execution/linking boundary quite clearly. By giving each project a package, and each library within that package a subpackage, you can easily see how things are connected.*

So while working through it, with the two objectives to both reduce the amount of software we had to install (I talked about that yesterday), and to verify that we don’t distribute our closed-source code linked to GPL libraries, I started noticing a few bad things; from one side the license identification in Gentoo is shabby, but that’s nothing new, as I write this, I’m fixing a few ebuilds that report the wrong license information, for instance; from the other side, we have packages like PulseAudio that does not let you understand their licensing in a very clear way.

In the case of PulseAudio, the LICENSE file tells you this:

All PulseAudio source files are licensed under the GNU Lesser General Public License. (see file LGPL for details)

However, the server side has optional GPL dependencies. These include the libsamplerate and gdbm (core libraries), LIRC (lirc module), FFTW (equalizer module) and bluez (bluetooth proximity helper program) libraries, although others may also be included in the future. If PulseAudio is compiled with these optional components, this effectively downgrades the license of the server part to GPL (see the file GPL for details), exercising section 3 of the LGPL. In such circumstances, you should treat the client library (libpulse) of PulseAudio as being LGPL licensed and the server part (libpulsecore) as being GPL licensed. Since the PulseAudio daemon, tests, various utilities/helpers and the modules link to libpulsecore and/or the afore mentioned optional GPL dependencies they are of course also GPL licensed also in this scenario.


Is this clear to you? It should be: libpulse is the library you implement a PulseAudio client with, and libpulsecore used to be the convenience library only used by the server… but in PulseAudio’s history, this hasn’t been the case for quite a while, with the result that libpulse requires libpulsecore, and that means that if you link GDBM into PulseAudio’s core library … you now have GPL’d libpulse.

This is not the case for all the libraries it uses though: for instance BlueZ is not loaded into the core library so you still only have a PulseAudio daemon GPL’d and not the libraries, as intended.

What’s the catch about this? Well, turns out that Nokia knew about this for a while, since they did contribute a “simple” database in alternative to GDBM (GPL-2) and TDB (GPL-3), which is fine for most embedded usage, if not for desktops — which is exactly what I need here.. of course the ebuilds still force GDBM enabled. I’m fixing that as well.

I’m leaving for later fixing the license specification for other USE flags, it’s a time constraint for now.

I guess that every time I do this I understand how difficult license auditing is, and why people don’t like having multi-license projects or even multiple licenses doing almost the same thing. Oh well.

One thought on “License auditing your code

  1. I sympathize with you… that’s why I’ve promised myself that my open-source projects (still in partially-closed development, for now) will all use the MPL2.0.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s