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
next prev parent 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).