On Tue, Dec 01 2020, Felipe Contreras wrote: > On Tue, Dec 1, 2020 at 3:51 AM Han-Wen Nienhuys <hanwen@xxxxxxxxxx> wrote: >> On Mon, Nov 30, 2020 at 10:21 PM Felipe Contreras >> <felipe.contreras@xxxxxxxxx> wrote: >> > On Mon, Nov 30, 2020 at 2:28 PM Han-Wen Nienhuys <hanwen@xxxxxxxxxx> wrote: > >> > Sounds to me Google has not made its mind about actually contributing >> > these changes. >> > >> > Or am I missing something? >> >> The restrictions are not about the patches themselves. They are about >> restricting what gets posted under github.com/google/ . > > I see. > > But it doesn't have to be posted on github.com/google/, it doesn't > have to be posted on github.com at all. If the code is under an open > source license, you (or anyone) can post it anywhere. The libgit2.git and git.git codebases are under different licenses. Therefore if the goal is to have code that's used in both it's not viable to e.g. store it in git.git under our current contribution policies. The first contributor to submit a fix to it under GPLv2 as opposed to "any GPL or LGPL version" or whatever will preclude its subsequent import into libgit2. Assigning copyright to Google is a way around that. They own your work, and then they re-license it under whatever license those two projects use. But as I pointed out in [1] it requires contributors to git.git's reftable/ directory & Junio to play along with that scheme, least the whole process come to a halt. Maybe that's worth it, maybe not. But seems like something the series should very explicitly highlight and document e.g. in Documentation/SubmittingPatches. We do have some in-tree code in that state already, but it's mostly/entirely one-off imports of GNU/FSF code like compat/regex/ or sh-i18n--envsubst.c that we're not actively working on in any way, and isn't core to git like the reftable would be. There's individual contributors who just don't like the idea of copyright assignment and wouldn't do it for that reason, but there's also contributors who do paid-for work for their employers on git.git sometimes. E.g. I've done such work under terms that were basically "you can contribute to open source as part of your job, and under the license the relevant project uses". Going through the legal process of changing that to "we, your employer, who own copyright to your work, agree to license it to this third party project/company/whatever for the purposes of an open source contribution" would in my experience be *very much* an uphill battle. So I think even if the individual contributor wouldn't mind the copyright assignment (I'd personally be fine with that), e.g. I've been in employment relationships where I'd just forget about sending a patch if it needed assignment, because there's no way I'd be getting it past legal, in the same way Han-Wen seems to be having an uphill battle with Google's lawyers. 1. https://lore.kernel.org/git/873625i9tc.fsf@xxxxxxxxxxxxxxxxxxx/
