Why you should not let developers scan their code for open source violations 4/4

As discussed in prior posts [1] [2] [3], companies need to take stock of the open source software code in their products. Otherwise, they will not be able to correctly comply with the licenses of the open source code they use. Taking stock means scanning and analyzing your product code, and who else to turn to but your current developers who wrote the code?

The problems start, if such a clean-up is not properly budgeted for. On top of regular feature development, developers are now supposed to sift through old code, analyze it, and possibly even replace unwanted open source code? This is unlikely to lead to the desired results. The obvious conflicts of interest are:

• Developers don’t have time. Cleaning up does not deliver new business value and is therefore rarely adequately budgeted for. The result is hasty work, if any work at all.
• Open source clean-up does not help reaching performance goals. Similarly to not getting the time to do a proper job, a clean-up rarely makes it into performance goals, leading to low incentives.
• Developers may hesitate to correctly identify policy violations. Identifying unwanted open source code creates new work, because it is now apparent that the violation needs to be fixed.
• Developers may want to cover up past sins. Many companies still have a “no open source policy” and hence, if a developer put open source code into product code, they violated corporate policy.
• Developers may not know what they are doing. Without proper education, developers are unlikely to do a good job, simply because they don’t know what they are doing. “If it is on the web, it is free to use, isn’t it?” is still a common (but obviously wrong) sentiment.

For these reasons, I advise against letting developers scan their own code. Typical indicators that your developers may not have done such a stellar job are blanket exclusions of directories from scanning, or even more obviously, no findings at all. If you are serious about taking stock, you should give the job to unrelated developers within the company or go straight to a third party.