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