From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Sagar Patel <sagarmp@cs.unc.edu>, Nick Clifton <nickc@redhat.com>
Cc: Chenghua Xu <paul.hua.gm@gmail.com>, binutils@sourceware.org
Subject: Re: [committed v2] MIPS/opcodes: Fix alias annotation for branch instructions
Date: Mon, 7 Mar 2022 11:51:57 +0000 (GMT) [thread overview]
Message-ID: <alpine.DEB.2.21.2203071140470.47558@angie.orcam.me.uk> (raw)
In-Reply-To: <CAMGmevD2bkunEuW5C=KvM6d6=3QaJL3WQzduF7+yv9DJkZbr4g@mail.gmail.com>
On Mon, 7 Mar 2022, Sagar Patel wrote:
> > NB I can see you have not contributed before and your patch is very
> > small, affecting 4 lines of code only, which qualifies as not a legally
> > significant change. If you wish to continue contributing to binutils
> > project however, then please consider getting a copyright assignment
> > signed with FSF, as this will allow you to make changes beyond the limit
> > of ~15 lines of code total, which these 4 lines count against too. Nick,
> > the head binutils maintainer (cc-ed), will get you introduced if you would
> > like to follow this path.
>
> I have another patch that has a larger diff teed up, so I guess I'll
> need to look into copyright assignment. Is there an easy way to assign
> copyright as changes are submitted, instead of assigning it for all
> future changes?
You can certainly assign copyright for individual changes only, however
FSF has not traditionally been particularly swift handling paperwork, so
it may not be the most efficient and the least frustrating way of doing
things.
From my engineer's point of view the easiest way not to assign copyright
for any future changes is not to submit them in the first place, and that
works equally well with the standard copyright assignment. I guess
lawyers can have a different view though. I think you can withdraw an
assignment already in place at any time too.
> It would be great if this project could drop the copyright assignment
> requirement like gcc [1]. This would certainly reduce friction in the
> process of contributing. (I know you're probably not the person that
> makes these decisions. Just putting this out there.)
I do not know if any decision WRT the copyright policy for binutils will
be unilateral or consensus-based (probably the latter, in which case I
will most likely have a chance to speak out), but in any case Nick will
be the best person to tell. Nick?
Maciej
next prev parent reply other threads:[~2022-03-07 11:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 18:32 Maciej W. Rozycki
2022-03-07 7:13 ` Sagar Patel
2022-03-07 11:51 ` Maciej W. Rozycki [this message]
2022-03-07 12:50 ` Nick Clifton
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.2203071140470.47558@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
--cc=paul.hua.gm@gmail.com \
--cc=sagarmp@cs.unc.edu \
/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).