-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ctrlx-reporter): Allow licenses filtering based on the classifications #9842
Merged
nnobelis
merged 2 commits into
oss-review-toolkit:main
from
boschglobal:nnobelis/ctrlx_use_categorizations
Feb 3, 2025
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit message nits:
sthe license" (BTW, I guess this can only be true for proprietary licenses; so maybe we should explicit say "Some proprietary licenses forbid their terms to be disclosed".)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'm wondering whether this should become a general reporter option that works for all report formats... any opinions here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had the same thought, I do remember discussion around such feature long time ago.
I do recall having some 2 step mechanism in mind
I believe there has been an additional use case, which I do not recap. Maybe someone else does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sschuberth I think it's even worse than that: there are some licenses that forbid you to even mention them publicly, not just their terms.
@sschuberth, @fviernau :
The problem is, I am not sure a "one size fits" all solution would work for all reporters.
For instance for CtrlX, the logic should be the following as I understand it:
This second point is needed because one of our users wants to "hide" a component from the report based on its license.
If you provide a generic filtering upfront, how would you disambiguate the two cases ?
Additionally, some reporters already do more of less this logic: the
AsciiDocTemplateReporter
has a classification filtering functionFreemarkerTemplateProcessor.TemplateHelper#filterForCategory
. Then the template chooses which licenses/categories to show or not.If the filtering is done upfront, aren't we losing flexibility here ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's ok. I just wanted to emphasize that all this only applies to proprietary licenses, not Open Source licenses.
Shouldn't it be
NONE
if there really are no licenses found?Well, that's something to think about, maybe by adding something to
ReporterInput
. But still I think that the filtering itself could be implemented for all reporters, like by providing an allow-list of license classifications that should be included.Indeed we'd lose the possibility to filter different categories for different reports in one invocation of the reporter tool. But the question is: Do we really need this flexibility, or can we consolidate logic in order to simplify things? And if some one really needs to filter licenses differently per report, that some one could always run
ort report
multiple times with different configuration.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of this idea, different reports have different audiences and requirements, for example, in my opinion the web app report should always show all findings, otherwise you cannot rely on it without checking the settings used to generate it.
If there is a specific requirement right now to have such a filtering for one single reporter, why not implement it as a reporter option now instead of trying to tackle the much more complex general use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because IMO we need to watch a bit for not everybody just scratching his / her own itch to quickly implement an isolated feature, fragmenting the code base with heterogeneous behavior. The way reporters do repetitive work, like applying license choices etc., already is a mess, and I don't want it to become worse.
That said, maybe we should approach this differently, with different reporter sub-classes, like SBOMs, attribution documents, and technical reports (not meant for distribution), and provide tailored
ReporterInput
s to all of these.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, you guys need to continue the discussion without me, as I'll be on vacation. I'll dismiss my review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern is basically the same but from another angle, I'd rather have an isolated feature in a single reporter than an unfinished or not well thought through implementation that affects the whole reporter. And my impression is that making this a global option requires more planning to do it right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, maybe I've underestimated the effort.