Bobulate

Compliance engineering as a topic covers those activities that make it possible to ship a (consumer electronics) product that complies with the license(s) of the software contained in that product. That includes things like: figuring out what software actually is in the product (you’d be surprised how often vendors don’t even know); ensuring that you know what configurations and versions were chosen to put in the product; finding out what the licenses on those versions of the software are; finding out out what the obligations under those licenses are; and finally actually doing what those obligations demand. Hence, comply.

Comply or explain (to one of the organizations that look into enforcing software license obligations, like the BSA or gpl-violations.org).

The FSFE has long had a brief article on how to report and fix violations and Armijn Hemel at Loohuis Consulting has written a fairly lengthy compliance engineering guide (also some articles on LWN).

One popular license for software that tends to end up in consumer electronics products is the GPL. Either version 2 or version 3. It has some specific obligations that make compliance both important and sensitive. Those are the clauses requiring the complete corresponding source code, which means you need to know what the code is and how to provide it. It also means that for every binary release you need to provide the sources that can be used to create exactly that binary release. Not every company does that consistently.

Heck, I’ll name names: Conceptronic, a Dutch consumer electronics company, tries hard to comply. It delivers source code for the firmware shipped with the original release of devices, and it sometimes updates the available source tarballs. But not always. Dennis, the guy responsible, knows this is a problem. He tries, but time pressure and the upstream don’t always make it possible to do the right thing.

So there’s a company technically in the wrong where I’m willing to believe that they could be in the right if there was a little less effort involved, or a little better support in the compliance engineering process.

Enter, once more, Armijn and Shane, in their business guises of Loohuis Consulting and Opendawn Consulting. They work, shall we say, both sides of the fence: both in helping people improve their compliance processes and in tracking down violators later. For both sides, knowing which sources should have been supplied with a given binary release is of paramount importance.

So Shane and Armijn — supported by the Linux Foundation and Stichting NLnet — have produced a tool that helps in identifying what software has gone into a binary firmware image. It’s still in its infancy, but it can usefully detect Linux kernel versions, Busybox versions and configurations. That means it can be used — for products containing those pieces of software — to answer questions like “what sources and configuration files and scripts should be delivered with this product?” And that’s important because of the requirement in the GPL to provide (when necessary as defined by the other license obligations) the complete corresponding source code. Not just a bunch of tarballs and a “figure it out” notice; not just the upstream code, but whatever patches went into the device as well; and preferably not a whole bunch of extraneous cruft, either.

The tool makes it easier to do compliance checking from the outside, and easier and cheaper (as in Free beer) to do basic checking on the inside. It’s no replacement for a dedicated compliance engineer, but it does help a lot in answering questions about “what’s in here?” before firmware goes out the door.

I should add that the tool understands some common firmware packaging styles, so it will find and unpack and check things in a squashfs image. Upcoming features will add more filesystems, like concatenated squashfs filesystems, which will save a lot of time compared to running od -c, grepping for magic numbers, dd-ing things apart and then loopback mounting parts individually — that will become automatic.

You can find the tool (which is Free Software under the Apache license) at BinaryAnalysis.org. BA to the rescue. Man, I love it when a plan comes together.

The modh coinniollach is not as difficult as it often seems (…) all you need to do is to delete the ‘dh’ from the aimsir fhaistineach and to replace it with ‘nn’.

My brother brought me those instructions out of an Irish paper; I’m sure it’s good grammatical advice, but I find I’m lacking the knowledge necessary to put the advice into practice.

The reason I bring this up is not one of Irish grammar (though you may consider it a shout out to my friend Shane in Japan), but one about context and documentation. I’m an IRC user. Since 1994 or so, and for most of that time I’ve been [ade] or adridg on the networks I use (Ade Lovett used to be without the brackets). For most of that time, screen + ircii or irssi have been my tools of choice — I never could get quassel to do anything useful on the operating systems I use, and konversation, while nice, doesn’t survive my KDE session. So it came as a bit of a surprise to need to use jabber; this is used for FSFE communications, so I started up kopete.

Suffice to say it’s been an extremely annoying three hours of futzing about.

There’s not much point in writing bug reports against kopete from KDE 3.5.10, so I won’t (scratch 20 minutes because a newline got into the server’s hostname when pasting it into the configure dialog); in addition I can’t always tell the difference between a bug and myself being stupid (groupchats are totally different from contacts). The only thing I can sensibly do is add some notes to the wiki for the congenitally IRCed. Now, having written a sentence like “use RMB on the systray, pick and identity and then ‘Join Groupchat…'” I realize that there’s an awful lot of context missing there as well (and it’s o-so-disrespectful of tablet users). I take my cap off for the KDE Userbase editors, for sure.

Sadly enough, this entire tale could be retold with “pdflatex” in the place of IRC and “OpenOffice” in the place of Jabber. I now have a working OOo on FreeBSD 7-STABLE without a JRE, but that too took a measure of doing. It’s just the price you pay when you start interacting with different communities with different tools.