Date   

Re: Update on project: Validate license cross references

Mark D Baushke <mdb@...>
 

My comments are in-line. Look for MDB:

On Aug 9, 2020, at 12:33 PM, Smith Tanjong Agbor <stanjongagbor@...> wrote:

After discussing with mentors: Steve and Gary; we thought it wise to seek everyone's opinion on two topics:

1. Change back the isMatch field to Boolean(true/false)
In the previous email thread on this project; Michael Kaelbling suggested that the "isMatch" field value be changed from boolean to text; and the said value should contain the results of the comparison(between the license text in the xml and that in each of the crossref urls). He suggested that values could be:
  • verbatim
  • noassertion – if no test result is available (for invalid links perhaps)
  • todo – no match attempted
  • “” – no match asserted
  • verbatim2 – matches with \r == \r\n == \n
  • verbatim3 – matches “ignoring whitespace differences” reflowed text
  • verbatim4 – matches ignoring decoration (comments, flower-boxes)
  • template – matches template verbatim (see ppalaga’s comment)
  • et cetera as they become available
One of the issues we identified concerning this approach was
a. The above results are not mutually exclusive. Given that they are not mutually exclusive, we might be compelled to store those text values in a list.
ex: isMatch: [verbatim2, verbatim4, etc]
That said, we thought; do we need all that information? Aren't we over-engineering?

b. Is such detailed information necessary? Parsing this will entail knowing all possible values, and any update on this values will require updating the projects that parse this information.

So, we would like to know your thought process on this, and if storing this information is of utmost importance.

MDB

My opinion is that the isMatch operator should be true/false only.

I would also favor the addition of another operator with the name isValid for ensuring that the links exist.

If there is a need for the other functionality, then providing other operators may be desirable.

Perhaps isFuzzyMatch or listOfFuzzyMatches would deal with non-verbatim matches...

In the end, it is desirable if a producer of a package utilizing multiple license F/OSS elements is able to determine if the license is not able to comply with the source licenses if it were to be distributed (such as having something built from a GPLv2.0-only + Apache1.1 set of sources).

To get to that level of usefulness, one needs to know which licenses are equivalent via isMatch or other such idioms.
 

----------------------------------------------------------------------------------------------------------------------------

2. Html formatting of the details on the crossrefs
The progress I made on the project also concerned the html template(that is used to generate the spdx website) to display the license crossrefs details.
Here is the 0BSD license on the website(spdx.org)
<0BSD1.png>
and Here is the updated license I have locally, with the crossref details:
<0BSD2.png>
<0BSD3.png>

So the questions that popped up were the following:
  • Do we need all this information displayed on the website?
MDB

I do not believe the extra material is needed. However, if it is 'free' and accurate, I do not mind it being present.
  • Do we need the isWayBackLink parameter(wayback links can be identified visually already)
MDB

I am not a fan of information being only visible. I know of many people that are visually impaired, be it via being color blind or blind where funky icons hold no meaning whatever.

  • If the url is not valid, we should not make the url clickable(remove the link as an anchor tag)
MDB
It is better to not provide a link which is not able to be followed.
  • Can we use an accordion to display url details?
MDB
No thank you.
  • Could we use icons to indicate truth values of fields?

MDB
ICONS are mostly evil if they are the only providers of information.
They CAN provide additional information for some kinds of users
who are looking for patterns in the visual presentation, but generally
have problems when the display device is not the one used by the
original graphic designer. Hint: Look at the wide variation in display
on the various kinds of mobile devices as compared with a high resolution 
graphics monitor.


So, design experts' ideas are welcome on this topic.


MDB
I am NOT a design expert.

These were the two main topics that require your intervention and contributions.

MDB
Thank you for asking.

        Be safe, stay healthy,
        -- Mark



Update on project: Validate license cross references

Smith Tanjong Agbor
 

Hi everyone,

After discussing with mentors: Steve and Gary; we thought it wise to seek everyone's opinion on two topics:

1. Change back the isMatch field to Boolean(true/false)
In the previous email thread on this project; Michael Kaelbling suggested that the "isMatch" field value be changed from boolean to text; and the said value should contain the results of the comparison(between the license text in the xml and that in each of the crossref urls). He suggested that values could be:
  • verbatim
  • noassertion – if no test result is available (for invalid links perhaps)
  • todo – no match attempted
  • “” – no match asserted
  • verbatim2 – matches with \r == \r\n == \n
  • verbatim3 – matches “ignoring whitespace differences” reflowed text
  • verbatim4 – matches ignoring decoration (comments, flower-boxes)
  • template – matches template verbatim (see ppalaga’s comment)
  • et cetera as they become available
One of the issues we identified concerning this approach was
a. The above results are not mutually exclusive. Given that they are not mutually exclusive, we might be compelled to store those text values in a list.
ex: isMatch: [verbatim2, verbatim4, etc]
That said, we thought; do we need all that information? Aren't we over-engineering?

b. Is such detailed information necessary? Parsing this will entail knowing all possible values, and any update on this values will require updating the projects that parse this information.

So, we would like to know your thought process on this, and if storing this information is of utmost importance.

----------------------------------------------------------------------------------------------------------------------------

2. Html formatting of the details on the crossrefs
The progress I made on the project also concerned the html template(that is used to generate the spdx website) to display the license crossrefs details.
Here is the 0BSD license on the website(spdx.org)
0BSD1.png
and Here is the updated license I have locally, with the crossref details:
0BSD2.png
0BSD3.png

So the questions that popped up were the following:
  • Do we need all this information displayed on the website?
  • Do we need the isWayBackLink parameter(wayback links can be identified visually already)
  • If the url is not valid, we should not make the url clickable(remove the link as an anchor tag)
  • Can we use an accordion to display url details?
  • Could we use icons to indicate truth values of fields?

So, design experts' ideas are welcome on this topic.

These were the two main topics that require your intervention and contributions.


Thanks, 


Invitation: SPDX joint legal/tech team meeting @ Tue Aug 11, 2020 1pm - 2pm (EDT) (spdx-legal@lists.spdx.org)

Steve Winslow
 

You have been invited to the following event.

SPDX joint legal/tech team meeting

When
Tue Aug 11, 2020 1pm – 2pm Eastern Time - New York
Where
https://zoom.us/j/663426859 (map)
Calendar
spdx-legal@...
Who
swinslow@... - organizer
spdx-legal@...

On August 11, during the tech team's regular recurring call, we will hold a joint legal/tech team meeting. The primary focus will be to discuss proposed updates to the licensing-related fields in version 3.0 of the SPDX spec. Hope you can join us!



= = = = =



https://zoom.us/j/663426859
Meeting ID: 663 426 859

 Tuesdays at 17:00 UTC (and best guess for local time - 10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT, 18:00 WAT, 19:00 CEST).
 Australia +61 2 8015 2088
 Canada +1 647 558 0588
 Germany +49 30 3080 6188
 Japan +81 3 4578 1488
 US Toll-free 877 369 0926
 Find your local number: https://zoom.us/u/ac9KKJWzJT

Going (spdx-legal@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account spdx-legal@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


3.10 License List release

Steve Winslow
 

Hello all,

The version 3.10 release of the license list is now tagged and live at https://spdx.org/licenses.

This release included (as you’ll see below) a number of different variants on existing licenses, as well as a handful of new ones.

In addition to the new license entries and various cleanup, this release included a substantial rewrite of documentation about the workflow for adding new licenses. If you’re interested in participating in the process, please come join us!

20 new licenses were added to the list:

More details can be found in the release notes at https://github.com/spdx/license-list-XML/releases/tag/v3.10.

A big thank you to the participants in the SPDX Legal community and license request submitters who contributed to this release.

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: [spdx] SPDX license identifier for bzip2 are strange, why?

J Lovejoy
 

< bcc general list as FYI for anyone who wants to follow the discussion, but moving to legal list>

Quick search shows:
- both version were on the list when we moved to the XML format in 2016

However, I’m not clear on if that was both versions or what…

a ha! search on wiki meeting minutes then found this: https://wiki.spdx.org/view/Legal_Team/Minutes/2014-06-26
regarding diff b/w 1.0..5 and 1.0.6

we should check 1.0.7 and 8 against matching guidelines.

that’s all I have for now, it’s late.

higher power, eh? ;)


Cheers,
Jilayne

PS given this quick trip back in time at our process flow for new licenses back then… OMG, LOOK HOW FAR WE’VE COME!!!!


On Jul 29, 2020, at 12:38 PM, Mark Atwood via lists.spdx.org <atwoodm=amazon.com@...> wrote:

Hi!
 
I’ve started looking at the license and the SPDX identifiers on the “bzip2” project.
 
The license looks like a unsurprising BSD variant, but weirdly it’s been getting a versioned license ID with each release version.  The difference between two version seems to be entirely just the data and the software version.
 
Can this instead just match against one of the BSD variant templates?
 
Why does bzip2 get so finely versioned licensed identifiers?  Do we plan on created a new license identifier when bzip2 releases a version 1.0.9?
 
..m
 
 
Mark Atwood <atwoodm@...>
Principal, Open Source
+1-206-604-2198
 
 
 
From: Cressey, Ben <bcressey@...> 
Sent: Wednesday, July 29, 2020 11:03 AM
To: Atwood, Mark <atwoodm@...>
Cc: etaoin, iliana <iweller@...>
Subject: SPDX license identifier for bzip2
 
Hi Mark,
 
iliana suggested I run this by you, as a higher power in the SPDX org.
 
I’m looking to package bzip2 for Bottlerocket. It has an odd license that Fedora dubs “BSD” but which SPDX has a versioned license for:
 
The upstream author seems to revise the license with each new version, though 1.0.7 and 1.0.8 are close except for the date and version:
 
iliana recommended that I use the “bzip2-1.0.6” identifier for now.
 
Perhaps the author could be persuaded to tweak the license so that it doesn’t need a new SPDX identifier for every release? Maybe it doesn’t matter and 1.0.6 is close enough until they change the text in a significant way again?
 
Thanks,
Ben


Meeting this Thursday, July 30

Steve Winslow
 

Hello all,

The next regularly-scheduled SPDX legal team meeting will be tomorrow, Thursday, July 30, at 9AM PDT / noon EDT.

Tomorrow will be the last call before the 3.10 release, occurring Friday or this weekend. Any PRs for this release should be in by then, remaining issues will be bumped to 3.11 or later. Open issues tagged for 3.10 are at https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.10+release%22

Best,
Steve

= = = = =

Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln


--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: Correct handling of snippets

Max Mehl
 

~ Gary O'Neall [2020-07-28 02:41 +0200]:
1. We would both be fine with REUSE-Snippet-Begin, REUSE-SnippetBegin,
SPDX-Snippet-Begin or SPDX-SnippetBegin, and Snippet(-)End
respectively. Would SPDX want to introduce such a tag as an addition
to the existing Snippet information in the near future, or should
REUSE take the initiative here?
[G.O.] I personally would like to include this in the SPDX spec - we just need a volunteer to create an issue or (better yet) a pull request to update the Annex E Using SPDX license list short identifiers in source files (https://github.com/spdx/spdx-spec/blob/development/v2.2.1/chapters/using-SPDX-short-identifiers-in-source-files.md#annex-e-using-spdx-license-list-short-identifiers-in-source-files-informative). I would offer help on this, but I'm pretty busy with this year's Google Summer of Code and won't be able to help much for the next couple of months.

My preference would be SPDX-Snippet-Begin or SPDX-SnippetBegin.
Thank you! I've opened a Pull Request, but it only touches Annex E. I
wondered whether we also have to clarify other snippet specifics in
snippet-information.md subsequently, but see more here:

https://github.com/spdx/spdx-spec/pull/464

3. For license, we would prefer SPDX-License-Identifier. This is the tag
people use for declaring licensing of their files, but it could be
applicable for snippets as well, so in their enclosed context.

SPDX-LicenseInfoInSnippet might be the "official" way how to do it,
but to be brutally honest, I find this counter-intuitive and very
hard to memorise. I know that License-Identifier has become the
unloved child for a few people because of the lack of CamelCase and
clear context e.g. to files, but it's already out there, well-known,
and accepted. So I would suggest to use it for snippets as well.
[G.O] Is there a possible ambiguity of an SPDX-License-Identifier is associated with a file or a snippet?
For unaware tools, perhaps. They would detect that there are multiple
License-Identifiers (is this legal in SPDX?), but this way at least they
would know about the potentially differently licensed code in the file.

For tools, it should not be hard to detect whether License-Identifier is
inside a snippet or not. In my PR's description I explain why
"Snippet-License-Identifier" might be even more confusing to users.

Another question was raised regarding nesting of snippets, so the strange case
when a third-party code that I would like to use as a snippet would contain a
third-party snippet already. In this case, to also be compatible with the current
SPDX info on snippets, we would suggest to not allow nested snippets but
instead mandate that a snippet has to end in order for the next snippet to be
able to begin. Would you agree?
[G.O.] To be honest, I haven't considered the nesting of Snippets. Un-nested snippets are complex enough ;) In an SPDX document nesting is allowed since they are expressed with byte ranges and there is no rule to prevent nesting or even overlapping snippets. When marking snippets inline, it is a bit more challenging. I would definitely disallow overlapping snippets (e.g. Snippet A is lines 1 through 20 and Snippet B is lines 10 through 30). Nesting may be useful, however but it would significantly complicate the tooling. I don't feel strongly, but I tend to agree with the proposal that nesting not be allowed.
Great to know we're on the same page here then ;)

Best,
Max

--
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom: https://fsfe.org/join


SPDX online tools funding

J Lovejoy
 

Hey folks,

Gary has a CommunityBridge funding drive for the online SPDX tool. To support SPDX, an online tool has been developed which provides an easy all-in-one website to upload and parse SPDX documents for validation, comparison and conversion and search SPDX license list.

This project is to provide funding for hosting the online tools to make it freely available to the open source community. Basically, Gary has been hosting this himself for years. If we all pitch in, we can meet (and better yet, exceed) the goal and ensure funds to move it to proper hosting.

https://funding.communitybridge.org/projects/f0e320d6-9c86-4656-ad4d-97842f25b124

Cheers,
Jilayne


Re: Correct handling of snippets

Gary O'Neall
 

Hi Max,


1. We would both be fine with REUSE-Snippet-Begin, REUSE-SnippetBegin,
SPDX-Snippet-Begin or SPDX-SnippetBegin, and Snippet(-)End
respectively. Would SPDX want to introduce such a tag as an addition
to the existing Snippet information in the near future, or should
REUSE take the initiative here?
[G.O.] I personally would like to include this in the SPDX spec - we just need a volunteer to create an issue or (better yet) a pull request to update the Annex E Using SPDX license list short identifiers in source files (https://github.com/spdx/spdx-spec/blob/development/v2.2.1/chapters/using-SPDX-short-identifiers-in-source-files.md#annex-e-using-spdx-license-list-short-identifiers-in-source-files-informative). I would offer help on this, but I'm pretty busy with this year's Google Summer of Code and won't be able to help much for the next couple of months.

My preference would be SPDX-Snippet-Begin or SPDX-SnippetBegin.

2. For copyright, we would prefer SPDX-SnippetCopyrightText as an
equivalent to SPDX-FileCopyrightText
[G.O.] Agree

3. For license, we would prefer SPDX-License-Identifier. This is the tag
people use for declaring licensing of their files, but it could be
applicable for snippets as well, so in their enclosed context.

SPDX-LicenseInfoInSnippet might be the "official" way how to do it,
but to be brutally honest, I find this counter-intuitive and very
hard to memorise. I know that License-Identifier has become the
unloved child for a few people because of the lack of CamelCase and
clear context e.g. to files, but it's already out there, well-known,
and accepted. So I would suggest to use it for snippets as well.
[G.O] Is there a possible ambiguity of an SPDX-License-Identifier is associated with a file or a snippet?

Another question was raised regarding nesting of snippets, so the strange case
when a third-party code that I would like to use as a snippet would contain a
third-party snippet already. In this case, to also be compatible with the current
SPDX info on snippets, we would suggest to not allow nested snippets but
instead mandate that a snippet has to end in order for the next snippet to be
able to begin. Would you agree?
[G.O.] To be honest, I haven't considered the nesting of Snippets. Un-nested snippets are complex enough ;) In an SPDX document nesting is allowed since they are expressed with byte ranges and there is no rule to prevent nesting or even overlapping snippets. When marking snippets inline, it is a bit more challenging. I would definitely disallow overlapping snippets (e.g. Snippet A is lines 1 through 20 and Snippet B is lines 10 through 30). Nesting may be useful, however but it would significantly complicate the tooling. I don't feel strongly, but I tend to agree with the proposal that nesting not be allowed.


Looking forward to your replies and a constructive discussion!

Best,
Max



[^1]: To James' concerns: I would like to ignore the potential license
compliance problems with snippets carrying incompatible licenses for this
thread. Let's discuss first how devs can actually communicate that they've
used a third-party snippet and under which conditions, before we think about
how compliance might have to be handled in various (edge) cases.

--
Max Mehl - Programme Manager - Free Software Foundation Europe Contact
and information: https://fsfe.org/about/mehl | @mxmehl Become a
supporter of software freedom: https://fsfe.org/join


Re: Correct handling of snippets

Max Mehl
 

Hi all,

At REUSE, we found some time to wrap our brains around this issue again.

~ Gary O'Neall [2020-06-05 19:58 +0200]:
You could use the SPDX term "LicenseInfoInSnippet" since you are
including the license information directly in the copied snippet.
I've always treated this similar to the declared license for packages.

In terms of marking the start and end of the snippet, I don't know of
any existing SPDX tags that would help. Within the SPDX document, we
use a byte range. This would be rather impractical within the file
containing the snippets. The proposal in the referenced thread of
using a tag at the start and end of the snippet range looks like it
would work.
Thanks for the suggestions. I think what we need is a consensus on 1.
how to mark the begin/end of a snippet, 2. how to mark copyright, and
3. how to mark the license of this snippet [^1].

1. We would both be fine with REUSE-Snippet-Begin, REUSE-SnippetBegin,
SPDX-Snippet-Begin or SPDX-SnippetBegin, and Snippet(-)End
respectively. Would SPDX want to introduce such a tag as an addition
to the existing Snippet information in the near future, or should
REUSE take the initiative here?

2. For copyright, we would prefer SPDX-SnippetCopyrightText as an
equivalent to SPDX-FileCopyrightText

3. For license, we would prefer SPDX-License-Identifier. This is the tag
people use for declaring licensing of their files, but it could be
applicable for snippets as well, so in their enclosed context.

SPDX-LicenseInfoInSnippet might be the "official" way how to do it,
but to be brutally honest, I find this counter-intuitive and very
hard to memorise. I know that License-Identifier has become the
unloved child for a few people because of the lack of CamelCase and
clear context e.g. to files, but it's already out there, well-known,
and accepted. So I would suggest to use it for snippets as well.


Another question was raised regarding nesting of snippets, so the
strange case when a third-party code that I would like to use as a
snippet would contain a third-party snippet already. In this case, to
also be compatible with the current SPDX info on snippets, we would
suggest to not allow nested snippets but instead mandate that a snippet
has to end in order for the next snippet to be able to begin. Would you
agree?


Looking forward to your replies and a constructive discussion!

Best,
Max



[^1]: To James' concerns: I would like to ignore the potential license
compliance problems with snippets carrying incompatible licenses for
this thread. Let's discuss first how devs can actually communicate that
they've used a third-party snippet and under which conditions, before we
think about how compliance might have to be handled in various (edge)
cases.

--
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom: https://fsfe.org/join


Re: Update on project: Validate license cross references

Smith Tanjong Agbor
 

Hi everyone,

This is a follow-up email on my previous email titled: Update on project: Validate license cross references

Your contributions are welcome.

Thanks,
Smith

Le dim. 12 juil. 2020 à 19:34, Smith Tanjong Agbor <stanjongagbor@...> a écrit :
Hi everyone,

After discussing with mentors: Steve and Gary; we thought it wise to seek everyone's opinion on two topics:

1. Change back the isMatch field to Boolean(true/false)
In the previous email thread on this project; Michael Kaelbling suggested that the "isMatch" field value be changed from boolean to text; and the said value should contain the results of the comparison(between the license text in the xml and that in each of the crossref urls). He suggested that values could be:
  • verbatim
  • noassertion – if no test result is available (for invalid links perhaps)
  • todo – no match attempted
  • “” – no match asserted
  • verbatim2 – matches with \r == \r\n == \n
  • verbatim3 – matches “ignoring whitespace differences” reflowed text
  • verbatim4 – matches ignoring decoration (comments, flower-boxes)
  • template – matches template verbatim (see ppalaga’s comment)
  • et cetera as they become available
One of the issues we identified concerning this approach was
a. The above results are not mutually exclusive. Given that they are not mutually exclusive, we might be compelled to store those text values in a list.
ex: isMatch: [verbatim2, verbatim4, etc]
That said, we thought; do we need all that information? Aren't we over-engineering?

b. Is such detailed information necessary? Parsing this will entail knowing all possible values, and any update on this values will require updating the projects that parse this information.

So, we would like to know your thought process on this, and if storing this information is of utmost importance.

----------------------------------------------------------------------------------------------------------------------------

2. Html formatting of the details on the crossrefs
The progress I made on the project also concerned the html template(that is used to generate the spdx website) to display the license crossrefs details.
Here is the 0BSD license on the website(spdx.org)
0BSD1.png
and Here is the updated license I have locally, with the crossref details:
0BSD2.png
0BSD3.png

So the questions that popped up were the following:
  • Do we need all this information displayed on the website?
  • Do we need the isWayBackLink parameter(wayback links can be identified visually already)
  • If the url is not valid, we should not make the url clickable(remove the link as an anchor tag)
  • Can we use an accordion to display url details?
  • Could we use icons to indicate truth values of fields?

So, design experts' ideas are welcome on this topic.

These were the two main topics that require your intervention and contributions.


Thanks, 
Smith






Meeting this Thursday, July 16

Steve Winslow
 

Hello all,

The next regularly-scheduled SPDX legal team meeting will be this coming Thursday, July 16, at 9AM PDT / noon EDT.

For the agenda we will focus on the (many!) open issues for 3.10: https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.10+release%22. The target release date for 3.10 is July 31, and this will be the next-to-last call before then, so please get your PRs in if you're aiming to include them in this release.

Best,
Steve

= = = = =

Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Update on project: Validate license cross references

Smith Tanjong Agbor
 

Hi everyone,

After discussing with mentors: Steve and Gary; we thought it wise to seek everyone's opinion on two topics:

1. Change back the isMatch field to Boolean(true/false)
In the previous email thread on this project; Michael Kaelbling suggested that the "isMatch" field value be changed from boolean to text; and the said value should contain the results of the comparison(between the license text in the xml and that in each of the crossref urls). He suggested that values could be:
  • verbatim
  • noassertion – if no test result is available (for invalid links perhaps)
  • todo – no match attempted
  • “” – no match asserted
  • verbatim2 – matches with \r == \r\n == \n
  • verbatim3 – matches “ignoring whitespace differences” reflowed text
  • verbatim4 – matches ignoring decoration (comments, flower-boxes)
  • template – matches template verbatim (see ppalaga’s comment)
  • et cetera as they become available
One of the issues we identified concerning this approach was
a. The above results are not mutually exclusive. Given that they are not mutually exclusive, we might be compelled to store those text values in a list.
ex: isMatch: [verbatim2, verbatim4, etc]
That said, we thought; do we need all that information? Aren't we over-engineering?

b. Is such detailed information necessary? Parsing this will entail knowing all possible values, and any update on this values will require updating the projects that parse this information.

So, we would like to know your thought process on this, and if storing this information is of utmost importance.

----------------------------------------------------------------------------------------------------------------------------

2. Html formatting of the details on the crossrefs
The progress I made on the project also concerned the html template(that is used to generate the spdx website) to display the license crossrefs details.
Here is the 0BSD license on the website(spdx.org)
0BSD1.png
and Here is the updated license I have locally, with the crossref details:
0BSD2.png
0BSD3.png

So the questions that popped up were the following:
  • Do we need all this information displayed on the website?
  • Do we need the isWayBackLink parameter(wayback links can be identified visually already)
  • If the url is not valid, we should not make the url clickable(remove the link as an anchor tag)
  • Can we use an accordion to display url details?
  • Could we use icons to indicate truth values of fields?

So, design experts' ideas are welcome on this topic.

These were the two main topics that require your intervention and contributions.


Thanks, 
Smith






meeting minutes

J Lovejoy
 

Hi all,

I merged the minutes from the last 3 meetings: https://github.com/spdx/meetings/tree/master/legal

I also updated the wiki to remove the outdated conference call info and add a link to the new location for meeting minutes: https://wiki.spdx.org/view/Legal_Team

Jilayne



Meeting today, July 2

Steve Winslow
 

Hello all,

The next regularly-scheduled SPDX legal team meeting will be today, Thursday, July 2, at 9AM PDT / noon EDT.

For the agenda we will look briefly at:
1) PR #1048 -- adding the -invariants / -no-invariants options for GFDL licenses: https://github.com/spdx/license-list-XML/pull/1048
2) Issue #931 -- discuss questions raised by John regarding translations of CC licenses: https://github.com/spdx/license-list-XML/issues/931
3) Issue #1052 -- discuss clarifying documentation for license workflow process: https://github.com/spdx/license-list-XML/issues/1052

After that, we will review status updates on the various open issues for 3.10.

Best,
Steve

= = = = =

Join Zoom Meeting
https://zoom.us/j/611416785

Meeting ID: 611 416 785

One tap mobile
+16465588656,,611416785# US (New York)
+16699006833,,611416785# US (San Jose)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
        +1 647 558 0588 Canada
        855 703 8985 Canada Toll-free
Meeting ID: 611 416 785
Find your local number: https://zoom.us/u/aceZFvRyln


--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: ANTLR-PD

Till Jaeger
 

Thanks for discussing this issue. I agree that asking the ANTLR 2 people
might be helpful to learn more about the history of the license and what
they consider appropriate.

Best,

Till

Am 23.06.20 um 23:40 schrieb Alan Tse:

Why don’t we reach out since they’re the license steward to see if they’d
prefer an update vs two separate licenses?

 

*From: *<Spdx-legal@...> on behalf of Steve Winslow
<swinslow@...>
*Date: *Tuesday, June 23, 2020 at 2:00 PM
*To: *Bradlee Edmondson <brad.edmondson@...>
*Cc: *"jaeger@..." <jaeger@...>, SPDX-legal <Spdx-legal@...>
*Subject: *Re: ANTLR-PD

 

*CAUTION:**This email originated from outside of Western Digital. Do not
click on links or open attachments unless you recognize the sender and know
that the content is safe.*

 

Hi Brad, it's a good point and I was considering that too. I guess my one
question would be whether there are other projects that have used the
original vs. the later version of the license, beyond ANTLR.

 

Since it's the ANTLR project and the ANTLR-PD license, if they're the only
ones who have used it -- and if they're not even using it anymore for new
versions -- personally I'd feel comfortable with adding it via markup and
perhaps including an explanatory sentence in the Notes so that people are
aware. Rather than adding a new separate identifier. But this is just a gut
reaction, I don't feel especially strongly about it. Open to others'
thoughts of course  :)

 

Best,

Steve

 

On Tue, Jun 23, 2020 at 4:42 PM Brad Edmondson <brad.edmondson@...
<mailto:brad.edmondson@...>> wrote:

Thanks Till for reporting the issue and Steve for looking into it.

 

My first reaction would be that the two texts, ANTLR with additional
license and ANTLR without, are legally different licenses (with
different effects which are important for the reasons Till mentioned),
and should therefore be added as a new version of the ANTLR license
rather than added as optional matching text to the original.

 

What do others think?

 

Best,

Brad

--

Brad Edmondson, /Esq./
512-673-8782 | brad.edmondson@... <mailto:brad.edmondson@...>

 

 

On Tue, Jun 23, 2020 at 8:36 AM Steve Winslow
<swinslow@... <mailto:swinslow@...>> wrote:

Hi Till -- taking a closer look, it seems that the language you
cited was added to the original ANTLR 2 license sometime later,
which is probably why it isn't in the license list version.

 

Looking at the Wayback Machine,
http://web.archive.org/web/20130401024631/https://www.antlr2.org/license.html
<http://web.archive.org/web/20130401024631/https:/www.antlr2.org/license.html>
shows that at least as of April 2013 the ANTLR 2 License did not
include that additional paragraph. I haven't done a deeper dive yet
to figure out when it was subsequently added.

 

Given that, I'd be inclined to add it to the ANTLR-PD markup but to
mark it as optional, so that it would match whether or not that
paragraph is present.

 

Thanks,

Steve

 

On Tue, Jun 23, 2020 at 8:33 AM Steve Winslow via lists.spdx.org
<http://lists.spdx.org> <swinslow=linuxfoundation.org@...
<mailto:linuxfoundation.org@...>> wrote:

Thanks for flagging this, Till. I've added an issue in the
license-list-XML repo to track this at
https://github.com/spdx/license-list-XML/issues/1056.

 

I don't know the history of this one myself, but it looks like
that language had been omitted prior to when the license list
was first brought into source control (see
https://github.com/spdx/license-list-XML/commits/master/src/ANTLR-PD.xml).
I expect it should be added into the ANTLR-PD markup for the
reasons you mentioned.

 

Best,

Steve

 

On Tue, Jun 23, 2020 at 5:33 AM Till Jaeger via lists.spdx.org
<http://lists.spdx.org> <jaeger=jbb.de@...
<mailto:jbb.de@...>> wrote:

Hello list,

I just found out that there is a deviation from
https://spdx.org/licenses/ANTLR-PD.html#licenseText to the
linked text from
http://www.antlr2.org/license.html which contains the
following language:

"In countries where the Public Domain status of the work may
not be valid,
the author grants a copyright licence to the general public
to deal in the
work without restriction and permission to sublicence
derivates under the
terms of any (OSI approved) Open Source licence."

From the perspective from EU law this is an extremely
important part since
it makes clear that a unrestricted license is intended if PD
does not work.
This avoids (always disputable) interpretation of the PD text.

Is there any reason for the omission? Could the text be added?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB
Christinenstraße 18/19 | 10119 Berlin
Tel. +49.30.443 765 0  |  Fax +49.30.443 765 22
Sitz der Gesellschaft: Berlin | Registergericht AG
Charlottenburg | PR 609 B
www.jbb.de <http://www.jbb.de>




--

Steve Winslow
Director of Strategic Programs
The Linux Foundation

swinslow@... <mailto:swinslow@...>



--

Steve Winslow
Director of Strategic Programs
The Linux Foundation

swinslow@... <mailto:swinslow@...>



--

Steve Winslow
Director of Strategic Programs
The Linux Foundation

swinslow@... <mailto:swinslow@...>


Re: ANTLR-PD

Alan Tse
 

Why don’t we reach out since they’re the license steward to see if they’d prefer an update vs two separate licenses?

 

From: <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...>
Date: Tuesday, June 23, 2020 at 2:00 PM
To: Bradlee Edmondson <brad.edmondson@...>
Cc: "jaeger@..." <jaeger@...>, SPDX-legal <Spdx-legal@...>
Subject: Re: ANTLR-PD

 

CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.

 

Hi Brad, it's a good point and I was considering that too. I guess my one question would be whether there are other projects that have used the original vs. the later version of the license, beyond ANTLR.

 

Since it's the ANTLR project and the ANTLR-PD license, if they're the only ones who have used it -- and if they're not even using it anymore for new versions -- personally I'd feel comfortable with adding it via markup and perhaps including an explanatory sentence in the Notes so that people are aware. Rather than adding a new separate identifier. But this is just a gut reaction, I don't feel especially strongly about it. Open to others' thoughts of course  :)

 

Best,

Steve

 

On Tue, Jun 23, 2020 at 4:42 PM Brad Edmondson <brad.edmondson@...> wrote:

Thanks Till for reporting the issue and Steve for looking into it.

 

My first reaction would be that the two texts, ANTLR with additional license and ANTLR without, are legally different licenses (with different effects which are important for the reasons Till mentioned), and should therefore be added as a new version of the ANTLR license rather than added as optional matching text to the original.

 

What do others think?

 

Best,

Brad

--

Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...

 

 

On Tue, Jun 23, 2020 at 8:36 AM Steve Winslow <swinslow@...> wrote:

Hi Till -- taking a closer look, it seems that the language you cited was added to the original ANTLR 2 license sometime later, which is probably why it isn't in the license list version.

 

Looking at the Wayback Machine, http://web.archive.org/web/20130401024631/https://www.antlr2.org/license.html shows that at least as of April 2013 the ANTLR 2 License did not include that additional paragraph. I haven't done a deeper dive yet to figure out when it was subsequently added.

 

Given that, I'd be inclined to add it to the ANTLR-PD markup but to mark it as optional, so that it would match whether or not that paragraph is present.

 

Thanks,

Steve

 

On Tue, Jun 23, 2020 at 8:33 AM Steve Winslow via lists.spdx.org <swinslow=linuxfoundation.org@...> wrote:

Thanks for flagging this, Till. I've added an issue in the license-list-XML repo to track this at https://github.com/spdx/license-list-XML/issues/1056.

 

I don't know the history of this one myself, but it looks like that language had been omitted prior to when the license list was first brought into source control (see https://github.com/spdx/license-list-XML/commits/master/src/ANTLR-PD.xml). I expect it should be added into the ANTLR-PD markup for the reasons you mentioned.

 

Best,

Steve

 

On Tue, Jun 23, 2020 at 5:33 AM Till Jaeger via lists.spdx.org <jaeger=jbb.de@...> wrote:

Hello list,

I just found out that there is a deviation from
https://spdx.org/licenses/ANTLR-PD.html#licenseText to the linked text from
http://www.antlr2.org/license.html which contains the following language:

"In countries where the Public Domain status of the work may not be valid,
the author grants a copyright licence to the general public to deal in the
work without restriction and permission to sublicence derivates under the
terms of any (OSI approved) Open Source licence."

From the perspective from EU law this is an extremely important part since
it makes clear that a unrestricted license is intended if PD does not work.
This avoids (always disputable) interpretation of the PD text.

Is there any reason for the omission? Could the text be added?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB
Christinenstraße 18/19 | 10119 Berlin
Tel. +49.30.443 765 0  |  Fax +49.30.443 765 22
Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
www.jbb.de




--

Steve Winslow
Director of Strategic Programs
The Linux Foundation



--

Steve Winslow
Director of Strategic Programs
The Linux Foundation



--

Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: ANTLR-PD

Steve Winslow
 

Hi Brad, it's a good point and I was considering that too. I guess my one question would be whether there are other projects that have used the original vs. the later version of the license, beyond ANTLR.

Since it's the ANTLR project and the ANTLR-PD license, if they're the only ones who have used it -- and if they're not even using it anymore for new versions -- personally I'd feel comfortable with adding it via markup and perhaps including an explanatory sentence in the Notes so that people are aware. Rather than adding a new separate identifier. But this is just a gut reaction, I don't feel especially strongly about it. Open to others' thoughts of course  :)

Best,
Steve


On Tue, Jun 23, 2020 at 4:42 PM Brad Edmondson <brad.edmondson@...> wrote:
Thanks Till for reporting the issue and Steve for looking into it.

My first reaction would be that the two texts, ANTLR with additional license and ANTLR without, are legally different licenses (with different effects which are important for the reasons Till mentioned), and should therefore be added as a new version of the ANTLR license rather than added as optional matching text to the original.

What do others think?

Best,
Brad
--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...


On Tue, Jun 23, 2020 at 8:36 AM Steve Winslow <swinslow@...> wrote:
Hi Till -- taking a closer look, it seems that the language you cited was added to the original ANTLR 2 license sometime later, which is probably why it isn't in the license list version.

Looking at the Wayback Machine, http://web.archive.org/web/20130401024631/https://www.antlr2.org/license.html shows that at least as of April 2013 the ANTLR 2 License did not include that additional paragraph. I haven't done a deeper dive yet to figure out when it was subsequently added.

Given that, I'd be inclined to add it to the ANTLR-PD markup but to mark it as optional, so that it would match whether or not that paragraph is present.

Thanks,
Steve

On Tue, Jun 23, 2020 at 8:33 AM Steve Winslow via lists.spdx.org <swinslow=linuxfoundation.org@...> wrote:
Thanks for flagging this, Till. I've added an issue in the license-list-XML repo to track this at https://github.com/spdx/license-list-XML/issues/1056.

I don't know the history of this one myself, but it looks like that language had been omitted prior to when the license list was first brought into source control (see https://github.com/spdx/license-list-XML/commits/master/src/ANTLR-PD.xml). I expect it should be added into the ANTLR-PD markup for the reasons you mentioned.

Best,
Steve

On Tue, Jun 23, 2020 at 5:33 AM Till Jaeger via lists.spdx.org <jaeger=jbb.de@...> wrote:
Hello list,

I just found out that there is a deviation from
https://spdx.org/licenses/ANTLR-PD.html#licenseText to the linked text from
http://www.antlr2.org/license.html which contains the following language:

"In countries where the Public Domain status of the work may not be valid,
the author grants a copyright licence to the general public to deal in the
work without restriction and permission to sublicence derivates under the
terms of any (OSI approved) Open Source licence."

From the perspective from EU law this is an extremely important part since
it makes clear that a unrestricted license is intended if PD does not work.
This avoids (always disputable) interpretation of the PD text.

Is there any reason for the omission? Could the text be added?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB
Christinenstraße 18/19 | 10119 Berlin
Tel. +49.30.443 765 0  |  Fax +49.30.443 765 22
Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
www.jbb.de





--
Steve Winslow
Director of Strategic Programs
The Linux Foundation



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: ANTLR-PD

Brad Edmondson
 

Thanks Till for reporting the issue and Steve for looking into it.

My first reaction would be that the two texts, ANTLR with additional license and ANTLR without, are legally different licenses (with different effects which are important for the reasons Till mentioned), and should therefore be added as a new version of the ANTLR license rather than added as optional matching text to the original.

What do others think?

Best,
Brad
--
Brad Edmondson, Esq.
512-673-8782 | brad.edmondson@...


On Tue, Jun 23, 2020 at 8:36 AM Steve Winslow <swinslow@...> wrote:
Hi Till -- taking a closer look, it seems that the language you cited was added to the original ANTLR 2 license sometime later, which is probably why it isn't in the license list version.

Looking at the Wayback Machine, http://web.archive.org/web/20130401024631/https://www.antlr2.org/license.html shows that at least as of April 2013 the ANTLR 2 License did not include that additional paragraph. I haven't done a deeper dive yet to figure out when it was subsequently added.

Given that, I'd be inclined to add it to the ANTLR-PD markup but to mark it as optional, so that it would match whether or not that paragraph is present.

Thanks,
Steve

On Tue, Jun 23, 2020 at 8:33 AM Steve Winslow via lists.spdx.org <swinslow=linuxfoundation.org@...> wrote:
Thanks for flagging this, Till. I've added an issue in the license-list-XML repo to track this at https://github.com/spdx/license-list-XML/issues/1056.

I don't know the history of this one myself, but it looks like that language had been omitted prior to when the license list was first brought into source control (see https://github.com/spdx/license-list-XML/commits/master/src/ANTLR-PD.xml). I expect it should be added into the ANTLR-PD markup for the reasons you mentioned.

Best,
Steve

On Tue, Jun 23, 2020 at 5:33 AM Till Jaeger via lists.spdx.org <jaeger=jbb.de@...> wrote:
Hello list,

I just found out that there is a deviation from
https://spdx.org/licenses/ANTLR-PD.html#licenseText to the linked text from
http://www.antlr2.org/license.html which contains the following language:

"In countries where the Public Domain status of the work may not be valid,
the author grants a copyright licence to the general public to deal in the
work without restriction and permission to sublicence derivates under the
terms of any (OSI approved) Open Source licence."

From the perspective from EU law this is an extremely important part since
it makes clear that a unrestricted license is intended if PD does not work.
This avoids (always disputable) interpretation of the PD text.

Is there any reason for the omission? Could the text be added?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB
Christinenstraße 18/19 | 10119 Berlin
Tel. +49.30.443 765 0  |  Fax +49.30.443 765 22
Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
www.jbb.de





--
Steve Winslow
Director of Strategic Programs
The Linux Foundation



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


Re: ANTLR-PD

Steve Winslow
 

Hi Till -- taking a closer look, it seems that the language you cited was added to the original ANTLR 2 license sometime later, which is probably why it isn't in the license list version.

Looking at the Wayback Machine, http://web.archive.org/web/20130401024631/https://www.antlr2.org/license.html shows that at least as of April 2013 the ANTLR 2 License did not include that additional paragraph. I haven't done a deeper dive yet to figure out when it was subsequently added.

Given that, I'd be inclined to add it to the ANTLR-PD markup but to mark it as optional, so that it would match whether or not that paragraph is present.

Thanks,
Steve


On Tue, Jun 23, 2020 at 8:33 AM Steve Winslow via lists.spdx.org <swinslow=linuxfoundation.org@...> wrote:
Thanks for flagging this, Till. I've added an issue in the license-list-XML repo to track this at https://github.com/spdx/license-list-XML/issues/1056.

I don't know the history of this one myself, but it looks like that language had been omitted prior to when the license list was first brought into source control (see https://github.com/spdx/license-list-XML/commits/master/src/ANTLR-PD.xml). I expect it should be added into the ANTLR-PD markup for the reasons you mentioned.

Best,
Steve

On Tue, Jun 23, 2020 at 5:33 AM Till Jaeger via lists.spdx.org <jaeger=jbb.de@...> wrote:
Hello list,

I just found out that there is a deviation from
https://spdx.org/licenses/ANTLR-PD.html#licenseText to the linked text from
http://www.antlr2.org/license.html which contains the following language:

"In countries where the Public Domain status of the work may not be valid,
the author grants a copyright licence to the general public to deal in the
work without restriction and permission to sublicence derivates under the
terms of any (OSI approved) Open Source licence."

From the perspective from EU law this is an extremely important part since
it makes clear that a unrestricted license is intended if PD does not work.
This avoids (always disputable) interpretation of the PD text.

Is there any reason for the omission? Could the text be added?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB
Christinenstraße 18/19 | 10119 Berlin
Tel. +49.30.443 765 0  |  Fax +49.30.443 765 22
Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
www.jbb.de





--
Steve Winslow
Director of Strategic Programs
The Linux Foundation



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

421 - 440 of 3280