From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: YunQiang Su <syq@debian.org>, "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v3] MIPSr6/math: Use builtin fma and fmaf
Date: Fri, 14 Jun 2024 09:42:28 -0300 [thread overview]
Message-ID: <e28a1d0b-34cb-4441-9611-610100865cef@linaro.org> (raw)
In-Reply-To: <CAKcpw6WwFi7gMFaHFsRVeZnWMSM1K81LYuMfCt4S5JdVa2FWYw@mail.gmail.com>
On 09/06/24 03:43, YunQiang Su wrote:
> 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 agree that for this specific case, no math-use-builtins-*.h file have the
Copyright headers and require it for this patch does not seem productive. Maybe
a better approach would to send a subsequent patch to add the missing headers.
next prev parent reply other threads:[~2024-06-14 12:42 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
2024-06-14 12:42 ` Adhemerval Zanella Netto [this message]
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=e28a1d0b-34cb-4441-9611-610100865cef@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=macro@orcam.me.uk \
--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).