|
Re: Update on project: Validate license cross references
Mark D Baushke <mdb@...>
My comments are in-line. Look for MDB:
MDB
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.
MDB
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.
MDB
It is better to not provide a link which is not able to be followed.
MDB
No thank you.
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.
MDB
I am NOT a design expert.
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:
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)  and Here is the updated license I have locally, with the crossref details:   So the questions that popped up were the following:
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
|
||||||||||||||
|
|
||||||||||||||
|
3.10 License List release
Steve Winslow
Hello all, 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>
toggle quoted messageShow quoted text
Quick search shows: - both version were on the list when we moved to the XML format in 2016 - email archive https://lists.spdx.org/g/Spdx-legal/topic/22080449#817 - shows discussion for zip in Feb 2014, added for v1.20 of the license list (also see: https://wiki.spdx.org/view/Legal_Team/License_List/Licenses_Under_Consideration#Licenses_Under_Consideration and https://wiki.spdx.org/view/Legal_Team/Minutes/2014-02-20 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!!!!
|
||||||||||||||
|
|
||||||||||||||
|
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]:
Thank you! I've opened a Pull Request, but it only touches Annex E. I1. We would both be fine with REUSE-Snippet-Begin, REUSE-SnippetBegin,[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. 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 For unaware tools, perhaps. They would detect that there are multiple3. For license, we would prefer SPDX-License-Identifier. This is the tag[G.O] Is there a possible ambiguity of an SPDX-License-Identifier is associated with a file or a snippet? 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. Great to know we're on the same page here then ;)Another question was raised regarding nesting of snippets, so the strange case[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. 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,
[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. [G.O.] Agree [G.O] Is there a possible ambiguity of an SPDX-License-Identifier is associated with a file or a snippet? [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.
|
||||||||||||||
|
|
||||||||||||||
|
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 areThanks 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 :
|
||||||||||||||
|
|
||||||||||||||
|
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:
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)  and Here is the updated license I have locally, with the crossref details:   So the questions that popped up were the following:
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
Thanks for discussing this issue. I agree that asking the ANTLR 2 people
toggle quoted messageShow quoted text
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
|
||||||||||||||
|
|
||||||||||||||
|
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@...>
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:
Steve Winslow
|
||||||||||||||
|
|
||||||||||||||
|
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:
|
||||||||||||||
|
|
||||||||||||||
|
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,
On Tue, Jun 23, 2020 at 8:36 AM Steve Winslow <swinslow@...> wrote:
|
||||||||||||||
|
|
||||||||||||||
|
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:
|
||||||||||||||
|
|
