Jason, On Mon, Mar 12, 2018 at 2:31 PM, Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > On Mon, Mar 12, 2018 at 04:15:08PM -0500, Kate Stewart wrote: >> Hi Jason, > >> I've discussed it with my legal contacts, and it does sound like >> the best path forward at this time is to come up with a new SPDX >> id for this variant, given its pervasive nature. I'll put a >> request in to the SPDX legal group for a new identifier, and we >> can shift the conversation over to there for now. > > Okay. Thank you. Doug and I will wait to hear back from you before > allowing any more SPDX tags for this license text in the subsystem. > > Please let me know if any more information is required, I may be able > to dig up more information if required to do so. > >> It will probably take a month or so to work through their meetings, >> but that is going to be less problematic than the other option >> for cleaning this up. Thanks for the detailed background, it >> helped. Kate > > When requesting a tag can some text be added to the notes in the SPDX > database alerting the reader to check the license carefully as there > are many things claiming to be this license? > > For instance in the kernel these four files: > > arch/arm/crypto/crct10dif-ce-core.S > arch/arm64/crypto/crct10dif-ce-core.S > arch/x86/crypto/aesni-intel_avx-x86_64.S > arch/x86/crypto/crct10dif-pcl-asm_64.S > > Claim to be the OpenIB.org BSD license, but Intel has modified it in a > way I've never seen before. > > And in user space we see this version claiming to be the "OpenIB.org > BSD license" > > https://github.com/linux-rdma/rdma-core/blob/master/COPYING.BSD_FB > > That one already matches the SPDX BSD-2-CLAUSE though. > > Given this, I expect there are others too. First I want to apologize because this is a major #FAIL on my side and to make me feel less guilty that's also a fail on the part of the other licenses scanners we used: these were also treated by Fossology and the WR scanner as BSD-Clause FWIW, but that's a weak excuse! I very clearly recall stumbling on these variants of the "simplified" BSD last year. And I ended up treating them as regular BSD-2-Clause ignoring the variations in the warranty disclaimers. This was based on reports of quirks by Thomas and team ... and I pushed the commits to treat these as plain BSD-2-Clause some 11 months and a few scores ago in two commits [1] [2] to scancode-toolkit. I should have known better as Thomas's reports always are laser focused. Here is what I am doing to clear up this mini mess (and will report here by tomorrow): 1. I collected all the kernel files that have this OpenIB licenses in 4.16rc4 grep -r linux-4.16-rc4 -e "OpenIB.org" -l 2. I am also adding the openfabric code from master [3] and that from rdma [4] I am scanning, diffing and reviewing all these in details to properly identify all the variants of these puppies. Then I will: 1. update scancode so that these variants are detected correctly and not mixed up with a BSD-2-Clause 2. work with Kate and SPDX so we can get these a new SPDX id. I/we will push to fasttrack this. Then we can work out proper kernel patches. [1] https://github.com/nexB/scancode-toolkit/commit/83cebdf2dc00c0f211c84d27047a1c8b937f508e [2] https://github.com/nexB/scancode-toolkit/commit/a88bc8d8b598b2378d0729b5e568e4d73ab89e52 [3] https://github.com/ofiwg/libfabric [4] https://github.com/linux-rdma/rdma-core/ -- Cordially Philippe Ombredanne -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
