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

Maciej W. Rozycki <macro@orcam.me.uk> 于2024年6月8日周六 22:17写道:
>
> 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."
>

I don't think that the line count is the most important: some code is
quite short
while its logic is quite complex.

For this patch, I don't think that it has logic at all. It is just a
statement about the
FMA support of MIPS ISA documents.
I mean I doubt whether it can be protected by copyright.

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

Personally, I don't think/wish a short and *non-logic* code can be protected
by copyright, as anybody who may do something for it will write the
almost same code.
I don't think that their work is a copy paste.

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

  reply	other threads:[~2024-06-09  6:44 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
2024-06-09  6:43         ` YunQiang Su [this message]
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=CAKcpw6WwFi7gMFaHFsRVeZnWMSM1K81LYuMfCt4S5JdVa2FWYw@mail.gmail.com \
    --to=syq@debian.org \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=macro@orcam.me.uk \
    /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).