public inbox for
 help / color / mirror / Atom feed
From: Brian Inglis <>
Cc: John Scott <>
Subject: Re: (was: Newlib copyright review) and SPDX tagging to REUSE spec RFC
Date: Fri, 11 Aug 2023 12:23:41 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2023-08-11 06:14, John Scott wrote:
> I'm re-doing the packaging of Newlib for Debian, and that means I'm doing a full-blown copyright review where I'm recording the copyright holders and license terms for every last file. It would be a shame if folks in other distros had to duplicate my effort. I was thinking, if I'm going to be doing this anyway perhaps I can upstream my efforts and make Newlib comply with the REUSE specification?
> If you haven't heard of it, REUSE uses SPDX-FileCopyrightText and SPDX-License-Identifier to make all the copyright and license information machine-readable. It's a specification from the Free Software Foundation Europe. If you're okay with me doing this, please let me know whether you want these tags to replace the existing copyright and license notices, or to be in addition to them and tagged on to what's already there.
> If you're not interested, please let me know so I know to resume my efforts in Debian. But I'm offering to put in all of the work and since Newlib has so many different copyright holders and licenses it seems like you could really benefit.

You may want to resend this as a newlib RFC, similar to my subject change, 
adding some of the info below.

You could provide a few links to REUSE (try web searching that!) and SPDX 
materials to explain what you are doing to those who have not yet encountered 
the REUSE and SPDX projects and tools.

REUSE specifies the outdated 7 year old SPDX 2.1 spec: will newer versions 
(currently 2.3) be allowed and supported?
[SPDX are still discussing Data License which is a bone of contention for 
commercial contributors, of which there are many in newlib.]

Are you okay with providing your changes, including any REUSE and SPDX 
cataloguing documents you may create which apply to the project, under some 
non-GPL licence attribution, that allows the library to continue to be used by 
contributing and other corps for their commercial purposes?

Could you please outline any changes that you contemplate making to the document 
tree, such as LICENSES, REUSE, SPDX, etc. directory additions and likely contents?

Are you using one of the SPDX tools to match the licence texts, as the 
variations in BSD, MIT, and Verbatim licences can be confusing, and even when it 
states a name, it may be called something else by SPDX?

Could you please document the sources of these tools and how you intend to use 

What do you plan to do about uncatalogued licence texts: submit them to SPDX for 
review and (re-)naming, and/or just create a LicenseRef-Debian-NAME or 
(preferably?) LicenseRef-newlib-NAME or ExceptionRef-newlib-NAME placeholder?

Any other considerations from those involved in licensing and cataloguing?

Would probably be okay if you just added any SPDX-License-Identifier: ... below 
the existing licence text, then folks can see how it goes.

Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

  reply	other threads:[~2023-08-11 18:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11 12:14 Newlib copyright review John Scott
2023-08-11 18:23 ` Brian Inglis [this message]
2023-08-11 22:18   ` (was: Newlib copyright review) and SPDX tagging to REUSE spec RFC Joel Sherrill
2023-08-11 23:29     ` Brian Inglis
2023-08-12 19:05   ` John Scott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).