Early on in the development of ubiworx, we created a Certificate of Origin (COO) spreadsheet and kept it in our repo along with the code. It was a simple spreadsheet with one row per file in the repo, a data created column, author column and a column to describe any 3rd party code used. It was sometimes a bit of a pain to maintain and sometimes fell behind reality, but it got enough updates to be a reasonable reflection of the code base. It also was a good forcing function for engineers to think about where the code came from. As soon as John or I spotted anything in that column we immediately dug into why it was there.
Years later when we went to sell the company, that COO turned out to be an invaluable document. It would have been difficult to impossible to reconstruct the COO years after we started since dozens of developers had contributed to the 200KLOC or so of code. Having an up-to-date COO meant we knew the origin of every file and the license of every one as well. The git history helped a lot and we were able to cross-reference it to fill in any gaps, but it would be quite challenging if all we had was the git history.
Why not use GPL code?
From the outset of the project we had been very clear to all our team that any use of GNU General Public Licensed (GPL) code was forbidden. Copying and pasting code from slashdot or other sites was also forbidden. Lesser or Library GPL (LGPL) code was allowed with PM approval and there were strict conditions as to its use. MIT and other permissive licenses were allowed if absolutely necessary.
The GPL is a strict license that imposes several conditions on its use. These conditions are very clearly called out and integrators can make an informed decision to use GPL code or not. One of the best-known features of the GPL code is that using any GPL code in your system means the GPL must apply to your entire system. This is sometimes unfairly called the “viral” nature of the GPL. The virus analogy is unfair because you cannot choose to get a virus whereas the conditions attached to GPL-protected source code are as I said clearly called out and a clear choice must be made to include GPL code.
I have been asked before by engineers how can “they” force you to release your source code if they find you have used some GPL source code in your product. The answer is “they” (the original author or an organisation acting on their behalf) can’t force you to do anything! What the author can do is grant a license to use their source code and to specify conditions that must be met before the license can be used. If you choose not to comply with these conditions then you have not complied with the license and you are using unlicensed source code in your product. In this case, the original author can prevent you from shipping your product until you comply with the license conditions. What if you don’t want to comply? Your only choices then are recall your product or re-engineer it so it doesn’t contain any GPL code. Neither are pleasant options for a commercial product ready for launch. Some people naively think the GPL is new and untested (even now) and that it wouldn’t stand up in court, but copyright law goes back centuries. There is a mountain of legal precedent and fighting that is not going to be easy.
For our use case, we deemed the condition to release source code for our product to be too high a price to pay for the convenience of availing of some GPL source code so we opted to completely avoid GPL source code. I am sure many other software companies find themselves in similar situations and I do sometimes wonder if the GPL is in fact doing more to prevent the spread of open source than to enable it in some sectors? For us, we had decided that our closed source code was proprietary and was where our value was. The ability to charge a license fee for the use of our product was what was going to keep the lights on and the rent paid. Giving up this revenue stream simply wasn’t an option. Advocates of the GPL will of course say it does not prohibit charging for software but in reality nobody is going to pay a license fee for code they can get elsewhere and use for free.
Lesser GPL and permissive licences
LGPL often makes sense and is sometimes pretty much unavoidable. The glibc library is licensed under LGPL and not much would work without it. But engineers still need to be aware that while this license doesn’t mean you have to open source your entire product, it does mean any distribution must allow a user to rebuild and replace LGPL components if they choose. When using shared object libraries this is straightforward but linking static LGPL libraries may require you to release your Makefiles and any other tools needed to rebuild your system.
MIT, BSD, Apache and other permissive licenses don’t carry the requirement that all source code must be released. They do generally though look for an acknowledgement of their contribution so an about box or similar should acknowledge the original authors.
COO and due diligence
During the due diligence phase of the ubiworx acquisition, having a COO and knowing the origin of every file meant things ran very smoothly. There were a few queries from the consultant who had brought in to assess the code, but no red flags and nothing we couldn’t explain to their satisfaction. The very existence of the COO was a reassurance in itself to the due diligence team as it meant we had paid close attention to the origin of all of our source code.