public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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.

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