Skip to content

Conversation

@fviernau
Copy link
Member

@fviernau fviernau commented Nov 27, 2025

See individual commits.

This is howit looks if new API is used. But migration is not necessary as its backwards compatible, it
also shows how to combine sources for one rule: oss-review-toolkit/ort-config#370.

Here you can see how the combined license soure violation is rendered in static-html reports:


Bildschirmfoto vom 2025-11-27 23-17-10

@fviernau fviernau force-pushed the violation-multiple-license-sources branch from 734e7b1 to 7c3325f Compare November 27, 2025 20:56
@fviernau fviernau force-pushed the violation-multiple-license-sources branch 2 times, most recently from 1e4d928 to 260566b Compare November 28, 2025 10:11
@fviernau fviernau marked this pull request as ready for review November 28, 2025 10:22
@fviernau fviernau requested a review from a team as a code owner November 28, 2025 10:22
@fviernau fviernau force-pushed the violation-multiple-license-sources branch 2 times, most recently from 00d5186 to 08ced1a Compare November 28, 2025 11:13
@codecov
Copy link

codecov bot commented Nov 28, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.43%. Comparing base (08e631b) to head (72fa425).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##               main   #11154   +/-   ##
=========================================
  Coverage     57.43%   57.43%           
- Complexity     1701     1703    +2     
=========================================
  Files           346      346           
  Lines         12845    12845           
  Branches       1222     1222           
=========================================
  Hits           7378     7378           
  Misses         4994     4994           
  Partials        473      473           
Flag Coverage Δ
funTest-external-tools 13.66% <ø> (ø)
funTest-no-external-tools 31.07% <ø> (+0.09%) ⬆️
test-ubuntu-24.04 42.46% <ø> (ø)
test-windows-2025 42.44% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@fviernau fviernau force-pushed the violation-multiple-license-sources branch 2 times, most recently from b3e3164 to 819ea09 Compare November 28, 2025 12:15
Copy link
Member

@sschuberth sschuberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the general idea of this change.


/**
* The source of the license.
* The license sources to evaluate the license for. Must not be empty and contained in the [resolvedLicense].
Copy link
Member

@sschuberth sschuberth Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I'm unsure about the "to evaluate the license for" part. No one forces the rule to actually look at / evaluate the license sources. I think it should rather say "The sources where this particular license was found".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe "The sources where this particular license was found" is mis-leading:

  1. The above resolvedLicense.source is actually the set of sources
    where the license was found.
  2. And licenseSources in fact are the
    sources which shall be considered by the license rule.

Does this make more sense now?

fun licenseRule(
name: String,
licenseView: LicenseView,
separateEvaluationPerSource: Boolean = true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we even need this configurability? Why not make the new the default, and require rule users to manually create multiple violations from this rule (one violation per source) if needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is needed for:

  1. Backwards compatibility
  2. I believe separate violations per source to be very valuable and should be still supported in
    the same simple way as before.

}
}

/** Backwards compatibility */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I would be fine with omitting this and having a breaking change, and clearly documenting the migration path as part of the release notes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean only this property, or the entire commit?

(Would you also be ok, with marking it as deprected now, and removing it later? This would allow a smooth transition outside of the critical path of upgrading ORT.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean only this property, or the entire commit?

I was referring to the entire commit.

Would you also be ok, with marking it as deprected now, and removing it later?

Yes. I was just trying to say that this additional work would not be required from my side.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ended up not deprecating this property, because the separate per source evaluation / single source per license rule or violation is still a valid (and in my opinion even the preferred) use case. In that case using that property is a bit simpler.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @fviernau we don't want to get rid of per license source evaluator per rule we just want to offer ORT user more power/flexibility to define rules that match their organization's open source policies.

@fviernau fviernau force-pushed the violation-multiple-license-sources branch from 819ea09 to 8ee235d Compare November 28, 2025 16:10
@fviernau fviernau requested a review from sschuberth November 28, 2025 16:10
@fviernau fviernau force-pushed the violation-multiple-license-sources branch 2 times, most recently from be57cb6 to 0bafa29 Compare November 28, 2025 21:57
@tsteenbe tsteenbe force-pushed the violation-multiple-license-sources branch from 0bafa29 to 6e5a7b5 Compare December 1, 2025 11:56
@fviernau fviernau changed the title evaluator: Introduce the option to evaluate a licenseRule for all license source at once evaluator: Introduce the option to evaluate a licenseRule for all license sources at once Dec 1, 2025
Prepare for combining rule violations that stem from the same license
and package, but from different licenses sources.

Signed-off-by: Frank Viernau <frank.viernau@gmail.com>
Prepare for an upcoming change.

Signed-off-by: Frank Viernau <frank.viernau@gmail.com>
While it is valuable to be able to evaluate the license rule seperately
per license source, some users do desire to evaluate only once per
license for all source. Introduce a toggle, which allows for that while
keeping the old behavior as default.

Signed-off-by: Frank Viernau <frank.viernau@gmail.com>
Ensure the previous change is backwards compatible.

Signed-off-by: Frank Viernau <frank.viernau@gmail.com>
@fviernau fviernau force-pushed the violation-multiple-license-sources branch from 6e5a7b5 to 72fa425 Compare December 4, 2025 09:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants