The Flexera CodeInsight product datasheet (https://www.flexerasoftware.com/media/datasheets/datasheet-fci.pdf) says it can identify open source components in Docker Containers. After some testing, I am seeing results that are incomplete in identifying open source components within a simple project.   I found an article which discusses containers and license compliance (https://lwn.net/Articles/752982/). The article mentioned that VMWare has started a project to be able to the create of a bill of materials (BOM) for a container image (https://github.com/vmware/tern). Flexera can look how to use this tool to improve their product. ... View more

We have seen odd behavior when uploading new versions of the software and starting a new scan. Training from Flexera did not cover procedure on what steps to take. We have seen inventory research get deleted which represents a huge loss of time and effort. What are the best practices for handling scans for new software versions? ... View more

What is the best practices from Flexera for handling false positives? Mark file as reviewed only Create unpublished inventory item called "False Positives" Create multiple "False Positive" unpublished inventory items -- Use information to modify scan profile to avoid false positives in future ... View more

The open source external reference sites for partial and exact matches results in a lot of wasted time chasing false positives since the actual original source is not included in the search results. The product needs to identify the true origin of the source rather than rather than listing all possible matches from the universe of open source projects. From a usability perspective, any match list beyond 10-20 items is impractical to research manually! If the match list is too large, CodeInsight should offer methods of narrowing the list of search items such as: Include the ability to sort by earliest occurrence date -- The earliest file contain the source match is more likely to the be the original source code Establish code lineage (i.e. graph relationship model) Identify if any of the match items include attribution to the original source code ... View more

Regardless of inventory type ("component" or "license only"), the policy approval process should be consistent (see difference for review status below). ... View more

The usage tab introduced in 2019 R1 release needs the following clarification: Distribution – What does internal mean? From the documentation, the example provided is for development tools that is not part of the final build. We think internal distribution should be defined as for software that is package with the build but only distributed to internal company users. You should have a separate entry called “Not Distributed” for components that are not in the final build (i.e. test harness codebase). Part of Product – This question should come before distribution. If component is not part of the final build and not part of the product, then it would not be distributed. If “No” is selected for “Part of Product”, then the “Distribution Type” should default to “Not Distributed”. Linking – Please define “Not Linked”. We assume code copied into program source file would be an example of “Not Linked” ... View more

Inventory items are tightly associated with files. When we have a software version change, there can be changes to the 3rd party license component file names (cxf-core-3.3.1.jar to cxf-core-3.3.2.jar).   When uploading a new zip file and selecting “delete existing project codebase”, all inventory items are deleted if the new zip file does not contain the exact file name associated with existing inventory items. The time and effort researching license information for inventory items should not be discarded so quickly.   When uploading zip files, you can either: Upload zip with no deletion Pro: Preserves inventory items Con: Unused folders and files stay around forever. Orphaned inventory items must be removed manually. Upload new zip with deletion (overwrite existing files/folders) Pro: Folders and files are up-to-date with source control system Con: Inventory item research (audit notes, approvals, license text, etc.) is lost forever once the inventory item is deleted because of file/folder name changes The user should be given the option to preserve inventory items. This should be the default since it is a huge waste of time and effort to redo the license analysis research. I would propose that the upload with deletion only change the status of the inventory items to “deprecated”. The analyst will then have the option to either: Delete the inventory item -- This would be used if the component was no longer used in the application Associate the inventory item with new files uploaded in the zip -- Small file name changes (cxf-core-3.3.1.jar to cxf-core-3.3.2.jar) will be handled without losing prior license audit notes and legal team approvals ... View more

The automated component detection only identifies sub-components of a larger development framework. For example, our developers may be using Spring Boot framework, Angular 7 framework, etc. and CodeInsight will find 100+ sub-components and provide no hierarchy information for which components belong to the larger framework. This causes our analysts to waste a lot of effort researching the license of the sub-component.   The product should provide a method for establishing a license component hierarchy (see examples below) for complex open source frameworks so that we don’t have to waste a lot of effort researching obscure sub-component licenses.   Apache CXF (Apache 2.0)                 Component 1 (MIT)                 WSDL4J (CPL) à Weak Copyleft but follows ASF policy guidelines to only include binary file   Spring Boot (Apache 2.0)                 Component 1 (MIT)                 …                 Component 100 (CPPL)   Angular 7 JavaScript Framework (MIT)                 Node package 1 (MIT)                 … Node package 1000 (???) ... View more

The automated component detection creates inventory items with unknown license types. This happens under the following scenarios: Automated component detection publishes inventory items with "I don't know" license type There are multiple license options (i.e. CDDL or GPL with Classpath Exception) The component does not have a license Automated component detection creates unpublished inventory items with "Work In Progress" license type The published items with the "I don't know" license type are labeld as P3 and marked as “Pending”. It does not make sense to me that an inventory item can be published for approval if the license type is not known. If a license cannot be determined, the automated fining should be unpublished state so that the analyst can determine the correct license type. ... View more