I tried and managed to contribute 3 curations.
Curation documentation could be improved at ClearlyDefined.
Did some guessing which was partially ok, partially not.
https://github.com/clearlydefined/curated-data/pull/5837
https://github.com/clearlydefined/curated-data/pull/5838
https://github.com/clearlydefined/curated-data/pull/6025
From: <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> on behalf of Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Reply to: "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date: Wednesday, 9. September 2020 at 16:39
To: "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-architecture-council] IP Due Diligence Process Documentation and ClearlyDefined
I haven't explored using Facets. Mostly because I haven't seen them used consistently and, in practice, we haven't had much of a need for it (in addition to separating out test code, etc., it might also help in cases where a single Git
repository is used to create multiple JARs, but I don't think that this is actual use case for facets). Theoretically, you could use Facets to do your own evaluation (e.g., use the GLOB patterns specified to grab the license data for only those facets that
you care about).
NOASSERTION means that the discovered license cannot be mapped to an SPDX _expression_. This identifier is unintuitive as "no assertion" really sounds like "unspecified". From our point of view, it's a blocker that requires further investigation.
The string NOASSERTION. This indicates that license-like data is found, but that ClearlyDefined cannot identify an SPDX-identified license.
ClearlyDefined uses various tools, including
scancode-toolkit to determine licenses (IPZilla uses this tool for third-party content scans). In my experience, the tools are generally good but do make mistakes (this is one of the reasons why we've been pushing the use of
SPDX-Identifier tags in file headers). I'm looking at
one record today that has one file that was incorrectly identified as NOASSERTION (which I will submit a curation for).
So one way to improve the results would be to provide the scancode project with patches. Another is to just provide your own curation. You can make changes directly in the ClearlyDefined data yourself and push them for review by a curator.
There are some cases where we (the Eclipse IP Team) don't agree with what is in ClearlyDefined, have curations that are currently too cumbersome to push, or the data is completely missing from ClearlyDefined. This is why the license tool
first checks with IPZilla to see if we're trying to override. For Eclipse projects, IPZilla is still the primary source of license data.
My intention is that eventually we will start reducing our dataset by moving it to ClearlyDefined. One of our challenges here is that ClearlyDefined makes it super easy to push one curation. Pushing multiple curations (e.g., multiple versions
of the same content) is possible, but is a very manual process (which involves YAML for some insane reason).
FWIW, the curation that I provided for maven/mavencentral/org.eclipse.jdt/org.eclipse.jdt.core/3.22.0 that corrects the source repository and discovered licenses was accepted. So that's one...
HTH,
I am having a bit of trouble working with:
> NOASSERTION appearing as a discovered license;
First of all, this is a bit difficult to parse in the API model. This information is part of a "facet", it seems there can be more than one (like "test", "doc", …) and there is one named "core". To my understanding, all of them may contain
a list of license expressions each.
Simply putting up a red flag, if any of those facets (or only "core"?) contains 'NOASSERTION' would be doable of course.
Then again, IIRC "discovered" means that some tool detected that, and that tool might be wrong. So how would you reasonably override this detected value?
--
Jens Reimann
Principal Software Engineer / R&D Product Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________
Red Hat GmbH,
https://de.redhat.com/
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
--
Wayne Beaton
Director of Open Source Projects |
Eclipse Foundation, Inc.
Join us at our virtual event:
EclipseCon 2020
- October 20-22
|