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

On Sun, 9 Jun 2024, YunQiang Su wrote:

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

 It's the copyright law that matters, not your judgement, I'm afraid.

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

 Maybe, maybe not, ultimately it would have to be taken to a court of law 
to know for sure.  But in any case transforming documentation into code is 
creative work and therefore in principle covered by copyright law.  And 
this piece could be written in different ways.

 Hence in my opinion it is not clear that it is trivial and in any case 
adding a copyright header makes no harm, but makes it clear to the reader 
what the intent of the copyright holder (in this case FSF) has been when 
it comes to the terms of use of this piece.

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

 If you assert that this piece of work is trivial, then they can well 
trivially recreate it from documentation rather than copying from our 
sources, so what's the problem with having a copyright notice?

  Maciej

  parent reply	other threads:[~2024-06-14 13:06 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
2024-06-14 13:06           ` Maciej W. Rozycki [this message]
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=alpine.DEB.2.21.2406141345370.9248@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --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).