public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: YunQiang Su <syq@debian.org>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
	 libc-alpha@sourceware.org
Subject: Re: [PATCH v3] MIPSr6/math: Use builtin fma and fmaf
Date: Sat, 8 Jun 2024 15:17:45 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2406081449030.9248@angie.orcam.me.uk> (raw)
In-Reply-To: <CAKcpw6UkysxBLgE6bVFQTxg_rQvySkQ=mNwUnHk7P9Ksae9-mQ@mail.gmail.com>

On Wed, 5 Jun 2024, YunQiang Su wrote:

> >  Doesn't this need a copyright notice?
> >
> 
> There is no copyright notice in any math-use-builtins-*.h.

 Existing files do not matter, it's the current interpretation of rules 
that does.  Correcting preexisting issues incurs effort someone has to 
undertake, so they may well stay around for a while; there are many of 
them.  New submissions need to be correct in all cases though.

> I guess that we treat them as so straight forward, thus no copyright
> notice is needed.

 And who decides that a piece of code is "straightforward"?  We currently 
have these rules written down:

--------------------------------------------------------------------------
4. Creating files

   * Don't create empty files
   * Find new versions of the copyright headers to use as a template.
   * Make sure the top line is descriptive.
   * "Contributed by" statements are no longer used.
--------------------------------------------------------------------------

I'd argue that iff a file consists solely of a #include_next directive, it 
might possibly skip the copyright header (though I think it would best be 
consulted by a lawyer anyway).  Otherwise if you argue that a piece of 
code is "straightforward" (i.e. legally insignificant, I suppose), then we 
need to draw a line somewhere.  We currently have it stated that:

"Copyright assignment for commulative [sic!] changes by any one author of 
less than 15 lines do not require copyright assignment."

so by extension you could argue that your submission only has 13 lines and 
therefore *by itself* is not legally significant.  Then if someone changes 
the file in the future so that it has at least 2 lines more, then it will 
be their responsibility to add the copyright notice header at that time.  
But it could be easy to miss.  And then should we remove the header again 
if the file has shrunk with a later update?

 I would argue that adding the the copyright notice right away is the 
correct approach in this case.

  Maciej

  reply	other threads:[~2024-06-08 14:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04  1:31 YunQiang Su
2024-06-04 18:00 ` Adhemerval Zanella Netto
2024-06-05 15:15   ` Maciej W. Rozycki
2024-06-05 15:26     ` YunQiang Su
2024-06-08 14:17       ` Maciej W. Rozycki [this message]
2024-06-09  6:43         ` YunQiang Su
2024-06-14 12:42           ` Adhemerval Zanella Netto
2024-06-14 13:06           ` Maciej W. Rozycki
2024-06-14  1:35   ` YunQiang Su
2024-06-24 17:45     ` [COMMITTED] " Andreas K. Hüttel
2024-06-24 22:55       ` Maciej W. Rozycki
2024-06-24 22:57         ` Andreas K. Huettel
2024-06-24 23:08         ` [REVERT] Revert "MIPSr6/math: Use builtin fma and fmaf" Andreas K. Hüttel
2024-06-06  7:07 ` [PATCH v3] MIPSr6/math: Use builtin fma and fmaf Philippe Mathieu-Daudé

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=alpine.DEB.2.21.2406081449030.9248@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=syq@debian.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).