Refreshing a 4 years old problem

In yesterday’s post I described some of the issues with making sure that your (business logic) closed source software doesn’t get “contaminated” by GPL’d code, i.e. that you still work at an arm’s length with code that requires you to fully open your own code.

A few people are likely to take an issue with such a position of mine, mostly because I know people would just love to force companies to just always open the whole of their code, but that’s not how it works, unfortunately, in real life. What happens when you push too hard is that you’re pushed back, like Apple’s GPL-3 response (dropping Samba and GCC).

As I said, I rather have many 97% Free Software firmwares, each paying for actively maintaining two or three projects (plus a number of smaller fixes), than one 100% Free Software firmware, that maybe covers the expenses of one project.

Of course license compliance is one huge topic especially considering Android and other distributions issues like that, and that’s why me and Luca are working on this to make sure that all the sources are available properly. Of course one of our priorities is also to reduce the cost and effort due to keeping the sources in sync, and auditing the shipped content, so that’s why in the other post I was trying to cut down as many packages as possible, even when I was going to replace a more liberally licensed package with busybox, which is instead strongly copylefted.

But this is getting long for a preamble, even coming from me.

One of the things we’ve decided to try dropping out of the firmware was the pair usbutils and pciutils, which, dependencies counted, meant three packages (the third is libusb), less than before; two GPL’d, and one LGPL’d. How could we do that? Well, the only reason we had them around was that PulseAudio requires the hardware database feature of udev, and that requires the USB and PCI IDs files… which are provided by the two above-mentioned packages. The IDs files are dual-licensed under GPL-2 or 3-clause BSD though, so they are much less of a problem for us.

So anyway why am I saying this is a four years old problem? Well, it so happens that I tried once already to coordinate so that the hardware data information was merged into a single package that all distributions and project could use, rather than have it either duplicated, or provided with packages that are a bother as a dependency. Four years ago.

What I did for now is to create placeholder files that only describe the interfaces and not the vendor/device names; it goes without saying that we expect PulseAudio to work without knowing their name (and if it doesn’t, we can still strip it down to just the devices we ship with), and create a git repository for this mini-hwdata repository. What I plan to do as soon as I have time to coordinate, I’ll work again to create an hwdata ebuild that could take care of just providing the ids files, both as a weekly snapshot, and as a live ebuild fetching the files from all the various upstream locations — so that one could replace the network-cron feature with a simple emerge command.

For those who wonder why I’m not bringing it up with the folks who run those utilities (yet), this is the answer Kay gave me on Google+ yesterday (my Google+ profile is public):

It will all be part of udev/systemd some day. The entire device classification ID database thing needs something far more advanced than the current ID text files with just human readable vendor product strings and a bunch of udev rules merging some properties. We will get to that, but it will take until next year, I guess.

Waiting another year to solve something that can be coordinated in less than a week within each distribution sounds silly to say the least.