Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
just a quick note on this: the leftpad issue had some very specific and extenuating circumstances that led to the mess it created which are really not applicable here. So while the legal team will consider our scenario, leftpad is not instructive. > On Mar 13, 2019, at 4:04 PM, Philippe Ombredanne wrote: > > Kyle: > On Wed, Mar 13, 2019 at 6:54 PM Kyle Mitchell wrote: >> How will you handle name disputes? How will you deal with >> complaints (to SPDX/LF) about the identifiers being used by >> private parties under their assigned namespaces? >> >> Prior art: https://www.npmjs.com/policies/disputes > > Thankyou: that's all valuable things to consider indeed and hard > earned from the leftpad issues. > Though I doubt mere licenses will ever be as successful as npm! > -- > Cordially > Philippe Ombredanne > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3694): https://lists.spdx.org/g/Spdx-tech/message/3694 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Hi all, I’m admittedly a bit late to this party despite having a few thoughts on the topic. This thread has quite a few aspects to it, starting with Jeff’s initial proposal, so I’ll try to hit all of them, even though the whole thread is not below. First of all, I am noticing some energy around being able to add more licenses to the SPDX License List and to do so more easily. Jeff encapsulated this concept quite succinctly with the initial conclusion to his email which was: "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." He is not the only person to express a similar sentiment. By way of review for those not intimately involved, the general highlights of the process to add a license include: 1) we only add open source licenses, use in the “real world”, etc. 2) we review them for similarity to existing licenses on list, which may result in not adding the new license if it is substantially similar to an existing license if we can accommodate any minor differences with additional matching markup according to our matching guidelines 3) add them to list, which includes creating the XML file and a .txt file - at which point they become “official” as of the next release. We aim to do releases on a quarterly basis. I’d say that after the big push to add Fedora licenses a few years back, we probably average less than 10 new licenses/exceptions per release. We have some tooling, thanks to various GSoC projects (and Gary!) that has helped in making the process cleaner. But at the end of the day, the reality is that EVERYONE who works on this project is a volunteer and it is a very small number of people actually doing this work. At the same time, I have noticed a trend that the people asking for more licenses, faster process, etc. are generally not engaged in the project in any significant way or helping to that end. Not to pick on Jeff in particular - but I have not seen a new license submission by anyone at Microsoft (that I know of) and I had to approve Jeff’s email to go to the legal team (not on list :). As SPDX gets used more and since we moved to using the Github repo, we also now have started seeing “drive-by” license submissions in the repo. I’m sure other open source projects experience this kind of thing, but I don’t really have experience as to how this is best dealt with: in other words, how do we get more people engaged and more hands-on-deck on a consistent basis? Because if we go back to the original question of being able to add more licenses, more quickly - we must have more resources in order to do so. Another issue, I think Philippe touched upon related to Jeff’s proposal for a fingerprint algorithm and the challenges in matching licenses where there are small differences - this is a key part of what the SPDX legal team does in #2 above: if we have two licenses that are similar, but not exactly the same, we have a team of lawyers looking at the differences and making a determination as to whether those differences are legally substantive or not: if not, then we accommodate with matching markup (if possible); if they make a legally substantive difference, then we add as a separate license. For obvious reasons, we are very conservative in this determination. But in any case, that is not a step that is going to automat-able. Finally - my biggest concern about some kind of registry for licenses that are not on the SPDX license list for the purpose of getting an SPDX id, is that people will just do that instead of submitting licenses to be on the SPDX License List and that trying to track this other list and pull licenses into the SPDX License List where appropriate (as per Philippe’s revised proposal) will just create more work for an already too-small and over-stretched team. In other words, it feels like not a solution, but a diversion from a bigger question (make it easier to add more licenses?) and bigger issue (need for more resources). I hope to discuss the bigger question on the upcoming legal call. Thanks, Jilayne > On Mar 13, 2019, at 12:24 PM, Philippe Ombredanne > wrote: > > Richard: > > On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana wrote: >> 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. > > Let me recap my understanding: > > I think everyone agrees that we want want more licenses in SPDX. > Anyone against this, please voice your concerns now. > > The review of new licenses for list is an all-volunteers process with > a certain level of ceremony explained here >
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Kyle: On Wed, Mar 13, 2019 at 6:54 PM Kyle Mitchell wrote: > How will you handle name disputes? How will you deal with > complaints (to SPDX/LF) about the identifiers being used by > private parties under their assigned namespaces? > > Prior art: https://www.npmjs.com/policies/disputes Thankyou: that's all valuable things to consider indeed and hard earned from the leftpad issues. Though I doubt mere licenses will ever be as successful as npm! -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3670): https://lists.spdx.org/g/Spdx-tech/message/3670 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Richard: On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana wrote: > 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. Let me recap my understanding: I think everyone agrees that we want want more licenses in SPDX. Anyone against this, please voice your concerns now. The review of new licenses for list is an all-volunteers process with a certain level of ceremony explained here https://spdx.org/spdx-license-list/license-list-overview and therefore it takes time. But it takes too much time. Why do I want an id for stable/well-defined licenses? This would make it easier to talk about and exchange licenses and it does not require the reproduction of the license text at all times. Why not using a LicenseRef for these? This would still require reproducing always the license text in every SPDX document, which does not help when there is no document (e.g. in a package manifest such as an npm or an RPM). NOASSERTION as used for now in ClearlyDefined is also fraught with problems as highlighted by Richard earlier. There are two main use cases for more licenses: private or public licenses. The main concern is to ensure that these license ids are unique enough in both cases, and that there is minimum or no duplication of license texts across ids. - For private licenses, the only concern is to ensure that names are unique enough. Mark suggested using a reverse domain name prefix for this. I suggested a lightweight registration of a prefix that would not require one to own/buy a DNS domain name. The two can likely work together (e.g. you could use a domain name or anything and still do a one time registration). In anycase, I become the master of the license texts and ids in my namespace. - For public licenses one could use a prefix/namespace plus the optional registration of actual license id/name/texts. A content-defined fingerprint id may not help in practice as I explained in a previous email as too brittle. In light of all this, here is my suggestion: 1. Establish a lightweight, easy and fast registration process for SPDX license id prefix (aka namespace). As simple as a quick PR in a Git repo. This prefix can be made of any character that would be a valid license identifier. This is used to prefix ids (and not in LicenseRef). This way you can use both DNS and non-DNS names alright. This can be used for both public and private namespaces. 2. Establish a lightweight, easy and fast registration process for prefixed SPDX license ids in an existing namespace. As simple as a quick PR in a Git repo. Submissions are very lightly moderated (we want to register licenses but not cooking recipes). There is no need for any markup or other annotations at this stage: only basic id, name, text and possibly URLs. When submitted, there is an automated deduplication triggered (e.g. we run a license scan on this license text) and if a submission is the same or mostly the same as any existing SPDX licenses, the check fails. (This is a CI script). The submitter can then reuse instead a pre-existing license id. 4. We add a status for licenses records such that they are either reviewed/approved by the SPDX legal team or not. The submissions of namespaced ids would NOT be in the approved status. 5. From that point on, the SPDX legal team can use not only direct requests for license additions but also can funnel selected public registrations as candidates for inclusion in the main SPDX non-namespaced License List. Done. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3669): https://lists.spdx.org/g/Spdx-tech/message/3669 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Richard, Jeff: On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana wrote: > 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. Agreed. What I am trying to achieve here is to make these become "standard" and known at SPDX. I think this is possible. On Sun, Mar 10, 2019 at 12:44 PM Jeff McAffer wrote: >> 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" This ideal works in theory but for several reasons I outline below would be too brittle in practice as you would have different fingerprints too often for this to be working. Instead running a full license detection is a better way to dedupe things. And this requires some form of centralization but could be fully automated alright. The other thing is that IMO giving a name/id does matter a lot: the license named 43bdf298 is not really human friendly. Now even if license-text-fingerprint-as-id were to work out, the difficult part is not so much the algorithm for computing these, but the content you feed for fingerprinting. And that part is not easily to automate: - For instance, is a copyright part of the license or not (I think not, but YMMV)? - Or what about statements around a license? For instance these two SPDX licenses may not really deserve a different id yet they have one: https://spdx.org/licenses/bzip2-1.0.6.html and https://spdx.org/licenses/bzip2-1.0.5.html The LICENSE file in the original code archives does not have a patent disclaimer statement footer seen in bzip2-1.0.5's SPDX license text. That footer is present on the archive.org website only. I would not treat this as part of the license, but this was treated as part of it here. This is a judgment call. - Or for instance, there are 6+ version of the text of the GPL-2.0 which are really the same but would fingerprint differently. Therefore a fingerprint algorithm would be hard to generalize as there would be many exceptions or a simple one would be too brittle in too many cases. Deduping is best achieved by license detection with a full diff (which is what scancode does FWIW). Let me follow up with my suggestion. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3668): https://lists.spdx.org/g/Spdx-tech/message/3668 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Hi Jilayne: On Sat, Mar 9, 2019 at 6:40 PM J Lovejoy wrote: > Hi Philippe, > I’m a bit lost on what the goal of this is. Can you provide a bit more > context. > > I looked at a couple entries and noticed, for example, this one: > https://github.com/nexB/spdx-license-namespaces-registry/blob/master/scancode/licenseref-scancode-bsd-innosys.spdx > > which then points to this: > https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/bsd-innosys.yml > > which notes that this is common in the Linux kernel. > > Weren’t we going to add to the SPDX License List some of the other common > licenses you all were finding in the kernel? > > > and https://github.com/nexB/spdx-license-namespaces-registry/pull/1 > > I sent it quickly during the legal team call on Thursday and sorry for not providing much background then. Here it is: There has been a recent discussion initiated by Mark Atwood to create stable, yet private SDPX identifiers. And there is a similar need for ScanCode licenses too (See https://github.com/nexB/scancode-toolkit/issues/532 and has been requested by several users too. Through the discussions, Kate and Gary suggested that we could reuse LicenseRef and create an SPDX document for each license. The example repository and example pull request that I linked above are to provide an example of what this would look like if we were to have such a system where there could be two level of registrations: simple namespace and namespace + licenses ... all using LicenseRef The benefit is that there would be no change to the spec required at all and could be used today. Now, the actual content of the repo I linked is based on a completely random subset of non-SPDX-listed licenses that exists in ScanCode, so their actual content is not relevant here. I reckon that I still owe you to submit all the licenses that we found in the kernel that are not yet in SPDX I am terribly late on that part. The two are not directly related... yet I could see the submission of namespaced licenses as being a funnel for actual additions to the SPDX list proper. Some may be worthy of that addition while some may not make the cut. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3666): https://lists.spdx.org/g/Spdx-tech/message/3666 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
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 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-tech@lists.spdx.org On Behalf Of > Philippe Ombredanne via Lists.Spdx.Org > Sent: Thursday, March 7, 2019 9:44 AM > To: SPDX-legal > Cc: Spdx-tech@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%2Fdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=Gcu7ZaKsKtp%2BfMyorZpkfTKDQpm0zDg%2BxdkjOYD4bag%3Dreserved=0 > and > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FnexB%2Fspdx-license-namespaces-registry%2Fpull%2F1data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=GXODPG2zqT2uiVCI1Z84ZNQG85QpfEjcvvsA9oZQp5U%3Dreserved=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.comdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=iEQcHYltCN0uba4t1KwF5WvfGmPRB0RSZxGEjQH%2FYd4%3Dreserved=0 > AboutCode - Open source for open source - > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.aboutcode.orgdata=02%7C01%7CJeff.McAffer%40microsoft.com%7C
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
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-tech@lists.spdx.org On Behalf Of Philippe Ombredanne via Lists.Spdx.Org Sent: Thursday, March 7, 2019 9:44 AM To: SPDX-legal Cc: Spdx-tech@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%2Fdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=Gcu7ZaKsKtp%2BfMyorZpkfTKDQpm0zDg%2BxdkjOYD4bag%3Dreserved=0 and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FnexB%2Fspdx-license-namespaces-registry%2Fpull%2F1data=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=GXODPG2zqT2uiVCI1Z84ZNQG85QpfEjcvvsA9oZQp5U%3Dreserved=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.comdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=iEQcHYltCN0uba4t1KwF5WvfGmPRB0RSZxGEjQH%2FYd4%3Dreserved=0 AboutCode - Open source for open source - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.aboutcode.orgdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=dBq66UPR0wShGDO0SNmM06x0geoU5pABTj1Gjus0%2FsY%3Dreserved=0 nexB Inc. - https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nexb.comdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=sGjYB7p6aHw7Ag11XKkodFq%2BbDEeoaZlMmSsUrFbcOM%3Dreserved=0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3664): https://lists.spdx.org/g/Spdx-tech/message/3664 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Hi Philippe, I’m a bit lost on what the goal of this is. Can you provide a bit more context. I looked at a couple entries and noticed, for example, this one: https://github.com/nexB/spdx-license-namespaces-registry/blob/master/scancode/licenseref-scancode-bsd-innosys.spdx which then points to this: https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/bsd-innosys.yml which notes that this is common in the Linux kernel. Weren’t we going to add to the SPDX License List some of the other common licenses you all were finding in the kernel? Thanks, Jilayne > On Mar 7, 2019, at 10:44 AM, Philippe Ombredanne wrote: > > See https://github.com/nexB/spdx-license-namespaces-registry/ > and https://github.com/nexB/spdx-license-namespaces-registry/pull/1 > > -- > Cordially > Philippe Ombredanne > > +1 650 799 0949 | pombreda...@nexb.com > DejaCode - What's in your code?! - http://www.dejacode.com > AboutCode - Open source for open source - https://www.aboutcode.org > nexB Inc. - http://www.nexb.com > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3662): https://lists.spdx.org/g/Spdx-tech/message/3662 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
