Resolution: Expiration Date

oss-review-toolkit / ort

A suite of tools to automate software compliance checks.

https://oss-review-toolkit.org

Apache License 2.0

1.57k stars 308 forks source link

Resolution: Expiration Date #5204

Open jens-erdmann opened 2 years ago

jens-erdmann commented 2 years ago

In a workshop we discussed the potential feature of an expiration date for a resolution. The example scenario was the following: ORT did find a commercial license of a dependency in a project. The user has bought a 1-year limited license for the component. So the right thing to handle this finding would be to write a resolution and to revert it after the license ran out.

So this situation could be improved if the resolution would expire with the license.

mnonnenmacher commented 1 year ago

The are also use cases for an expiration_date for other types or resolutions:

For vulnerability resolutions it can make sense to revisit the resolution after some time to verify that the reasoning for resolving the vulnerability still applies.
For issue resolutions it might be decided that it is ok to ignore a technical issue for some time to give teams time to fix the issue.

So it would be good to support the expiration_date for all kinds of resolutions.

sschuberth commented 1 year ago

The idea for the implementation would be to simply add a expirationDate property to the resolution classes and take that property into account in the matches() logic, i.e. not match if the resolution has expired but instead warn / hint about the expiration.

sschuberth commented 2 months ago

The user has bought a 1-year limited license for the component.

Another use-case could be a "review this later" kind of resolution for temporary work-arounds.