Unexpected License Reset After Dependency-Track Upgrade from v4.8.2 to v4.12.0

[gautarav]

We recently upgraded Dependency-Track (DT) from 4.8.2 to version 4.12.0. The migration process was successful, and the initial interface looked similar to the previous version.

In the Version 4.8.2, we had a issue that a component missing the licenses or multiple licenses. Hence we manually set the license using the UI.
These changes were not getting overwrite by the BOM files generated by the ADO pipelines.

However, after performing the first analysis post-upgrade through ADO pipelines using Cyclone-DX 1.4, we encountered an unexpected issue: manually assigned component licenses were reset.
This is specifically for licenses that were not suppressed. Manually suppressed licenses are working as expected.

We have seen that there has been lot of changes in the license area, could you please suggest how can we overcome this problem or if we need to set a different configuration.
Any insights or solutions would be greatly appreciated.

Thanks in advance
@nscuro

[janiichi]

We have verified this with a clean instance deployment and manually uploading the BOM file. Behavior is same as mentioned above

[gautarav]

@nscuro, is there any update ?

[nscuro]

I would say this is similar to #4352. We need to somehow track which properties of a project or component have been modified manually and should not be overwritten by a new BOM upload.

[janiichi]

Hi @nscuro,

Thank you for looking into the issue regarding license resets. I wanted to highlight some additional considerations to help ensure the solution is robust and accommodates various scenarios. Manual changes in Dependency-Track span across several areas like suppression, license management, and application tagging (as mentioned in other discussions). However, licenses require special handling due to their criticality in compliance and cost management.

Scenarios to Consider

1. Packages Missing License Information:

   • For older packages without license data, manual setup of license information should be allowed. In this case, SBOM uploads should not overwrite the manually configured license.

2. Version-Specific License Changes:

   • A common scenario is when a package’s license changes across versions, e.g., version 1 uses license type X, and version 2 transitions to license type Y. This is often seen when open-source software becomes commercialized.
   • A solution here should enable version-specific license configurations, allowing manual or automated updates depending on the context. For example:
     • Version change highlights a compliance or cost impact.
     • The reverse scenario (commercial software going open-source) could also occur, requiring similar flexibility.

3. Internal Packages Without Licenses:

   • Many organizations use internal packages missing license information. In such cases, manual license assignments should not be overridden by SBOM uploads or other automated processes.

Suggested Solution

A possible approach could be to make this behavior configurable. Administrators should have the ability to define how license updates are handled in each scenario, tailoring the solution to their organization’s specific needs. This aligns with the idea that a "one-size-fits-all" approach is rarely effective in diverse environments.

By allowing configuration at the administrative level, Dependency-Track can better support both manual and automated workflows while ensuring compliance and cost objectives are met.

Looking forward to your thoughts on this approach!