Thanks Steve. I agree generally with your statement in this email and have added a comment to the PR. To be clear, this is a chance to the Annex on using SPDX license

Dear all, Unfortunately, I will not be able to make tomorrow's SPDX Legal Team meeting. In fact, I will not have an internet connection for the rest of the week, but I'll be back online next

If there is time left during the meeting on Thursday, we may also discuss the following issue (and I'd encourage folks to take a look and weigh in there as well): 3. Adding NONE to the License

Hi all, Our regularly-scheduled 4th Thursday meeting will be at the usual time this Thursday. There are two topics that I'd like us to discuss, as there has been active discussion on the issue threads

Thanks, Steve, for raising awareness! Unfortunately, I will not be able to join the Legal Team call this week (public holiday here in Germany), but I can participate in asynchronous discussions via

Hello spdx-legal team (cc spdx-tech team), Similar to my separate email earlier today, I'd also encourage interested folks to take a look at the draft annex in PR #464 at

Hello spdx-legal team (cc spdx-tech team), Some of you may recall the conversations in 2019 and 2020 around the idea of adding a "license namespace" concept to the SPDX spec. This was intended to be a

Hi, We have our regularly scheduled call today at noon Eastern US time. Tech Team Lead, Gary O'Neall, will be joining us to talk about the SPDX Online Tools!

Hello all, The version 3.17 release of the license list is now tagged and live at https://spdx.org/licenses. 5 new licenses were added to the

Thanks all for the confirmation to keep on keepin’ on with our current mode, then! J.

Am 02.05.22 um 13:43 schrieb Philippe Ombredanne: I stumbled across this rather by accident because I was looking for information on why NPM uses Artistic-2.0. Internet Archive does not provide much

Quoting Philippe Ombredanne (2022-05-02 13:43:56) Release notes for npm v2.14.13 contains the following: So seems to me (assuming licensing hasn't changed since v2.14.13) the command-line tool *is*

Hi Till: You have eagle eyes! <jaeger=jbb.de@...> wrote: This is IMHO a total and complete mess and non-sense, eventually non FOSS at all. Anyone from Microsoft or GitHub to fix this

Hi all, I noticed that NPM is using an Artistic-2.0 with additional terms and conditions: ----------------- npm License Copyright (c) npm, Inc. and Contributors All rights reserved. npm is

I agree here. I think semvar's notions are an imperfect fit for the nature of the license repo. We've selected major number to indicate a format (which one could argue is the semantic element that

Hi Steve, "Steve Winslow" <swinslow@...> writes: +1 -- semver is not really useful here, and 3.20 looks perfectly fine in the eyes of developers (and probably beyond.) All best, -- Bastien

Thanks all! One note just for consideration here: the version numbering for the License List has at least a syntactic meaning also within the spec itself, for SPDX documents: see

Dear Jilayne, Yes, I would say that's pretty normal for software projects. Incrementing the major version usually indicates that upgrading to that version would break something for existing users

I don’t think it’s an issue. To developers, 3.20 is normal and won’t be confused as 3.2. I would advocate moving to semantic versioning where it uses a triplet (e.g. 3.20.0) and each part of

Hi all, As I was adding milestones to the Github repo for the next couple releases, I wondered... do we just keep going with 3.18, 3.19, 3.20... (and 3.20 looks a lot like 3.2,