Hi David,
I believe that treating the SPDX license list different from other lists (e.g. more of a first class citizen) is a policy decision which should be discussed with the legal team before and separate from the syntax. In my personal opinion, the SPDX license list should be treated differently since it is sponsored directly by the SPDX organization. I also think we should recognize and support other lists, but should not be obligated to treat it as an “equal” in terms of syntax and other modeling/property aspects. I would suggest we try to table this discussion until the Friday call and add it to the list of policy discussions. >From a historical perspective, the past meetings I have been involved in have >always treated the SPDX license list as a focused unique list supported by the >SPDX community and only recently has the issue of having the SPDX license list >be treated as something of an equal to other curated and non-curated lists of >licenses. We do support fields that recognize with a license is on other >lists (e.g. the fsfLibre and isOsiApproved fields in the License List XML >schema ><https://github.com/spdx/license-list-XML/blob/master/schema/ListedLicense.xsd> > ). Best regards, Gary From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Monday, June 27, 2022 1:53 PM To: SPDX-list <[email protected]> Subject: Re: [spdx-tech] Joint SPDX Tech / Legal call - namespaces Re: License Identifier Syntax ONLY: (Not policy): The proposed annex currently says: The SPDX License List is a curated list of commonly found licenses and exceptions used in free and open or collaborative software, data, hardware, or documentation. Licenses in the SPDX License List have stable license identifiers and canonical permanent URLs pointing to specified license texts, with markup and matching guidelines to capture non-substantive variations to the text. That description does not accommodate "curated lists of commonly found licenses and exceptions used in other software, data, hardware or documentation, that have stable license identifiers and canonical permanent URLs pointing to specified license texts". I.e. license lists curated by organizations other than the SPDX legal team. The currently-proposed syntax treats other license list curators as second-class citizens, referring to licenses from those lists as "custom" and using a special syntax that doesn't apply to open-source licenses: Each custom license identifier under this namespace consists of the following, in order: the prefix LicenseRef- a period the namespace a period and a hyphen any other characters permitted by the license expression syntax (i.e., letters, digits, "-" and ".") That is a large amount of entirely unnecessary syntactic overhead. The only technical/syntax requirement is that license identifiers are unique. That can be achieved simply by assigning license identifiers that do not collide. No LicenseRef- period namespace period hyphen is necessary as long as license list curators create license identifiers that have not already been registered. The proposed annex contains: In order for a namespace to be usable in custom license identifiers, it must be registered with the SPDX project. The registration request must provide the namespace and the SPDX document defining the licenses. The trivial replacement is: In order for a license list to be usable as a source of license identifiers, it must be registered with the SPDX project. The registration request must provide the SPDX document defining the licenses. There is no need for "custom license identifiers" or "namespaces". The policy requirement for accepting a curated license list from another organization is that it contains no previously-assigned license IDs. The SPDX legal team maintains the list of license lists, the maintainers of each sublist agree to check the composite list before creating a new license ID, and the SPDX legal team checks each sublist for compliance with that requirement before registering it. The whole namespace idea is predicated on the notion that commercial licenses are inferior to open-source licenses and must be branded with a "LicenseRef-" scarlet letter. There is no technical reason to do so; maintaining a composite list of IDs managed by cooperating organizations is trivial; each organization follows its own rules and processes for accepting a license; the only requirement is that IDs are unique. Dave On Sat, Jun 25, 2022 at 5:19 PM Gary O'Neall <[email protected] <mailto:[email protected]> > wrote: We’ll have a call limited to the namespace syntax immediately following the tech team call on Tuesday (10:30 AM Pacific Time, 17:30 GMT 28 June 2022) led by Alexios. Please review the current proposed syntaxes in the GitHub Pull Request: https://github.com/spdx/spdx-spec/pull/681 We will have a separate call to complete the policy discussions on Friday at the usual time (8:00 AM Pacific, 15:00 GMT 1 July 2022) led by the legal team (Steve and/or Jilayne). Both meetings will just the JITSI coordinates: <https://www.google.com/url?q=https://meet.jit.si/SPDXLegalMeeting&sa=D&source=calendar&usd=2&usg=AOvVaw1TC-8CRycE4-PwNqVo2W8X> https://meet.jit.si/SPDXLegalMeeting Dial-in: +1.512.647.1431 PIN: 3275 0470 68# If any policy decisions impact the syntax, we will revisit the syntax after the policy discussion on Friday. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4631): https://lists.spdx.org/g/Spdx-tech/message/4631 Mute This Topic: https://lists.spdx.org/mt/91991350/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
