From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 6A89A3858D20 for ; Sat, 8 Jun 2024 14:17:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A89A3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6A89A3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4190:8020::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717856268; cv=none; b=P5mU54cmDlFKs+uBqvpK5QuXcI8NB/fh+39ytSCE9IZ1yCwpMTOriA1LzfTdupV16ItjkItbca1NIJtxQqmZoaBYXNdo+aDusBJWpeD2IpT0vhzeW5Anc708s5dcosNZW/YY0hZ86S+RI/LuLJluullFXdn+alCdu1P7Bqi257g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717856268; c=relaxed/simple; bh=mhQ2UjvMAUpZYlT44zaaUpwqLQcQ7MJkyp+xvWI6pK8=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=k02FrfoWyljETLKtxQ00m00rNe4DdkqU8nIp8nL4LOXSCanFlBHKh4z28uwm1v0ywxgfyxzT2Ya0f2apGIViPTSjnF6JGwU0KX78AOHG17leROaiuBA1SO25FXqswehwbgExbGpTqRFIygoW3oNS50HycENLxlPAjCa5CTCbyao= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by angie.orcam.me.uk (Postfix, from userid 500) id 6850B92009C; Sat, 8 Jun 2024 16:17:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 6170392009B; Sat, 8 Jun 2024 15:17:45 +0100 (BST) Date: Sat, 8 Jun 2024 15:17:45 +0100 (BST) From: "Maciej W. Rozycki" To: YunQiang Su cc: Adhemerval Zanella Netto , libc-alpha@sourceware.org Subject: Re: [PATCH v3] MIPSr6/math: Use builtin fma and fmaf In-Reply-To: Message-ID: References: <20240604013119.79086-1-syq@debian.org> <3f878318-5afb-45cf-b85e-ff21df14aa20@linaro.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.0 required=5.0 tests=BAYES_00,KAM_ASCII_DIVIDERS,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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