Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] IP Due Diligence Process Documentation and ClearlyDefined
FYI, I just encountered an example where "NONE" is included in the discovered licenses.

When you see NONE, that means that somebody has curated the data to fix a case where the harvesting process has decided that a license has been specified, but upon inspection the curator decided that there was no explicit license statement.

In this specific example, the file that was fixed was a history/change log file that contained a line that included an SPDX license code, but the file itself had no specific indication of what license the file itself is distributed under (in this case, we assume that it's distributed under the declared license).

FWIW, the license tool's SpdxExpressionParserTests.java throws the code scanners for a loop (it contains all sorts of test strings with various license codes). I intend to connect with the developers of scancode-toolkit to consider adding some means of escaping a file or indicating that license codes embedded in a file are just a bunch of data.

Wayne

On Wed, Sep 9, 2020 at 10:38 AM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
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.

From the documentation:

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,

Wayne

On Wed, Sep 9, 2020 at 5:23 AM Jens Reimann <jreimann@xxxxxxxxxx> wrote:
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?

On Wed, Aug 26, 2020 at 11:36 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I've made some updates to the IP process documentation in the handbook to try and describe how we use ClearlyDefined.


I'd like to send a long-overdue note out to the entire committer community. But first, I'd like your input... does what I've added in the handbook make sense to you?

FWIW, don't worry about typos. I'll pick them in my next pass.

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

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

_______________________________________________
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


--
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



--

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