From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 1A981385841F for ; Mon, 7 Mar 2022 11:51:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A981385841F 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 Received: by angie.orcam.me.uk (Postfix, from userid 500) id A8BD392009C; Mon, 7 Mar 2022 12:51:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id A319192009B; Mon, 7 Mar 2022 11:51:57 +0000 (GMT) Date: Mon, 7 Mar 2022 11:51:57 +0000 (GMT) From: "Maciej W. Rozycki" To: Sagar Patel , Nick Clifton cc: Chenghua Xu , binutils@sourceware.org Subject: Re: [committed v2] MIPS/opcodes: Fix alias annotation for branch instructions In-Reply-To: Message-ID: References: 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=-1162.8 required=5.0 tests=BAYES_00, 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 11:52:00 -0000 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