BSD-style non-non-promo (non-)clause falsely treated as BSD-new non-promo clause

[jonassmedegaard]

The test file tests/licensedcode/data/licenses/bsd-new_100.txt and tests/licensedcode/data/slic-tests/identification/chemeris.h and tests/licensedcode/data/slic-tests/identification/MSIntTypes.h and src/licensedcode/data/rules/bsd-new_6.RULE contains a 3rd "clause" which explicitly permits endorsement of derived products.

It looks like the classic non-endorsement clause but the initial negation is dropped, changing its meaning.

At least the last in the list is in corresponding YAML file declared as "bsd-new" which is incorrect.
Yes, that same file includes a note that the author later corrected licensing, but that does not change the fact that the licensing expressed is not "bsd-new".

One other file - src/licensedcode/data/rules/bsd-original_19.RULE has a similar but even worse issue of stripping the initial negation but then including the followup "nor" which as I understand it is syntactically wrong in the english language.

[pombredanne]

@jonassmedegaard re:

The test file tests/licensedcode/data/licenses/bsd-new_100.txt and tests/licensedcode/data/slic-tests/identification/chemeris.h and tests/licensedcode/data/slic-tests/identification/MSIntTypes.h and src/licensedcode/data/rules/bsd-new_6.RULE contains a 3rd "clause" which explicitly permits endorsement of derived products.

AFAICR, I actually filed a ticket on that long long long ago with @chemeris and that was a bona fide mistake/typo he had made back then and has fixed since.
See:

• https://code.google.com/archive/p/msinttypes/issues/7
• license bug chemeris/msinttypes#7

The commit that fixed this is still the latest
chemeris/msinttypes@7636cab

This is the reason why we have a bona fide BSD new reported here and not some kind of messed up frankenstein BSD he originally had committed by mistake thing.

This should be documented in the RULEs and test for sure.

[pombredanne]

@jonassmedegaard re:

One other file - src/licensedcode/data/rules/bsd-original_19.RULE has a similar but even worse issue of stripping the initial negation but then including the followup "nor" which as I understand it is syntactically wrong in the english language.

That's likely a bug... gosh... you have eagle eyes. You rock!
Let me fix this tomorrow

[jonassmedegaard]

Thanks for the additional details.

I understand how the statement issued was a mistake, and that it makes sense for that statement to be corrected to reflect the intent of the author.

That said, I do still think, however, that a tool to scan code for licensing information should present what it scans which is factually different from BSD-new in that case.

Debian seems to have 331 instances of this pattern - possibly all of them instances of that one mistake, but it is out there and being redistributed.

[jonassmedegaard]

oh, I forgot: Here's the search showing 331 instances of the pattern: https://codesearch.debian.net/search?q=The+name+of+the+author+may+be+used+to+endorse&literal=1

[pombredanne]

@jonassmedegaard Let's do what is right together then! let me ping you on IRC tomorrow and fix this how it should be.

[jonassmedegaard]

Quoting Philippe Ombredanne (2020-02-04 21:29:18)

@jonassmedegaard Let's do what is right together then! let me ping you on IRC tomorrow and fix this how it should be.

I am online now and tomorrow as well - and happy to discuss further. It might be that we simply disagree on how your tool should behave, and that is all fine - I simply wanted to make it clear that I disagree with (how I so far understand) your position here. Looking forard to chat more - here and/or on irc :-)

…

-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private

[pombredanne]

@jonassmedegaard

It might be that we simply disagree on how your tool should behave, and
that is all fine - I simply wanted to make it clear that I disagree with
(how I so far understand) your position here.

Actually we are in agreement there after all and I might not have been clear. The legacy Chemeris notice should be returned as something else than a bsd-new since this has been so widely copied and vendored in so many packages.

So what I suggest here is to create a new license called something such as the bsd-chemeris and add notes to it that explains what is explained here for reference and update all the rules and tests that deal with it accordingly to point to this new license. From a compliance point of view I am pretty sure that Alexander intention is bsd-new and if @chemeris replies in that sense we can add the details here and in Debian for the record such that downstream users can practically treat this as a plain bsd-new if they so wish.

[jonassmedegaard]

Quoting Philippe Ombredanne (2020-02-05 06:57:22)

@jonassmedegaard > It might be that we simply disagree on how your tool should behave, > and that is all fine - I simply wanted to make it clear that I > disagree with (how I so far understand) your position here. Actually we are in agreement there after all and I might not have been clear. The legacy Chemeris notice should be returned as something else than a `bsd-new` since this has been so widely copied and vendored in so many packages.

We agree that the text should be treated as a separate license. Good.

So what I suggest here is to create a new license called something such as the `bsd-chemeris` and add notes to it that explains what is explained here for reference and update all the rules and tests that deal with it accordingly to point to this new license. From a compliance point of view I am pretty sure that Alexander intention is `bsd-new` and if @chemeris replies in that sense we can add the details here and in Debian for the record such that downstream users can practically treat this as a plain `bsd-new` if they so wish.

We also agre on adding some side-channel remark when possible. Good. Related to that I recently shared some thoughts on "side-channel stuff" on my wishlist: https://bugs.debian.org/950363#10 (where I would categorize this one as "imperfect"). I agree that providing such side-channel notes may help encourage consumers to consider taking further action to address this "flaw" in the licensing - while making it clear that it is a flaw not fixable in the _detection_ of licensing. I will probably use the name BSD-2-Clause~Chemeris instead, to indicate how it (semantically, disregarding intent and history) deviates from (i.e. would likely legally be interpreted same as) another more general license. But that might be just nitpicking - we need not align our choice of names (and already deviate at other places, most notably MIT vs. Expat). - Jonas

…

-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private

[jonassmedegaard]

I am currently leaning towards naming this BSD-2-Clause~3rd-non-clause - also because another semantically close yet verbatim different case was reported in 2012 - i.e. a year prior to the Chemeris incident: https://bugs.debian.org/688843

[DennisClark]

This continues to be a problem. A scan using v32.3.3 on the file stdint.h from
https://sources.debian.org/data/main/q/qtwebengine-opensource-src/5.15.18%2Bdfsg-2/src/3rdparty/chromium/third_party/glfw/src/deps/vs2008/stdint.h
reports

license_expression	"bsd-new"
license_expression_spdx	"BSD-3-Clause"

even though the third clause in the code is materially different from that license:

//   3. The name of the author may be used to endorse or promote products
//      derived from this software without specific prior written permission.

I will follow up on the suggestion to create a new license, starting in DejaCode. I am inclined to back off from the whole business of the number of clauses, and call it something like bsd-endorsement-allowed .

stdint-results.json

[DennisClark]

New license LicenseRef-scancode-bsd-endorsement-allowed created in DejaCode enterprise and public. Permissive. Includes extensive Reference Notes:

No "home page" was found for this license, but most instances of it contain this copyright:

Copyright (c) 2006-2008 Alexander Chemeris

It is quite possible that Clause 3 of this license text was an unintentional typo (resulting from someone working too hard and too late perhaps) but this exact license text has been used in multiple places (e.g. see 327 results at https://codesearch.debian.net/search?q=The+name+of+the+author+may+be+used+to+endorse&literal=1 ) including the unexpected wording that allows endorsement: 

3. The name of the author may be used to endorse or promote products
     derived from this software without specific prior written permission.

@AyanSinhaMahapatra Please synchronize when you have time, making sure to include the notes and the various URLs, thanks.