There is a lot of open source in pretty much every software product these days. Engineering managers are often surprised about how much (in particular, if they have a policy of “no open source”). Taking a look is not just an exercise in curiosity, it is actually a necessity to know exactly what open source code is in your products. Without this knowledge, you don’t know which open source licenses you need to comply with, and if you are not compliant, you cannot legally correctly ship your product.
To learn what’s in a product, you need to create a bill of materials for it, that is a list of the included open source codes. While in theory, this can be done by hand, in practice you will want to use a tool. A license scanner like FOSSology is a first good step, but you may want to use a professional code scanner too, which will suggest to you which code of yours looks suspiciously similar to known open source code from the web. It is up to you then to review any such findings and declare your code as either proprietary or open source.
The problem? Unless your product is trivial, a code scanner is likely to find a lot of suspiciously looking code. To create a correct bill of materials, you need to review every single finding and determine what’s what. Faced with a sea of flagged problem situations, you may want to throw in the towel, but you can’t. If you delegate it all to the respective developers, they are likely to be annoyed, because nobody every budgets for this work and they still have their features to deliver. Look forward to not having a grand time.
Next: Why you should not let developers scan their code for open source violations
Leave a Reply