Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] ClearlyDefined Now Supported

On Tue, 2020-08-18 at 15:05 -0400, Wayne Beaton wrote:
> Close. Our understanding of how to use ClearlyDefined has evolved a
> little since we spoke at EclipseCon.
> Per the handbook:
> > 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. 

For now there's a few recent contributions referencing clearlydefined
where the effective licensing score is 60. In fact I don't think any
contribution so far has been below that. Do you know when a final
decision on the threshold would come ? If not I can always file CQs to
be safe.

> 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 took a look and most, if not all are dependencies of an artifact that
we use and distribute, but where the dependency itself never makes it
into the build. Strangely, they're declared as compile-time
dependencies, but if the contributor has made no effort to include them
(or feels they're optional), and their main library works, then that's
fine with me.

In fact, it seems many of these can be traced back to the
'org.apache.ant_1.10.8' module, which actually combines many of the
ant-* artifacts into one bundle.

This can be verified with mvn dependency:tree . Even those JUnit ones
come from Ant, because we currently distribute the 1.6.0 version of
those JUnit bundles and not 1.2.0.

I think I just need to find a way to exclude such false positives.

> I talked a bit about creating the dependency list to feed the tool in
> a recent blog post.

We currently have
which I based off of an example you posted somewhere. It might be time
to integrate this into the gerrit job.

Roland Grunberg

Back to the top