Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] ClearlyDefined Now Supported
I think I just need to find a way to exclude such false positives.

I experimented with using diff and an exclude file with some success. You may also be able to do something filtering on Maven scope (i.e. put false positives into the provided or test scope).

It's also worth noting that you may not *need* to do anything. The tool is intended to help with the process of identifying content that needs IP review. If you can explain away a hit, then you may be done.

Wayne

On Tue, Aug 18, 2020 at 4:23 PM Roland Grunberg <rgrunber@xxxxxxxxxx> wrote:
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 https://ci.eclipse.org/orbit/job/orbit-generate-iplog/
which I based off of an example you posted somewhere. It might be time
to integrate this into the gerrit job.


--
Roland Grunberg

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - October 20-22

Back to the top