Hi all, did you know: „the and any this you license software for that not use with may code such agreement other terms under are rights work your all from shall source including copyright provided

Hi Sebastian, Sorry - I've been negligent at sending out the follow-up meeting information. I missed the end of last week's call, but I believe it was decided to not have a call this week due to the

Dear all, I thought there was supposed to be a Namespace Proposal meeting at this time today, but I've joined the video call and there are only a couple of others here. Best wishes, Sebastian

Hi all, With a conference going on and end of quarter, we’ll skip our call this week. Please have a look at any open GitHub issues in the meantime! Jilayne Sent from my phone, please excuse brevity

For three reasons: 1) efficiency - a 16 bit integer is sufficient to identify 65,000 licenses. CBOR uses variable-length encoding of integers (major type 0), and even in JSON a number (e.g. 942 -

[JL]: No, you are mistaken. I am not looking for a way to use LicenseRef-, because LicenseRef- uses "a different technical mechanism" for different licenses. Instead of jumping to the technical

(removing general mailing list and adding spdx-tech) David, A few clarifications below: Btw, you are not a member of the spdx-legal mailing list, so these emails keep bouncing. Could you please join

All, I strongly support Gary's approach of identifying requirements first, then identifying and selecting from technical solutions that meet all requirements. The requirements are: * The SPDX legal

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

Just a reminder, we will be continuing the License Namespace discussion this Friday (likely today by the time you get this email) at 15:00 UTC/8AM Pacific at the coordinates below:

Dear David: You are not interfering at all... and I found your reply and insights super useful. I do not know your background, but it is clear that you have experience in this domain. So please do

Hi David: Thank you for your detailed feedback. See some comments inline below: On Wed, Jun 15, 2022 at 12:16 AM David Kemp <dk190a@...> wrote: I am not sure I read you correctly but if are

Greetings SPDX Tech and Legal teams, Good discussion today, we were able to close on the problem statements and make progress on the next steps and namespace policies. Minutes from today’s

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

Here is an example license list: https://scancode-licensedb.aboutcode.org/ Regards, Dennis Clark

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

Hi all, We have our 2nd Thursday of the month meeting today in about 45' (at noon US eastern time). I think we ought to get back to some day-to-day items in terms of

Steve captures my same reactions well. From:Spdx-legal@... <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...> Date: Friday, June 3, 2022 at 6:16 PM To: Ria Schalnat (HPE)

Hi Sebastian, thanks for this — this is an interesting proposal! I want to give it some more thought, but here are a couple initial reactions: For MATCHES-LICENSE, I gather the idea is that this is

Dear Ria, Indeed, LEGALLY_EQUIVALENT_TO would express a legal interpretation made by the SPDX document productor (which could be the vendor of the software or a third party). Whether or not this is