It’s Not That Complicated

We seem to be seeing a rise again in the discussions surrounding free and open source software licensing complexity, and the fear that open source may infect or taint your software. Glyn Moody wrote about the recent BlackDuck white paper on Android. (The BlackDuck white paper wanted its readers to appreciate the complexity so much they re-used the “185 components covered by 19 licenses” numbers three times.) The recent court discussion of the GPL-violation suit against Westinghouse adds fuel to the fire. Just yesterday I received email from a marketing department of yet another company with source scanning tools that ensure against open source “contamination” and “unclean IP”. Let’s get a few things out of the way. This is not an open source problem. If you program in C++ and have third-party ISV library code available, then someone could inadvertently copy source code. Or remove a copyright notice. Or maybe developers in your shop (including yourself) regularly pull example code from public example websites (e.g. MSDN or the IBM or Oracle developer networks) without paying attention to the copyright notices. Indeed some of the copyright notices on example code can be quite ambiguous or difficult to find. And when a developer copies example code from a book or journal article, did they have the right so to do? The Web massively removed friction from the system and it’s trivially easy to copy source code now. This is NOT an open source software problem. Next, Westinghouse Digital Electronics LLC got exactly what it deserved. The court found that it was indeed in violation of the terms of the software license associated with software it used. It’s pretty hard to miss the license and the copyright notices. It withdrew from the suit and failed to respond to multiple court orders. An excellent short write-up can be found here. Managing a complex sourcing of software is not that difficult. I ran a product engineering organization at a start-up in 1995 through to the end of 1999. We were delivering the functionality of a UNIX system on Windows NT as a native environment subsystem to provide true UNIX semantics at native speed. Over time we juggled our own software IP, Microsoft IP for their original POSIX subsystem, and 300+ utilities and libraries (i.e. components) covered by 20+ different licenses, ranging from the GPL and BSD to some more esoteric licenses. This was all before we had the Open Source Definition. We had a very simple rule for all development staff: If you are going to use software in the product that you did not write, then it needs to be signed off by the vice-president, R&D [me]. That’s it. We all learned in grade school that plagiarism is wrong, so don't claim work you didn't do by removing copyrights. We all learned as developers though that re-use is important, indeed necessary. Everyone in R&D understood our value as a company could be trivially marginalized if we got it “wrong”, whether through lost sales, or the loss of the Microsoft contract, or because we couldn’t articulate our value in an acquisition. We had the Free Software Foundation legal eagles watching us closely as well. I was responsible for working with the lawyers as appropriate (who in those days didn’t know nearly as much about collaborative development and licensing as they do now). We backed our “policy” with a simple set of tree-walking difference scripts to check copyrights against the known good output, and ran them during the nightly extract and build. We kept the copyrights document up-to-date. None of us had special or specific legal training. As a set of software developers in an ISV we had very good software hygiene with respect to things like source configuration, version control, automated build and test, and this allowed us to easily add our IP scans to the process. If I was to do it today, I would further ensure strings were appropriately inserted everywhere and do the back-end check on the binaries against a known good list as a secondary check, and I would investigate the collections of freely available tools for inclusion in the build process. Open source software, collaboratively developed and liberally licensed, may well be the best and most economical strategy yet devised for software re-use. A little forethought and some tool usage and you’re a long way to better enabling your organization to take advantage of open source economics while minimizing legal risk. It’s not that complicated.