Date   

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 SPDX
technical working group. There are definitely a number of issues and
considerations.

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.
To 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.

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-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
James Bottomley
Sent: Friday, June 5, 2020 9:08 AM
To: Max Mehl <max.mehl@...>; spdx-legal@...
Subject: Re: Correct handling of snippets

On Fri, 2020-06-05 at 16:15 +0200, Max Mehl wrote:
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"?
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



Re: Correct handling of snippets

James Bottomley
 

On Fri, 2020-06-05 at 16:15 +0200, Max Mehl wrote:
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"?
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@...>
 

Here a PR for the notes from the meeting:

https://github.com/spdx/meetings/pull/2

--V

On 2 Jun 2020, at 11:07, Steve Winslow <swinslow@...> wrote:

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
swinslow@...


Invitation: SPDX joint legal / tech team meeting @ Tue Jun 9, 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 Jun 9, 2020 1pm – 2pm Eastern Time - New York
Where
https://zoom.us/j/663426859 (map)
Calendar
spdx-legal@...
Who
(Guest list has been hidden at organizer's request)
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.


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.


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.


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

david.lebert.60@...
 

   donate


#spdx #spdx

david.lebert.60@...
 

     donate developpent


3.9 License List release

Steve Winslow
 

Hello all,

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

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

The release notes can be found at https://github.com/spdx/license-list-XML/releases/tag/v3.9

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,

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 documentation
software 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, provided
> that the above copyright notice appear in all copies and that both
> that copyright notice and this permission notice appear in supporting
> documentation.
X11 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






--
Steve Winslow
Director of Strategic Programs
The Linux Foundation


[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 documentation
software 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, provided
that the above copyright notice appear in all copies and that both
that copyright notice and this permission notice appear in supporting
documentation.
X11 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've
deprecated it.
The header quoted is fine.
Same goes for GPL-2.0 and the like.

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.
That'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:

I just got this note from one of my developers.

 

Is he correct? Should we or someone send a patch to Linux project?

 

..m

 

 

From: REDACTED

Sent: Tuesday, May 5, 2020 8:26 AM
To: Atwood, Mark <atwoodm@...>
Subject: Invalid SPDX identifier in Linux source tree

 

Mark,

Sorry for the delay, I'm long overdue in forwarding this to you.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c-dev.h

Contains the following invalid SPDX identifier:

/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */


The SPDX list of license identifiers (https://spdx.org/licenses/) does not include GPL-2.0+ in any form.  The closest would (presumably) be GPL-2.0-or-later.

---

 


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:

I just got this note from one of my developers.



Is he correct? Should we or someone send a patch to Linux project?



..m





From: REDACTED

Sent: Tuesday, May 5, 2020 8:26 AM
To: Atwood, Mark <atwoodm@...>
Subject: Invalid SPDX identifier in Linux source tree



Mark,

Sorry for the delay, I'm long overdue in forwarding this to you.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c-dev.h

Contains the following invalid SPDX identifier:

/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */


The SPDX list of license identifiers (https://spdx.org/licenses/) does not include GPL-2.0+ in any form. The closest would (presumably) be GPL-2.0-or-later.

---





--
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.



Is he correct? Should we or someone send a patch to Linux project?
No. Look again: GPL-2.0+ is right at the bottom of the list under
"Deprecated Licence Identifiers".

James

461 - 480 of 3280