License Compliance Engineering

Sometimes, I care about software licenses. Not every day, but enough to sometimes run the Krazy license checker over our codebase, just to find out what could or should still be licensed more officially. I don't believe there are any real licensing issues in kdelibs, for instance, but there are a few files where the header isn't quite in the shape that we'd like it to be. For instance, missing email addresses of contributors make it very difficult to contact authors if that should be needed. Everything is implicitly licensed in an LGPL v2 or LGPL v3 compatible fashion, but it's good to have that written out in full.

Sometimes I even think about license compliance. That's Armijn's fault (you may have met him at Akademy this year at the USB plugfest or the UPnP BoF) and I do enjoy exploring -- as a mathematician -- the limits of the words set out in licenses. What does section 3c of the GPLv2 mean, exactly? It's an interesting exercise.

But approaching licenses from a logical perspective -- word games -- or a developer's perspective -- either as a means to Free Software as an end or as an annoying thing that sometimes demands attention -- does not cover the whole spectrum of thinking about software licenses. You might think about business or legal aspects thereof, too. So it was with great interest that I read the SFLC GPL compliance guide which was released just today. It explains that some things I thought were logical violations are, in fact, not so because I'd missed some crucial sub-clause somewhere else. That's a relief.

Labels: License Compliance Engineering