public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: newlib@sourceware.org
Cc: John Scott <jscott@posteo.net>
Subject: Re: (was: Newlib copyright review) and SPDX tagging to REUSE spec RFC
Date: Fri, 11 Aug 2023 17:29:53 -0600	[thread overview]
Message-ID: <37a58be8-9aa4-c7ea-b814-fe2b89517bad@Shaw.ca> (raw)
In-Reply-To: <CAF9ehCWvoTOeNqksERdML1mO2J5pS259X4q+PpWh_B_V2snQ6w@mail.gmail.com>

On 2023-08-11 16:18, Joel Sherrill wrote:
> On Fri, Aug 11, 2023 at 1:23 PM Brian Inglis wrote:
>> 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
>> them?
>>
>> 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.

> Thanks for the great questions Brian. We have been adding SPDX annotation to 
> RTEMS source code but have not used any tooling yet. I'm hoping to learn 
> from this  process. Hopefully Scott doesn't mind educating as the process
> works through.

Ditto for Cygwin but we are using some tooling on package builds, checkins 
running CI, and package uploads.

One issue to address may be newlib prohibiting GPL and Cygwin being licensed 
under it within the same repo.

Noticed FreeBSD imports for newlib and Cygwin and recent checkins are annotated:

https://sourceware.org/git/?p=newlib-cygwin.git&a=search&h=HEAD&st=pickaxe&s=SPDX-License-Identifier%3A

and noticed the first licence in COPYING.NEWLIB may cause problems, as "Red Hat" 
is a trademark used in the copyright of these files, so the Red Hat trademark 
restriction may make it non-free for SPDX but IANAL:

(1) Red Hat Incorporated

Copyright (c) 1994-2009  Red Hat, Inc. All rights reserved.

"This copyrighted material is made available to anyone wishing to use,
modify, copy, or redistribute it subject to the terms and conditions
of the BSD License. This program is distributed in the hope that
it will be useful, but WITHOUT ANY WARRANTY expressed or implied,
including the implied warranties of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. A copy of this license is available at
http://www.opensource.org/licenses. *Any Red Hat trademarks that are
incorporated in the source code or documentation are not subject to
the BSD License and may only be used or replicated with the express
permission of Red Hat, Inc.*"

whereas other RH documents explicitly say "If the document is modified, all Red 
Hat trademarks must be removed." which may imply any use of the words "Red Hat"?

-- 
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 23:29 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 ` (was: Newlib copyright review) and SPDX tagging to REUSE spec RFC Brian Inglis
2023-08-11 22:18   ` Joel Sherrill
2023-08-11 23:29     ` Brian Inglis [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=37a58be8-9aa4-c7ea-b814-fe2b89517bad@Shaw.ca \
    --to=brian.inglis@shaw.ca \
    --cc=jscott@posteo.net \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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