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.

Last week, Diego Iastrubni asked removing GPL code, prompted by MonoDevelop’s announcement that it had removed all the GPL code in its codebase, thus opening the road to proprietary plugins.

Well Diego, there’s an app organization for that. Depending on your jurisdiction, you could ask the Free Software Foundation in the United States, the Free Software Foundation Europe in Europe, the Free Software Foundation Latin America in Latin America (are you seeing a pattern here?). The FSF in the United States is the steward of the GPL (all versions) and the organization in charge of interpreting the intent of the GPL. Of course, certain matters on interpretation will end up in courts — because it is not only about the intent of the license, but also what it actually says.

There are also national centres of competence regarding licensing issues and the use of Free Software. In Finland you might want to ask COSS; in Spain, CENATIC or ASOLIF; in the Netherlands, NOiV; in the United States, the Linux Foundation. Any of those might be able to help out with this kind of question. I won’t pretend that they definitely will: it depends on the context and workload and whether the question makes sense in their context.

Fortunately, an organization like FSFE has education and information provision written into its constitution (but not its budget: support the FSFE to help it continue to help you and the rest of the Free Software world). So here’s an attempt at an answer — which does not constitute legal advice and which does not constitute an interpretation of the GPL.

So let’s follow through Diego’s question:

I have this application which I license under the terms of BSD, and I saw a GPL library (lets call it libbar ) which might help me. I incorporate the library by dinamic linking. Now my application is effectly a GPL binary, sweet.

It is vitally important to distinguish between source and object forms of the software here, as well as keeping track of mechanisms of linking. Let’s try to strip this down to a bare minimum number of components. A program A written entirely by you using no external (third-party) components and released by you under the terms of the 2-clause BSD license. That’s fine. Now suppose you modify your application to use an interface provided by a GPL library (like libbar, in Diego’s example). Does that make your program a work that must be licensed under the GPL? Maybe. Does that make the object form of the program linked to GNU readline a work that can only be distributed under the terms of the GPL? Yes. So you must ship the object with the text of the GPL, with a source code offer (either the complete source or a written offer, as usual). Still, the sources retain the license that you originally put on them (BSD 2-clause, which is GPL-compatible, so this is possible).

Now you replace libbar (the GPL library) with a newly written, 2-clause BSD-licensed, libbar_bsd. It might implement the same API as libbar, or it might implement a slightly different one and you modify your application A accordingly. Does that change the licensing possibilities that you have? Yes. you can release A under the 2-clause BSD license — again, keeping in mind other obligations you might have. If you were forced to re-license the source under the GPL (see Maybe, above), then there may be issues. If you are the sole copyright holder, then of course you can re-license. But you need to double-check any contributions you may have received to the codebase. With the new A, you can release object versions including libbar_bsd, under the 2-clause BSD license.

Lets assume, my application uses (derives classes, whatever) code from libbar. If I remove the GPL code and change it by BSD code – my work even though it does not contain GPL code – it’s a derived work, due to compile time constrains. Am I correct?

I think this scenario has two different interpretations: if A uses functions from the library then — like I said previously — the object is definitely GPL licensed and the source might need to be. But if you actually have derived classes and modified code from libbar, then it’s going to be a great deal more difficult, because your source is in itself a derived work. I’m not sure how to understand the “remove the GPL code” here: if there is no GPL source code in the application and it doesn’t link to any GPL libraries in object form then there’s no reason that the GPL need apply.

Let’s look at Diego’s other scenario:

Lets assume that libbar, uses abstract classes/methods from libfoo (which is BSD). Lets assume that my application uses the interfaces exposed in libfoo, then libbar extends those interfaces, and I am not directly using libbar. When I use my new BSD library, my application is not compiled against any GPL code (just linked to) and it never used it directly. My old code was GPL by run-time constrains and, and the new one is BSD. Am I correct?

In this scenario, application A uses libfoo (presumably unrelated, although it apparently provides functionality to libbar), so there’s no GPL code involved at all. The parenthetical comment “(just linked to)” I don’t understand: why would the application A link to libbar at all if it doesn’t use it and libbar is en independent development?

So that leaves us with that dreaded “Maybe” from earlier. Paul Pacheco commented on Diego’s blog with exactly the right bits of the GPL — the trailer to clause 2 of the GPLv2; GPLv3 doesn’t have the same language. But perhaps even more important, the GPLv2 says:

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In other words, distributing your work which is both an identifiable part of the whole work and which is not derived from the GPL library (and I’ll claim that using an interface is not in itself sufficient to create a derivative work), then the source continues to be licensable however you like, but the object must be distributed under the GPL. The sources you provide that correspond to that object form must be distributed under the terms of the GPL — strange but true.

This week I was in Grenoble for the Embedded Linux Conference Europe. On the seond day of the conference — Friday — I was one of the few people wandering around in a suit. Even the guys who normally wear suits had dressed down to deal with the nitty-gritty of kernel threads, time sources, and boot time optimization.

So I talked about licenses. And license obligations. And interesting bits of the GPL version 2. There’s one clause of the GPL version 2 that I’d like to single out because it’s one that is surprising to me — and rarely mentioned. Clause 6.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

So, let’s suppose you (Bob) receive a program under the GPLv2 from the original author (licensor, called Alice), and pass it on unmodified to a third party, Charles. Clause 1 of the GPL applies, because it is verbatim. You just need to give Charles a copy of the license, and Charles receives a license from Alice automatically. There is in my reading no license, no relation whatsoever between you and Charles. Now if Charles distributes the program, the only license he could violate is Alice’s, and it is Alice who would need to enforce any violation.

This is actually how it works, too — suppose Alice wrote a part of the Linux kernel, she grants a license to any recipient (Charles) even though there are second parties involved (Bob); Alice can enjoin Charles to satisfy the requirements of the license. (For Alice perhaps read ‘Arald)

Now suppose you, Bob, modify the program before distributing it. In that case, clause 2b comes into play and the resulting work (based on the program) is also covered by the GPL version 2. When you distribute it, Charles receives a license from you to the modified work, and Charles receives a license from Alice to the original program. This is powerful, because Charles now has two licenses and two licensors that he must satisfy — but also weak, it seems to me, because Charles could violate one of the licenses and still keep the other. So if Bob sues Charles over compliance, Charles could just switch to the original Alice version (unless Alice enforces compliance issues as well).

It’s unlikely that would work in practice, because Charles wants the modifications done by Bob. Probably.

PS. Thanks to Saul Goode for some very careful and relevant comments to my previous writing on the GPL version 2; in particular pointing to the US Copyright Code and how it doesn’t restrict running the program at all — as indeed the GPLv2 itself writes “The act of running the program is now trestricted.”

The GPL version 2 was written back in 1991, in some sort of “plain english”. At least the intention was to write a clear document that allows recipients of a copyrighted work (e.g. a compute program in source code form) the four freedoms,

• 0: The reedom to use, for any purpose;
• 1: The Freedom to study the program;
• 2: The Freedom to make modifications to the program;
• 3: The Freedom to distribute the program, either in modified form or verbatim, either as source or as a compiled object./li>

(This is not the canonical form of the four freedoms, heck no). There are restrictions on when you may exercise those freedoms. In particular, when you distribute the program, you need to give the recipient the source code. If we boil it down to its syrupy goodness, this becomes “you can have this to do what you like, but anyone you give this to gets that same right.”

Well, that’s the intention. And under normal use, this is how it works. The GPL gives you permission to use the software (you must have a license to even run a piece of software you have, because of the way copyright law interacts with software). If you violate the terms of the GPL, then you can’t use the software. Simple.

The GPL version 2 has some extra text outside of the legal parts; for instance, one bit tries to clarify the intention of the license:

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

However, intentions come into play to only a limited extent in licenses. There is the text of the license, which is .. well, suffice to say it was written in 1991 with plain English in mind.

The Register is reporting on a webcast hosted by Black Duck Software with Karen Copenhaver and Mark Radcliffe. The Register article starts out with the misleading paragraph:

Two prominent IP lawyers have warned that the all-pervasive General Public License version 2 (GPLv2) is legally unsound.

Unsound doesn’t mean broken, and unsound doesn’t mean that the main use of the GPL version 2 is unsound. There’s a great deal of ambiguity in the license; I saw a talk by Sean Hogle at OSiMWorld with similar points. In particular this ambiguity exists around “derivative work”, although “distribution” is also not watertight. One illustration that “distribution” doesn’t cover everything that might be intended is the existence of the Affero GPL (AGPL).

Note that the analysis presented (in the webcast and summarized on the Register and then summary-summarized here) applies to the GPL version 2 only, and the GPLv3 is a great deal clearer (from a legal point of view, although it’s a lot more words).

As far as the Register article goes, the first comment finishes with “Rocket science it is not.” No, it’s not rocket science, but the gap between what you want (or what you have been led to believe) and what the text actually says — let alone what it does when subjected to scrutiny — may be very great. And that’s the different between landing on the moon, crashing into the moon, and exploding on the launch pad (which is AGPLv3, BTW).