-
Notifications
You must be signed in to change notification settings - Fork 310
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
Add the concept of "trusted" vendors / frameworks / SDKs #5105
Comments
Another proposal just came to my mind: "Trusted" in this context should mean that we trust the declared license, and thus also do not need to scan to get the detected licenses, even if no explicit concluded license is present. |
It has slipped my mind that we allow the name of a package curation to be empty, so we can conclude the license (and set authors) for whole namespaces like So, it that mechanism maybe already good enough? Note that this would still require separate curations for e.g. |
This is in context of [1]. [1]: #5105 (comment) Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
I believe yes. Also see #5971. |
This is in context of [1]. [1]: #5105 (comment) Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
This is in context of [1]. [1]: #5105 (comment) Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
This is in context of [1]. [1]: #5105 (comment) Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
This is in context of [1]. [1]: #5105 (comment) Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Turns out that curations with empty name / version are not enough to fully support this use-case, so I'm reopening this. A problem arises e.g. with NuGet packages which generally don't have a
The actual goal would be to conclude the license and set the author for all "System" packages. Having individual curations, even with empty versions, is not feasible as there are a lot of these packages. Also, leaving both the name and version empty is no option, as that would result in So we would either need to
|
This is required to support e.g. the use-case described at [1]. The `toCurationPath()` function already supports empty package names and uses `_.yml` as a file name in that case. [1]: oss-review-toolkit/ort#5105 (comment) Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
This is required to support e.g. the use-case described at [1]. The `toCurationPath()` function already supports empty package names and uses `_.yml` as a file name in that case. [1]: oss-review-toolkit/ort#5105 (comment) Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
When scanning code for e.g. Android or iOS apps, there are some reoccurring fundamental SDK dependencies which usually contains a lot of source code. It makes little sense to scan these dependencies over and over again for (small) version changes.
To address the issue, I believe it's fair to assume that if a company decided to develop e.g. Android / iOS apps, the (business) decision to accept the use of the required SDKs has effectively already been made. With that in mind, it would be nice if ORT had a concept of "trusted vendors" where a copyright holder and license need to be specified for whole SDK / framework, and then scanning for all belonging / matching packages would be skipped.
This is conceptually similar to the existing mechanism of curating
authors
andconcludedLicense
in conjunction with enablingskipConcluded
. A reason why this existing mechanism is not sufficient is that curations can only use ranges / wildcards as part of theversion
. However, in order to trust e.g. the Amazon AWS SDK as a whole, which includes a component likeMaven:com.amazonaws:aws-java-sdk-models:1.12.162
, we'd also need to allow wildcards for thename
(at least), so thatauthors
andconcludedLicense
could be curated for something likeMaven:com.amazonaws:aws-*:*
.So a proposal to support the concept of "trusted" vendors / frameworks / SDKs would be to extend the curation logic to also accept wildcards / regexes for the
name
.The text was updated successfully, but these errors were encountered: