>> Mark' scanner may be constrained by its underlying license detection engine >> and not catch this alright. I would guess this engine to be fossology. >> Mark: is this a correct guess?
Wind River's detection approach is to employ multiple scanning technologies + plus a voting algorithm (some technologies are better at identifying different licenses hence get a higher weight). We continue to add new and remove scanning technologies overtime. One problem is that different distros will sometimes designate different package level licensing for the same package. We have recently integrated a database that includes human analysis of the package licenses that looks at the most popular package level license designation (e.g., 4 or 7 distros agree on the same license). >> Note that per keyring metadata the correct license is "MIT and Python-2.0" >> and not just MIT. The algorithm being discussed here has a specific purpose - *to measure the discipline a project in ensuring every file has a license notice*. The package level license (or license found in a meta file) is often worthless or worst - deceptive. For example, the case where someone copies files into the Keyring project from another project under say the LGPL-2.1 (or GPL, Apache, ...) where the other project also only noted LGPL-2.1 (or GPL-2.0, Apache) in a meta file. That is, those files are NOT MIT and Python-2.0 so the meta file is misleading. If Keyring was more disciplined in putting a license notice in every file there is a higher probability they would have added the proper LGPL-2.1 (or GPL, Apache, ...) notice. Observation - The more successful a project is, the more likely they are to borrow from other projects that use different licensing (e.g., busybox, Linux Kernel). What is particularly valuable about SPDX is that it allows one to deliver licensing down to the file level and to show when licensing is missing. At the time we reviewed Keyring several years back it did not have a proper meta file license designation. It is for these various reasons Keyring deserved a failing License Coverage grade. - Mark -----Original Message----- From: Philippe Ombredanne [mailto:[email protected]] Sent: Monday, February 20, 2017 2:24 AM To: [email protected] Cc: Gisi, Mark; Schuberth, Sebastian; Paul Sherwood; Kate Stewart Subject: Re: Getting started... On Sat, Feb 18, 2017 at 5:58 PM, Paul Sherwood <[email protected]> wrote: > On 2017-02-18 04:54, Gisi, Mark wrote: >>>> At Kate's talk [1] (can't find the slides online, btw) she showed a >>>> Wind River dashboard which mentioned that the WR scanner >>>> (proprietary?) identified keyring as having no license info. >> >> >> Wind River has provided a free SPDX creation service for more than >> three years including the dashboard view: >> http://spdx.windriver.com/pkg_upload.aspx >> >> We did this to allow one to obtain instance access to the SPDX >> creation process to promote the adoption of SPDX. All you need is a >> software package and an email address (actually you only need an email >> since we provide sample packages as well). We make it so easy that >> even your grandmother can create an SPDX file - provide she has an >> email account (at least that was a core design principle that guided >> us). > > > Given that the service you're mentioning is proprietary, I'm not sure > whether the algorithm is the same as what led to Kate's slide or not. But in > any case the keyring upstream maintainer points out that his licensing is > detected at https://pypi.org/project/keyring/ and it seems that the service > Kate used did not detect it. Paul, Kate: keyring is actually using the standard Pypi metadata to document its license in its setup.py file [1] and this contains proper identification. Note that per keyring metadata the correct license is "MIT and Python-2.0" and not just MIT. Mark' scanner may be constrained by its underlying license detection engine and not catch this alright. I would guess this engine to be fossology. Mark: is this a correct guess? Now, the latest ScanCode toolkit [2] detects keyring's two licenses correctly. ScanCode [2] is open source software and now has emerging support for SPDX contributed by Sebastian Schuberth. See also several related comments in this issue Paul entered on keyring [3] [1] https://pypi.python.org/pypi?:action=list_classifiers [2] https://github.com/nexB/scancode-toolkit/ [3] https://github.com/jaraco/keyring/issues/263#issuecomment-281035598 -- Cordially Philippe Ombredanne +1 650 799 0949 | [email protected] DejaCode : What's in your code?! at http://www.dejacode.com nexB Inc. at http://www.nexb.com _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
