how to disable NO_LICENSE_IN_DEPENDENCY?

[yegor256]

I'm using this plugin with a pretty large repository, where we have many third-party dependencies, some of which simply don't have licenses. There is no possible way to fix that, since they are not ours. Moreover, if they don't have license, we can safely assume that they don't care who and how is using their products.

Thus, the question: how can I ignore this particular type of error?

[sschuberth]

There is no possible way to fix that, since they are not ours.

For this, ORT has the concept of package curations. Community-maintained curations are part of the ort-config repository.

Moreover, if they don't have license, we can safely assume that they don't care who and how is using their products.

It's actually the opposite: If something does not explicitly state a license, you must not use it at all. That's common legal interpretation and part of many Open Source usage guidelines, like e.g. the one from Zalando which states "You cannot use unlicensed code anywhere".

Thus, the question: how can I ignore this particular type of error?

If you still want to ignore this error (which is highly discouraged), then you can do so via rule violation resolutions.

[yegor256]

@sschuberth great explanation, thanks! I can't figure out how to provide the location of curations.yml to the plugin? Maybe README may be extended with this information?

[sschuberth]

Maybe README may be extended with this information?

The project's README is the wrong location for user-facing guides. Instead, please refer to the docs on the website.

[yegor256]

@sschuberth this page is not related to the GitHub Actions plugin, if I'm not mistaken. It explains how ORT can be used inside Jenkins, via manual configuration. The README file, instead, explains how to configure YAML for GHA -- that's why I'm reading it (it's pretty well written, by the way!)

[sschuberth]

this page is not related to the GitHub Actions plugin, if I'm not mistaken.

Well, those are the generic docs that apply to any way ORT is run. Also when running ORT via the GitHub action, it looks for its configuration files (and that includes package curations) in the default locations.

That said, the GitHub action could have some special additional logic that I'm not aware of, as I'm not maintaining it. @tsteenbe can probably tell you more.

But I'd assume you two options are: Put curations inside of an .ort.yml file that's committed to the repository running the action, or contribute it to the public ort-config repository for use by all.

[yegor256]

@sschuberth placing curations into the .ort.yml file in the root of my repository leads to this error in the log:

WARNING: PACKAGE_CURATION_IN_ORT_YML - The use of package curations is not allowed in the *.ort.yml file.

What is my next step? How to allow curations in the .ort.yml?

This is my .ort.yml:

curations:
  packages:
  - id: "Maven:edu.berkeley.cs.jqf:jqf-fuzz:2.0"
    curations:
      comment: "They have FreeBSD license, but it's not properly formatted"

[sschuberth]

Again see the docs, it's in the big "NOTE" box at the top: You need to enable the enableRepositoryPackageCurations setting in config.yml. In the GitHub action content, it's more convenient to set config options via CLI than by writing them to config.yml. That can be done in general by passing the path to the configuration option to the -P CLI option, like -P ort.enableRepositoryPackageCurations=true. To pass that again to the GitHub action, use

with:
  ort-cli-args: '-P ort.enableRepositoryPackageCurations=true'

[yegor256]

@sschuberth once again, thanks for your help! I did what you suggested, but the warning is still the same: log. Any ideas?

[tsteenbe]

@yegor256 If you want to disable a rule you need set up your own ort-config repository with your own rules and then set ort-config-repository and ort-config-revision see https://github.com/oss-review-toolkit/ort-ci-github-action?tab=readme-ov-file#Run-ORT-with-a-custom-global-configuration.

Your ort,yml is incorrect - in meetings now but will shoot in a PR to your repo to fix things

[yegor256]

@tsteenbe thanks! Is it possible to enable some curations without creating a new repository? (this looks like an overkill). Would be great if your fix to our .ort.yml will fix everything!

[tsteenbe]

@yegor256 Fixed up your .ort.yml in yegor256/tojos#110 - note that the ort scan will still with PACKAGE_CURATION_IN_ORT_YML - The use of package curations is not allowed in the *.ort.yml file rule violations. In the rules in our ort-config repository we do not allow package curations in .ort.yml. I will make a PR against ort-config with my curations so curations in your .ort.yml are no longer needed. An alternative is that you clone ort-config within your own github.com/yegor256 and then you can change whatever you want but you loose the benefit of easily getting curations from other ORT users.

This also why we block in the ort-config policy rules the use curations in the .ort.yml - curations in .ort.yml are only applied to one project instead of being reusable by anyone (within your org/world).

[tsteenbe]

OK I fixed things up

1. Upstream declared license was wrong for which I submitted pom: Fix license name rohanpadhye/JQF#267
2. Fix violations in github.com/yegor256/tojos repository with Add various curations for edu.berkeley.cs.jqf packages ort-config#262 and
3. Finally I fixed up the .ort.yml in github.com/yegor256/tojos repository with license choices and to removeort-cli-args: '-P ort.enableRepositoryPackageCurations=true' in the GitHub action for ORT config see Fix ORT scan yegor256/tojos#110

@yegor256 Once 2 is merged then PR in 3 should pass

[yegor256]

@tsteenbe just curious, why do we need (2) if (1) will be fixed?

[tsteenbe]

@yegor256 The fix in 1) is not yet part of a JQF release so 2) is needed to fix the declared licenses for all versions before the JQF release containing 1. Your project github.com/yegor256/tojos is currently using verions of JQF that have not be fixed with 1 so 2) fixes that up.

In ORT community we try to fix up issue upstream if time permits so future release of FOSS projects won't have problems we detected with ORT. Curations and package configurations are mechanism in ORT to patch up already publish releases - you can't go FOSS maintainers to ask "Could you please fix up all your past release so licensing is right".