This sounds appealing to me (if I'm understanding it correctly). From Red Hat's perspective one of the great impracticalities of SPDX has been that, after many years of SPDX's existence, its adopted identifiers still represent only a small portion of the licenses encountered in much of the the software we encounter in our product and project development. I think there are a few problematic reasons for this aside from the fact that curating the SPDX license list is a lot of work. Use of "LicenseRef" (not to mention something like NOASSERTION) is a nonstarter for the use cases we are most interested in. What we've actually done in some cases is use the nonstandard identifiers created by nexB.
Indeed I recently complained about the use of NOASSERTION in ClearlyDefined: https://github.com/clearlydefined/clearlydefined/issues/99. The issue that partly inspired this was one involving the former Facebook React license which is still widely encountered ( https://github.com/clearlydefined/curated-data/pull/1107 ). Richard On Sun, Mar 10, 2019 at 12:44 PM via Lists.Spdx.Org <Jeff.McAffer=microsoft....@lists.spdx.org> wrote: > > I love the idea of being able to easily represent arbitrary licenses with > SPDX identifiers. We use a number of SPDX based license expression tools and > all of them require that the leaf nodes in an expression be valid > identifiers. Using LicenseRef is cool but essentially defers the identity > problem. Namespacing is a common approach to distributing the problem and > enabling different communities to evolve at their own pace. This happens very > often for us when we encounter novel licenses in some of the many 000s of > components we use. Today we have to either say NOASSERTION or spoof up a > LicenseRef. > > The downside with namespacing is that two namespaces can easily end up with > different identifiers for the same license. We'd be incrementally better off > but still faced with a logic problem (e.g., are LicenseRef-ns1-Foo and > LicenseRef-ns2-Bar the same or different). Since we often use multiple tools, > each having its own namespace, make it quite hard to reason about results. > > Theoretically there could be a central registry where interested parties > could instantly discover names for license texts and register new license > texts and give them names. Then a new tool vendor/user, encountering a "new" > license would first consult the registry to see if that text has already been > allocated a name. Still some gaps but perhaps incrementally better. > > IMO the "ideal" here is that there is some automated way of "fingerprinting" > license texts such that two parties, given more or less the same text, can > independently come up with the same id. At that point you would not need a > registry, just a shared algorithm. When/if eventually SPDX does recognize a > given license and gives it a formal id, there could be a relatively simple > aliasing step where SPDX id "SomeCoolLicense-1.0" is AKA "LicenseRef-43bdf298" > > Finally, if the SPDX license list was a) less opinionated as to what can be > identified and b) very fast at adding new entries, the bulk of the issue we > see would go away. > > Jeff > > > -----Original Message----- > From: spdx-t...@lists.spdx.org <spdx-t...@lists.spdx.org> On Behalf Of > Philippe Ombredanne via Lists.Spdx.Org > Sent: Thursday, March 7, 2019 9:44 AM > To: SPDX-legal <spdx-legal@lists.spdx.org> > Cc: spdx-t...@lists.spdx.org > Subject: [spdx-tech] An example of a super simple SPDX licenses registry, for > discussion > > See > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FnexB%2Fspdx-license-namespaces-registry%2F&data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901&sdata=Gcu7ZaKsKtp%2BfMyorZpkfTKDQpm0zDg%2BxdkjOYD4bag%3D&reserved=0 > and > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FnexB%2Fspdx-license-namespaces-registry%2Fpull%2F1&data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901&sdata=GXODPG2zqT2uiVCI1Z84ZNQG85QpfEjcvvsA9oZQp5U%3D&reserved=0 > > -- > Cordially > Philippe Ombredanne > > +1 650 799 0949 | pombreda...@nexb.com > DejaCode - What's in your code?! - > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dejacode.com&data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901&sdata=iEQcHYltCN0uba4t1KwF5WvfGmPRB0RSZxGEjQH%2FYd4%3D&reserved=0 > AboutCode - Open source for open source - > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.aboutcode.org&data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901&sdata=dBq66UPR0wShGDO0SNmM06x0geoU5pABTj1Gjus0%2FsY%3D&reserved=0 > nexB Inc. - > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nexb.com&data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901&sdata=sGjYB7p6aHw7Ag11XKkodFq%2BbDEeoaZlMmSsUrFbcOM%3D&reserved=0 > > > > > > -- Richard Fontana Senior Commercial Counsel Red Hat, Inc. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2560): https://lists.spdx.org/g/Spdx-legal/message/2560 Mute This Topic: https://lists.spdx.org/mt/30394607/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
