“Developers have the attention spans of slightly moronic woodland creatures.” — Linus Torvalds
I’m auditing code produced by an offshore company to be used as a SaaS product for a corporation. I’m not done, but thus far have discovered such fun things as:
- Affero GPL 3
- Unlicensed code — published to Github and a website, but no license attached. This makes it unusable.
- Cut -n- Pasted GPL v3.0 code — without any attribution
Offshoring is not easy; at the least there are communication issues due to language and cultural barriers to overcome. Moreover difference in timezones can greatly impact communication.
I’m not necessarily an advocate of “waterfall” type projects, but in the case of offshored projects the design and definition phase can definitely assist in defining of standards and criteria by which project success is determined.
One definite area for criteria would be to govern the use of Open Source within work-for-hire. I “have been and always will be” a proponent of Open Source — in fact any code I write for myself is licensed under the MIT license.
There are obligations which must be met in order to use Open Source code. While the obligations exist for individuals as well as companies, the reputation cost for a company which is sued for violating licenses vastly outweighs the financial impact. Consequently the use of Open Source needs governance.
Governance can be a very involved process, but depending on the size of the organization, need not necessarily be.
A Modest Proposal for a Governance Methodology
The vast majority of Open Source uses these licenses (in no particular order):
- MIT
- Apache
- Eclipse
- GPL
- LGPL
- AGPL
- Artistic License (Perl)
(for more detail see Top 20 Open Source Licenses] and/or Pick a License, any License)
Additionally a few use cases cover the vast majority:
- Internal Tool
- Library
- Application delivered to customer
- Web application code and assets delivered across the net
- Server side code
A simple matrix can be created of the licenses and their uses to determine if a particular combination is:
- allowed — code is allowed for this use case, it may not be for another.
- forbidden — code is forbidden for this particular case
- needs further review — cases where the license is not a popular license or anything which might need more clarification prior to use
Once approval is obtained, whether automatically via the matrix or after review, the use of the code is documented, preferably with a list of obligations, and stored in the source code repository.
Trust, but Verify
On a regular basis, the source repository is reviewed to ensure that there are no surprises. While on one level code review can be a helpful practice, repetative tasks such as this are best performed by a computer. There are open source and commercial projects to scan software:
- Black Duck
- FOSSology — Open Source
- OpenLogic
- OpenVAS – Open Vulnerability Assessment System — Open Source
These scans serve two purposes. First, they help prevent surprises. Second, they keep everyone honest. It’s entirely possible that a developer chooses to use a library which is licensed with an appropriate license but unfortunately the library includes code from another library which is released under a license which has more stringent obligations. A tool helps to identify these issues.
At the end of the day Open Source is here to stay. I believe that this is a good thing. However, there still needs to be some thought given to licensing obligations and how individual Open Source projects are used in an application. This governance needs to extend to work-for-hire produced for a company.
