Re: Correct handling of snippets
James Bottomley
On Fri, 2020-06-05 at 10:58 -0700, Gary O'Neall wrote:
We spent quite a bit of time discussing snippets in the SPDXTo be clear: I'm agnostic about identifying snippets in a fixed work. REUSE looks to be trying to apply snippets to living open source code and the case that specifically concerns me is where the snippet is under a different, but compatible, licence from the main file. How is the case where a contribution modifies the snippet and thus changes the licence supposed to be handled? James
|
||||||||||
|
||||||||||
Re: Correct handling of snippets
Gary O'Neall
We spent quite a bit of time discussing snippets in the SPDX technical working group. There are definitely a number of issues and considerations.
toggle quoted messageShow quoted text
At the conclusion of the discussions, there was a consensus that denoting snippets in an SPDX document was required for several use cases and was a common scenario in JavaScript / Node environments. 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. Gary
-----Original Message-----
|
||||||||||
|
||||||||||
Re: Correct handling of snippets
James Bottomley
On Fri, 2020-06-05 at 16:15 +0200, Max Mehl wrote:
Hi all,I really think this is a recipe for disaster. What's wrong with simply keeping the licence of the file? since to be contributed, the snippet must be compatible with it. To put it another way, why treat a snippet (a cut and paste) differently from a usual contribution? If someone really wants to cut a function out of Linux and put it in BSD based on the theory that it's originally a snippet under a permissive licence, they'll have to do a lot of legal analysis anyway. The problem you'll run into if you track snippets differently is that once a snippet inside a file is modified, under the DCO the modifications are under the licence "of the file" not of the snippet, so the newly derived snippet is now unconditionally under the licence of the file and that would make any separate tracking of the snippet licence wrong unless someone manually keep it in sync, which is not a burden any maintainer wants. The way we handle explicitly allowing code to move from Linux to BSD (usually in the area of drivers) is to make the *file* licence dual GPLv2/BSD to it's unequivocally agreed that every contribution is under both licences and thus a cut and paste from anywhere in the file is OK to go under a sole BSD licensed project. James
|
||||||||||
|
||||||||||
Correct handling of snippets
Max Mehl
Hi all,
At REUSE, we currently discuss how to correctly handling snippets from a third party, potentially under a different license [^1]. Since we strive to make as much use of SPDX as possible, I wonder about how you would solve this. I saw that SPDX uses the following tags instead of FileCopyrightText and License-Identifier: * SPDX-SnippetCopyrightText: Foo Bar * SPDX-SnippetLicenseConcluded: CC-BY-SA-4.0 This raised a bunch of questions: * How would one mark the begin and end of a snippet? * "LicenseConcluded" is quite different from the well-known License-Identifier [^2], so not very intuitive for developers. Is there some kind of alias that people can use? * Is was asked how one could refer the source of the snippet. "SnippetLicenseComments"? Best, Max [^1]: https://lists.fsfe.org/pipermail/reuse/2020q1/000051.html [^2]: I am aware that SPDX favours camel-case tag names nowadays. -- 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: Meeting this Thursday, June 4 and joint legal/tech next Tuesday, June 9
VM Brasseur <vmb@...>
toggle quoted messageShow quoted text
On 2 Jun 2020, at 11:07, Steve Winslow <swinslow@...> wrote:
|
||||||||||
|
||||||||||
Invitation: SPDX joint legal / tech team meeting @ Tue Jun 9, 2020 1pm - 2pm (EDT) (spdx-legal@lists.spdx.org)
Steve Winslow
|
||||||||||
|
||||||||||
Meeting this Thursday, June 4 and joint legal/tech next Tuesday, June 9
Steve Winslow
Hello all, the next regularly-scheduled SPDX legal team meeting will be this Thursday, June 4 at 9AM PDT / noon EDT. The main focus will be to review the status of issues for 3.10 that were assigned out to folks at the last session, and to review which ones are ready for discussion vs. still in process. The currently-tagged 3.10 issues can be seen at: https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.10+release%22 If there is time, we will also have an initial discussion about some of the proposed changes to the licensing-related fields for the SPDX 3.0 spec that is now in process. The initial details of the current proposal from the tech team can be seen at https://github.com/spdx/spdx-spec/issues/385 Finally and on a related note, on next Tuesday, June 9, there will be a joint legal/tech team call during the tech team's usual meeting at 10AM PDT / 1PM EDT. I will send a separate invite to this list -- hope you are able to join, as we'll be discussing the same proposed fields for SPDX 3.0. 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
|
||||||||||
|
||||||||||
License of an open source license text
Richard Purdie
Hi,
I work on the Yocto Project and we use SDPX identifiers when working with open source licenses. An issue has come up and it was suggested I ask about it here. The question is quite simple: Which licence are we using when we share just the license text? The background is more complex: YP has some software which is under "LGPL-2.1 and GPL-3 and GPL-2" where one source file is v3, the rest are under other licenses. When we build that software, multiple binaries result, we group them into different packages and can be specific about which licences each binary is under. If no GPLv3 code is in there, it can be under the other licenses. We also put the license texts into its own package. Right now that package is licensed as "LGPL-2.1 and GPL-3 and GPL-2", the same as the overall license. The problem is if someone excludes GPL-3 from their images, they can exclude specific packages but they also exclude the license package which isn't what they want. If the license text is under GPL-3 then this is unfortunate but we could just have to tell people to live with that. If it isn't but is under a different license (or a subset of it), what license do we put down for that package? I don't believe there is no SPDX identifier we can use? To be clear, we don't want to modify the license itself but want to list something in the license field of our binary package which says what its license is. Another way of putting is what is the license identifier for: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." (quoted from the GPL) Cheers, Richard
|
||||||||||
|
||||||||||
Meeting this Thursday, May 21
Steve Winslow
Hello all, the next regularly-scheduled SPDX legal team meeting will be Thursday, May 21 at 9AM PDT / noon EDT. Now that 3.9 has been released, there's a few things I'm hoping to focus on for this next meeting: 1) Assign out the current 3.10 issues to participants -- asking each attendee to take one or two issues, read them, and plan to propose a yes / no / "it's complicated" outcome on the subsequent call in a couple of weeks. 2) Review the "Later Release" issues and decide whether to pull them into 3.10, close them, or leave them as "Later Release". 3) If we have time, begin discussing #970, license expression syntax for selecting options: see https://github.com/spdx/license-list-XML/issues/970. This has implications for some other longstanding issues on the list, and could result in changes to the license expression syntax, which would be timely for the SPDX spec team's work on v3.0 of the spec. The currently-tagged 3.10 issues can be seen 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
|
||||||||||
|
||||||||||
#spdx
#spdx
|
||||||||||
|
||||||||||
#spdx
#spdx
|
||||||||||
|
||||||||||
3.9 License List release
Steve Winslow
Hello all, Along with the usual assortment of documentation updates and markup tweaks, this is the first release with the updated license inclusion principles. [1] 16 new licenses and exceptions were added to the list: * CAL-1.0 * CAL-1.0-Combined-Work-Exception * CERN-OHL-P-2.0 * CERN-OHL-S-2.0 * CERN-OHL-W-2.0 * Hippocratic-2.1 * LGPL-3.0-linking-exception * MulanPSL-2.0 * NCGL-UK-2.0 * O-UDA-1.0 * OGC-1.0 * Parity-7.0.0 * PolyForm-Noncommercial-1.0.0 * PolyForm-Small-Business-1.0.0 * SHL-2.0 * SHL-2.1 It looks like the release has gone fine in light of the updated SPDX website (details mentioned earlier this week). The only issue appears to be with the SPDX logo now not appearing on the license list pages, which I'm in the process of sorting out. If you see any other technical issues on the license list website, please feel free to let us know at https://github.com/spdx/spdx-website/issues. Many thanks to everyone who was involved with submitting licenses, reviewing submissions and creating PRs for this release. Best regards, Steve -- Steve Winslow Director of Strategic Programs The Linux Foundation
|
||||||||||
|
||||||||||
SPDX website updates
Steve Winslow
Hello SPDX community, This is a follow-up
from discussions on several of the SPDX general meetings and workgroup
calls over the past couple of months. The TL;DR version is:
More details are below for those who are interested. Thank you to everyone who was involved in assisting with the changeover. Best, Steve = = = The SPDX static website has previously been hosted on Drupal servers at https://spdx.org. This URL has also been used for hosting the files that are dynamically generated for the license list (https://spdx.org/licenses) and the RDF spec definition files (https://spdx.org/rdf/terms and other files under /rdf). The
Drupal servers have been planned for decommission, and we have migrated
the static website content over to Wordpress. Originally, we had
explored whether both the static and dynamically-generated content could
all remain at its existing URLs. However, this did not appear to be
reasonably doable without shifting the dynamic license list and RDF
content to separate subdomains. Because SPDX has committed to
maintaining the existing URLs for those files, we did not want to take
this approach. Instead, as mentioned above, the static content for the website has been shifted over to a new domain, https://spdx.dev. We have created redirects from the old spdx.org URLs over to the new corresponding pages at spdx.dev.
Because of this, URLs that you've bookmarked for the static site should
still get you to the right content. And URLs that you've bookmarked
for the license list and RDF definition files will remain the same, as
those are continuing to be hosted from spdx.org. You'll see that the content at the new https://spdx.dev
site is largely identical to the old site, although we have done some
reorganization of the top-level links to make the menu bar a bit more
usable. Now that the site transition is completed, we are looking to
make more updates to some of the content that has grown stale over time.
If you have suggestions or content you'd like to add or update, or if
you see bugs or errors on the website, please feel free to file an issue
at https://github.com/spdx/spdx-website/issues -- for the moment that is probably the easiest way to flag issues. -- Steve Winslow Director of Strategic Programs The Linux Foundation
|
||||||||||
|
||||||||||
Re: [new license request] The Open Group License
Steve Winslow
Hi Felicitas, thanks very much for your email. I've created an issue for your message in the repo at https://github.com/spdx/license-list-XML/issues/1026. Feel free to follow along and weigh in there as it is reviewed by the SPDX legal team participants. Best, Steve
On Tue, May 12, 2020 at 8:31 AM Felicitas Jung <f.jung@...> wrote: Hi,
|
||||||||||
|
||||||||||
[new license request] The Open Group License
Felicitas Jung
Hi,
while adding identifiers to licenses used in the BSP (note: i am a legal trainee, so wording may not be technical perfect), i stumbled upon the The Open Group License, which does not have an identifier yet. It is used in: xorg-app-iceauth, xorg-app-rgb, xorg-app-xauth, xorg- app-xdm, xorg-app-xinit, xorg-app-xprop, xorg-app-xrdb, xorg-app-xset, xorg-app-xsetroot, xorg-app-xvinfo (and maybe some more). The wording is consistent the following (copyright holder is always The Open Group): COPYING --- Copyright <yyyy, yyyy> <Copyright Holder> Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL <Copyright Holder> BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of <Copyright Holder> shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from <Copyright Holder>. --- The first paragraph is different from X11-License, therefore i do not want to use the X11-identifier: Permission to use, copy, modify, distribute,as in curl; no "including without limitation" like X11 and sell this software and its documentationsoftware and documentation are not together defined as "the software" and therefore more divided than in X11-License for any purpose is hereby granted without fee, providedX11 does not require appearance in documentation, but in substantial parts of software. I am hoping that you can add the License to the license list so it may gain an identifier. Thank you! Felicitas Jung
|
||||||||||
|
||||||||||
Meeting today, May 7
Steve Winslow
Hello all, the next regularly-scheduled SPDX legal team meeting will be today, Thursday, May 7 at 9AM PDT / noon EDT -- following the SPDX general meeting an hour earlier. This will be (for real this time) the last meeting before the expected 3.9 release of the license list which is aiming for next week. So the primary agenda item will be to discuss license requests currently tagged for 3.9, viewable at: https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.9+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: FW: Invalid SPDX identifier in Linux source tree
Max Mehl
~ Kate Stewart [2020-05-07 03:37 +0200]:
Kernel community still recognizes GPL-2.0+ as valid, although we'veSame goes for GPL-2.0 and the like. The conventions are documented in the kernel community trees, andThat's understandable, and a reasonable workflow. Is there any schedule for the completion of the addition of license identifiers and copyright notices? A quick `reuse lint` revealed the following stats: * Files with copyright information: 40292 / 67928 * Files with license information: 49815 / 67928 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
|
||||||||||
|
||||||||||
Re: FW: Invalid SPDX identifier in Linux source tree
Kate Stewart
Kernel community still recognizes GPL-2.0+ as valid, although we've deprecated it. The header quoted is fine. The conventions are documented in the kernel community trees, and the intention is when all the files have SPDX-License-Identifier, to do a global cleanup. Advice at this point is to stick with the pattern used in the kernel.
On Wed, May 6, 2020 at 8:22 PM Atwood, Mark <atwoodm@...> wrote:
|
||||||||||
|
||||||||||
Re: FW: Invalid SPDX identifier in Linux source tree
Richard Fontana
My understanding from being on the linux-spdx mailing list is that
this is intentionally tolerated for existing SPDX-License-Identifier notices because it was correct SPDX syntax under the earlier version of the SPDX spec. Richard On Wed, May 6, 2020 at 9:25 PM Mark Atwood via lists.spdx.org <atwoodm=amazon.com@...> wrote:
-- Richard Fontana Senior Commercial Counsel Red Hat, Inc. +1 212 689-4350 (mobile)
|
||||||||||
|
||||||||||
Re: FW: Invalid SPDX identifier in Linux source tree
James Bottomley
On Thu, 2020-05-07 at 01:21 +0000, Mark Atwood via lists.spdx.org
wrote: I just got this note from one of my developers.No. Look again: GPL-2.0+ is right at the bottom of the list under "Deprecated Licence Identifiers". James
|
||||||||||
|