Namespaces are used to register authoritative sources; before you can "find" another license list, the list must exist and be maintained.
Is there an example of an organization that maintains a license list? If so, the alternatives are 1) collaborate to manage a single license list 2) agree on namespace values for SPDX and the other managing organization(s). #1 sounds by far to be the easier process. But without a specific example of a second namespace, there are no criteria for deciding between 1 and 2, and this sounds like a solution in search of a problem. Dave On Thu, Jun 9, 2022 at 3:04 PM Gary O'Neall <[email protected]> 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. > > > > 1. 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 > 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 > - 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. > 4. 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) > 5. 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 > 6. 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 <[email protected]> > *Sent:* Friday, June 3, 2022 2:11 PM > *To:* '[email protected]' <[email protected]>; 'SPDX-legal' > <[email protected]> > *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: [email protected] > > 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. > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4566): https://lists.spdx.org/g/Spdx-tech/message/4566 Mute This Topic: https://lists.spdx.org/mt/91653387/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
