Spdx-legal@lists.spdx.org | Reminder - meeting tomorrow on License Namespaces

Home Messages Hashtags Subgroups

Date Date 1 - 3 of 3

Reminder - meeting tomorrow on License Namespaces

Gary O'Neall #3145 Greetings SPDX tech and legal teams, A reminder we are continuing the license namespace discussions tomorrow, Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific). We will be using the Legal Team’s JITSI meeting coordinates: https://meet.jit.si/SPDXLegalMeeting Dial-in: +1.512.647.1431 PIN: 3275 0470 68# We will focus this meeting on the namespace proposals continuing the discussions where we left off last week. The minutes including the agenda can be found here: https://github.com/spdx/meetings/blob/main/joint/2022-06-03.md I would like to limit the problem statement discussion to 20 minutes, 30 at most. To make this discussion more efficient and productive, I would like to stick with the list and actions we discussed last week and not introduce any new problem statements. Here’s a summary of the problem statement lists and actions we agreed to – along with a few additional suggestions some of you have made: TL;DR – we’re going to focus on #5 below. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. Agreed existing spec features cover this, but needs better documentation. Agreed to update Annex D. No need to discuss as a problem statement – we’ll need a plan to document which we will discuss later in the agenda Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. Consensus that this is better addressed by REUSE. No need to further discuss as a problem statement. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. No consensus on this topic Action was to identify at least one package manager group who would agree to implement namespaces before including this in the problem statements. If we do not find at least one such package manager group by our meeting tomorrow, we will consider this problem out of scope for this specific namespace solution At the start of the meeting – we will check to see if anyone found such a package manager group. Ability to efficiently reference common licenses which are not on the SPDX License List, including those which do not meet the SPDX license inclusion principles Reworded: Should we have a way to efficiently reference common licenses which are not on the SPDX License List, regardless of context (e.g. not specific to source code / Documents / package managers) The votes for this were 9 in favor, 3 not in favor. We’ll discuss on the call, but it looks pretty likely this will be in scope for the namespace problems to solve (I’m hoping this is a very short discussion) Ability to advertise the availability of license lists other than the SPDX license list There was an almost even split on this problem statement, so further discussion is warranted It was pointed out during and after the meeting, that this is a bit confusing as to what we mean by “advertise”. To help clarify, I would like to split this into 2 different problem statements: Ability to promote license lists other than the SPDX license list in a similar fashion to how we promote tools that support the SPDX standard Ability to locate/find license lists other than the SPDX license list Should namespace proposal help solve the issue of capturing variants of licenses which match the same listed licenses per the matching guidelines? There were 2 votes for this, 6 votes against I followed up with both votes for and they are OK not including this in the namespace discussion Even if we don’t solve this in the namespace proposal, it still needs to be discussed – suggest discussing it in a separate meeting – perhaps one of the legal or tech team calls Following the problem statements discussion, we can decide on what actions need to be taken followed by the policy discussion followed by the syntax and process discussion per the original agenda. See you online tomorrow. Best regards, Gary toggle quoted message Show quoted text From: Gary O'Neall <gary@...> Sent: Friday, June 3, 2022 2:11 PM To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...> Subject: Minutes from joint SPDX Tech Legal call available for review Greetings SPDX tech and legal team members, Thanks to all the attendees of today’s joint tech / legal call where we discussed the namespace proposals. I just created a pull request with the minutes at https://github.com/spdx/meetings/pull/180 Those of you on the call, please review and comment if we missed anything. We have scheduled a follow-up meeting for next Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific). We will be using the Legal Team’s JITSI meeting coordinates: https://meet.jit.si/SPDXLegalMeeting Dial-in: +1.512.647.1431 PIN: 3275 0470 68# We will focus this meeting on the namespace proposals continuing the discussions where we left off today. Sebastian has volunteered to coordinate a separate call to discuss the “License Snippets in Source Files”. This may be a separate meeting or may be part of the tech and/or legal calls next week. Stay tuned for further meeting details. Best regards, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: gary@... CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.
More All Messages By This Member
Steve Winslow #3147 Hi Gary, thanks for all of the above. Just one comment for folks on the list of agenda items -- for items 2 and 3, I think this may have accidentally copied over the same problem statement as item 1: 2. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. Consensus that this is better addressed by REUSE. No need to further discuss as a problem statement. 3. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. No consensus on this topic Looking back at the notes, I think these were supposed to be: 2. Unable to reference or locate text for non-listed licenses when used in license expressions within source files Consensus that this is better addressed by REUSE. No need to further discuss as a problem statement. 3. Unable to reference or locate text for non-listed licenses when license expressions are used in package manager meta-data files No consensus on this topic . . . Just wanted to highlight in case people are looking at this list instead of the minutes from last week's meeting. Talk to you all shortly, Steve On Thu, Jun 9, 2022 at 3:04 PM Gary O'Neall <gary@...> wrote: Greetings SPDX tech and legal teams, A reminder we are continuing the license namespace discussions tomorrow, Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific). We will be using the Legal Team’s JITSI meeting coordinates: https://meet.jit.si/SPDXLegalMeeting Dial-in: +1.512.647.1431 PIN: 3275 0470 68# We will focus this meeting on the namespace proposals continuing the discussions where we left off last week. The minutes including the agenda can be found here: https://github.com/spdx/meetings/blob/main/joint/2022-06-03.md I would like to limit the problem statement discussion to 20 minutes, 30 at most. To make this discussion more efficient and productive, I would like to stick with the list and actions we discussed last week and not introduce any new problem statements. Here’s a summary of the problem statement lists and actions we agreed to – along with a few additional suggestions some of you have made: TL;DR – we’re going to focus on #5 below. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. Agreed existing spec features cover this, but needs better documentation. Agreed to update Annex D. No need to discuss as a problem statement – we’ll need a plan to document which we will discuss later in the agenda Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. Consensus that this is better addressed by REUSE. No need to further discuss as a problem statement. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. No consensus on this topic Action was to identify at least one package manager group who would agree to implement namespaces before including this in the problem statements. If we do not find at least one such package manager group by our meeting tomorrow, we will consider this problem out of scope for this specific namespace solution At the start of the meeting – we will check to see if anyone found such a package manager group. Ability to efficiently reference common licenses which are not on the SPDX License List, including those which do not meet the SPDX license inclusion principles Reworded: Should we have a way to efficiently reference common licenses which are not on the SPDX License List, regardless of context (e.g. not specific to source code / Documents / package managers) The votes for this were 9 in favor, 3 not in favor. We’ll discuss on the call, but it looks pretty likely this will be in scope for the namespace problems to solve (I’m hoping this is a very short discussion) Ability to advertise the availability of license lists other than the SPDX license list There was an almost even split on this problem statement, so further discussion is warranted It was pointed out during and after the meeting, that this is a bit confusing as to what we mean by “advertise”. To help clarify, I would like to split this into 2 different problem statements: Ability to promote license lists other than the SPDX license list in a similar fashion to how we promote tools that support the SPDX standard Ability to locate/find license lists other than the SPDX license list Should namespace proposal help solve the issue of capturing variants of licenses which match the same listed licenses per the matching guidelines? There were 2 votes for this, 6 votes against I followed up with both votes for and they are OK not including this in the namespace discussion Even if we don’t solve this in the namespace proposal, it still needs to be discussed – suggest discussing it in a separate meeting – perhaps one of the legal or tech team calls Following the problem statements discussion, we can decide on what actions need to be taken followed by the policy discussion followed by the syntax and process discussion per the original agenda. See you online tomorrow. Best regards, Gary From: Gary O'Neall <gary@...> Sent: Friday, June 3, 2022 2:11 PM To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...> Subject: Minutes from joint SPDX Tech Legal call available for review Greetings SPDX tech and legal team members, Thanks to all the attendees of today’s joint tech / legal call where we discussed the namespace proposals. I just created a pull request with the minutes at https://github.com/spdx/meetings/pull/180 Those of you on the call, please review and comment if we missed anything. We have scheduled a follow-up meeting for next Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific). We will be using the Legal Team’s JITSI meeting coordinates: https://meet.jit.si/SPDXLegalMeeting Dial-in: +1.512.647.1431 PIN: 3275 0470 68# We will focus this meeting on the namespace proposals continuing the discussions where we left off today. Sebastian has volunteered to coordinate a separate call to discuss the “License Snippets in Source Files”. This may be a separate meeting or may be part of the tech and/or legal calls next week. Stay tuned for further meeting details. Best regards, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: gary@... CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.
More All Messages By This Member
J Lovejoy #3152 I wanted to clarify Philippe’s comment on how the SPDX-legal team chooses ids (which is generally documented here: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-fields.md ) as specific to the examples mentioned below: (also note - this thread was cross-posted to the tech and legal mailing lists, but it looks like David (?) is not on the legal mailing list, so it then seems like all replies may only be going to the tech list. If there is a cross-functional topic, please be sure you are a member of the relevant mailing lists so responses don’t get sidetracked away from one list or another) Re: Reminder - meeting tomorrow on License Namespaces From: Philippe Ombredanne Date: Wed, 15 Jun 2022 17:43:01 MDT 2) has the SPDX legal team agreed to not assign any SPDX IDs that case-insensitively match a current or future Scancode Key without matching license texts? (I hope so, otherwise migrating to qualified license IDs is unavoidable.) Not that I know of, but that would be a fairly easy and super useful thing alright. As a practical conflict example, we have been tracking in ScanCode the Arphic Public License with the "arphic-public" and SPDX "LicenseRef-scancode-arphic-public". When this was eventually added to SPDX in the license list 3.17 this May, the key picked by SPDX has been instead: "Arphic-1999" The way we resolve this in the ScanCode licensedb is to: - use the new "Arphic-1999" as the SPDX license id - move our now "old" "LicenseRef-scancode-arphic-public" to a list of "other_spdx_license_keys" because our user and their tools may depend on this. FWIW, we have been tracking this "arphic-public" for at least seven years since before ScanCode was called ScanCode. I am not claiming precedence here, rather just stating the date since when we started tracking these in ScanCode licensedb for reference. These licenses likely have existed for a long while before. The same also happened in that same SPDX license list release: - SPDX picked "Baekmuk" over ScanCode's "baemuk-fonts" (in ScanCode since before 2015) - SPDX picked "Bitstream-Vera" over ScanCode's "bistream" (in ScanCode since before 2015) - SPDX picked "mplus" over ScanCode's "m-plus" (in ScanCode since 2019) So if the SPDX process could kindly consider and reuse identifiers we have already used in ScanCode that would be more than nice and surely help diminish a possible source of confusion. ALL of the examples referenced were licenses already recognized and used by Fedora on their list. SPDX adopted the ids already in use by Fedora. This is directly inline with the documented description of SPDX License List fields for short identifiers as per the link above. I would hope that we can all agree that we should adopt the id used by a long-standing community project.
More All Messages By This Member

1 - 3 of 3

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms