Close. Our understanding of how to use ClearlyDefined has evolved a little since we spoke at EclipseCon.
If third-party content is not known to IPZilla, then ClearlyDefined can be used. When an entry is known to ClearlyDefined and has a score of at least 75 and all discovered licenses are on the Eclipse Foundation’s approved licenses list, then the content can be used without further action.
As I look at this, I realize that it's not quite right. As you suggested, the effective license score is what we're most interested in, and both the declared and discovered licenses need to match. I'll update this. Note that we've discussed dropping the threshold.
Now that Eclipse Orbit has a Maven-based build, you can actually use the
Dash License Tool to determine whether or not a CQ is required. I ran the tool on the build and discovered a few gaps in our data that I've filled. Note that the build identifies a small number of Eclipse GlassFish/Jakarta dependencies that we can safely ignore. I also noticed that the tool fails to parse a couple of funky version numbers, so I'm working on a fix for that. I noticed a handful of other build dependencies that I may need help with.
Note that the tool works off a dependency list. It's up to you to determine how to build that dependency list. You can, for example, run the tool on Maven dependency information generated for a single directory in the Orbit build:
[wayne@localhost icu4j]$ mvn dependency:list | grep -Poh "\S+:(system|provided|compile)" | sort | uniq | java -jar /gitroot/dash/org.eclipse.dash.license/target/org.eclipse.dash.licenses-0.0.1-SNAPSHOT.jar -
Querying Eclipse Foundation for license data for 1 items.
Found 1 items.
Vetted license information was found for all content. No further investigation is required.
[wayne@localhost icu4j]$ _
Or...
In the ./apache case, jakarta.mail is actually from an Eclipse project, so you can skip that one (I'll see if I can further tune the script to remove it automatically). I'm pretty sure that the JUnit ones come from a minor version of JUnit 5 that has not been vetted by the IP Team (or fully harvested by ClearlyDefined). In fact, the JUnit ones are great examples of how the
ClearlyDefined score is misleading (the source has not actually been scanned, so the license list is showing NOASSERTION).
It could be that some of these dependencies are "
build and test" dependencies. If you can identify them as such, then no further investigation is required.
I talked a bit about creating the dependency list to feed the tool in a recent
blog post.
HTH,
Wayne