| Message ID | 91c3ac2449edc45db643b0ba6cba66ef31176600.1606419752.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | reftable library | expand |
On Thu, Nov 26 2020, Han-Wen Nienhuys via GitGitGadget wrote: > From: Han-Wen Nienhuys <hanwen@google.com> > > TODO: relicense? On the topics of TODOs, it would be nice to have an answer/some idea the "I am concerned..." question in about https://lore.kernel.org/git/873625i9tc.fsf@evledraar.gmail.com/ relevant to the license etc.
On Fri, Nov 27, 2020 at 11:23 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > On Thu, Nov 26 2020, Han-Wen Nienhuys via GitGitGadget wrote: > > > From: Han-Wen Nienhuys <hanwen@google.com> > > > > TODO: relicense? > > On the topics of TODOs, it would be nice to have an answer/some idea the > "I am concerned..." question in about > https://lore.kernel.org/git/873625i9tc.fsf@evledraar.gmail.com/ relevant > to the license etc. Long term objective is for this to live in git proper, but remains independently compilable, so it can be used by libgit2 as well. This is achieved by having the code only depend on functions in strbuf.h and git-compat-util.h. I would like to enforce the separation by having an actual standalone compile, but the discussion over the code to do so has caused more heat than light, so I have deferred this by reworking standalone code to to be on file level, and only importing the non-standalone code. In one of the other patches, you found a place where I had overlooked a REFTABLE_STANDALONE #ifdef; I'll remove that. I'll also remove the update.sh script. Until the reftable code is actually merged into git, I work on the reftable library itself at github.com/google/reftable. I've asked our opensource team if we could switch off the CLA enforcement for this repo, to facilitate back & forth imports of fixes. The current version of the patchseries mainly addresses overall feedback from the Git team at Google to split the public API along commits too, and updates the series so it applies to master again.
On Mon, Nov 30, 2020 at 12:26 PM Han-Wen Nienhuys <hanwen@google.com> wrote: > Until the reftable code is actually merged into git, I work on the > reftable library itself at github.com/google/reftable. I've asked our > opensource team if we could switch off the CLA enforcement for this > repo, to facilitate back & forth imports of fixes. I've asked our lawyers, but this is not currently possible, unfortunately.
On Mon, Nov 30, 2020 at 2:28 PM Han-Wen Nienhuys <hanwen@google.com> wrote: > > On Mon, Nov 30, 2020 at 12:26 PM Han-Wen Nienhuys <hanwen@google.com> wrote: > > Until the reftable code is actually merged into git, I work on the > > reftable library itself at github.com/google/reftable. I've asked our > > opensource team if we could switch off the CLA enforcement for this > > repo, to facilitate back & forth imports of fixes. > > I've asked our lawyers, but this is not currently possible, unfortunately. Maybe I'm not understanding something correctly. Git's license is GPLv2. When you add your Signed-off-by line you are saying you are authorized to provide this code to the Git project under its open source license. Therefore, I should be able to take your patches, and rework them in any way I want as long as I keep Git's license. I don't need your permission, you are supposedly giving it by adding your Signed-off-by line. Read: https://developercertificate.org/ If you are not authorized to provide these patches under an open source license, then you should not add your Signed-off-by line. And if these patches cannot be used by the Git project, nor can we work on them in a collaborative manner, then what's the point in providing them? Sounds to me Google has not made its mind about actually contributing these changes. Or am I missing something? Cheers.
On Mon, Nov 30, 2020 at 10:21 PM Felipe Contreras <felipe.contreras@gmail.com> wrote: > > On Mon, Nov 30, 2020 at 2:28 PM Han-Wen Nienhuys <hanwen@google.com> wrote: > > > > On Mon, Nov 30, 2020 at 12:26 PM Han-Wen Nienhuys <hanwen@google.com> wrote: > > > Until the reftable code is actually merged into git, I work on the > > > reftable library itself at github.com/google/reftable. I've asked our > > > opensource team if we could switch off the CLA enforcement for this > > > repo, to facilitate back & forth imports of fixes. > > > > I've asked our lawyers, but this is not currently possible, unfortunately. > > Maybe I'm not understanding something correctly. > 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/ .
On Tue, Dec 1, 2020 at 3:51 AM Han-Wen Nienhuys <hanwen@google.com> wrote: > On Mon, Nov 30, 2020 at 10:21 PM Felipe Contreras > <felipe.contreras@gmail.com> wrote: > > On Mon, Nov 30, 2020 at 2:28 PM Han-Wen Nienhuys <hanwen@google.com> 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.
On Tue, Dec 01 2020, Felipe Contreras wrote: > On Tue, Dec 1, 2020 at 3:51 AM Han-Wen Nienhuys <hanwen@google.com> wrote: >> On Mon, Nov 30, 2020 at 10:21 PM Felipe Contreras >> <felipe.contreras@gmail.com> wrote: >> > On Mon, Nov 30, 2020 at 2:28 PM Han-Wen Nienhuys <hanwen@google.com> 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@evledraar.gmail.com/
On Tue, Dec 1, 2020 at 12:45 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > On Tue, Dec 01 2020, Felipe Contreras wrote: > > > On Tue, Dec 1, 2020 at 3:51 AM Han-Wen Nienhuys <hanwen@google.com> wrote: > >> On Mon, Nov 30, 2020 at 10:21 PM Felipe Contreras > >> <felipe.contreras@gmail.com> wrote: > >> > On Mon, Nov 30, 2020 at 2:28 PM Han-Wen Nienhuys <hanwen@google.com> 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. I am also bound by my employment contract to follow company instructions. While you (Felipe) can post code where you want, the same is not true for me. > 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. > [..] Thanks for sketching the dilemmas here. Me and Jun are talking to the open source folks here at Google, so I am optimistic that we will find some solution. Please give us a few days to sort this out. > 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. FWIW, the plan of record is still for this code to have its source of truth in the Git project. Once it's there, there is no need for Google to have CLAs for contributions to the reftable/ directory. There is still the open question of how to set the license terms for this code, so it is OK for it to be copied into libgit2. I picked the current license (BSD) because it was the most liberal I could find. (Maybe I should document that in the commit message.)
On Tue, Dec 1, 2020 at 5:45 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > 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. That's the default. Unless otherwise stated; you retain the copyright while contributing code to open source projects. Generally when open source projects want to change license they have to get the agreement from the majority of copyright holders. Some projects do ask you to give away your copyright, but I'm not comfortable with that. If I want to contribute my code with GPLv2, that's the license I want. If a project I contribute to wants to switch to GPLv3, then they have to remove my code (or do something illegal). So I see nothing wrong with Google owning the copyright and controlling under which license(s) their code is distributed. In fact, I would see something wrong with the opposite; them giving away their copyright. Cheers.
On Tue, Dec 1, 2020 at 7:35 AM Han-Wen Nienhuys <hanwen@google.com> wrote: > > On Tue, Dec 01 2020, Felipe Contreras wrote: > > > 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. > > I am also bound by my employment contract to follow company > instructions. While you (Felipe) can post code where you want, the > same is not true for me. I understand that, but what if a stubborn person decides to do that, and the code starts diverging from github.com/google/? So essentially a fork is created. I don't think that's in the best interest of Google, and that would force their hand to either a) allow you to contribute to the open repo, or b) allow open source people to contribute to the google repo. I find it silly that these thought experiments have to be explained to corporate lawyers, or worse; they actually have to be done so the lawyers get the point. But alas, that's what working in a big corporation entails. Good luck with that. (No sarcasm intended)
diff --git a/reftable/LICENSE b/reftable/LICENSE new file mode 100644 index 0000000000..402e0f9356 --- /dev/null +++ b/reftable/LICENSE @@ -0,0 +1,31 @@ +BSD License + +Copyright (c) 2020, Google LLC +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are +met: + +* Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. + +* Neither the name of Google LLC nor the names of its contributors may +be used to endorse or promote products derived from this software +without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.