| Message ID | 02bd1f40fa4e281f878d0b9ba4a8b5f8eb21c8ff.1618255552.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | reftable library | expand |
On Mon, Apr 12 2021, Han-Wen Nienhuys via GitGitGadget wrote: > From: Han-Wen Nienhuys <hanwen@google.com> > > TODO: relicense? So to your[1]: > However, it is fundamentally blocked on someone willing to spend > some time reviewing the series; this seems to be out of my > control. I for one find it hard to follow re-rolls of this when past discussion isn't clarified/updated in commit messages/CLs. So in particular in v3[2] there was a whole discussion about what what this licence & external hosting of this codebase meant in practical terms. I vaguely recall that that was clarified in some way by you, but didn't find the relevant E-Mail. Something like Google's lawyers said something to the effect that this could just be added to git.git, no? Maybe that's incorrect, I don't remember. Anyway, we're now in v6, and we still have nothing but a "TODO: relicense?" blurb here. As noted in the past discussion I'm not interested in the academic/theoretical side that license discussion, but the very practical question of how this library is expected to be integrated/maintained. I.e. if it's meant to be 100% externally maintained and "code-dumped" into git.git like we do with sha1collisiondetection/ that raises one set of concerns, but if it's meant to be "eaten" by git.git that poses another set of questions for the code review here. I.e. much of what you're doing in later patches in this series is introducing things that are redundant/odd if viewed if we're supposing that this code is meant to live in git.git. 1. https://lore.kernel.org/git/CAFQ2z_P=MqT81gLjov6A471Z9sd69qQTep8KG8M8=LO9pJtkpQ@mail.gmail.com/ 2. https://lore.kernel.org/git/CAFQ2z_OJQf3+b0TT6BmAV9q9G9c2icbLK0EqrEjpYmpi8g9Fsg@mail.gmail.com/
On Tue, Apr 13, 2021 at 9:28 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > However, it is fundamentally blocked on someone willing to spend > > some time reviewing the series; this seems to be out of my > > control. > > I for one find it hard to follow re-rolls of this when past discussion > isn't clarified/updated in commit messages/CLs. > > So in particular in v3[2] there was a whole discussion about what what > this licence & external hosting of this codebase meant in practical > terms. > > I vaguely recall that that was clarified in some way by you, but didn't > find the relevant E-Mail. Something like Google's lawyers said something > to the effect that this could just be added to git.git, no? Maybe that's > incorrect, I don't remember. You're right, I didn't update the thread. The outcome is that the library for now lives in https://github.com/hanwen/reftable while it's not integrated in git.git. In this repo I can accept contributions (including fixup changes posted to the git list) without requiring CLAs. > I.e. if it's meant to be 100% externally maintained and "code-dumped" > into git.git like we do with sha1collisiondetection/ that raises one set > of concerns, but if it's meant to be "eaten" by git.git that poses > another set of questions for the code review here. I.e. much of what > you're doing in later patches in this series is introducing things that > are redundant/odd if viewed if we're supposing that this code is meant > to live in git.git. The code is meant to be eaten by git.git, but be amenable to being used by libgit2 with minimal modifications. To that end, it tries to use just functionality offered by git-compat-util. If you could point out specific oddities, that would be helpful. As said earlier, the BSD license here is the most liberal I could find, but I'm open to something else, if that makes integration in both git and libgit2 possible. This was not discussed further, and hence the "TODO: relicense?" comment.
On Tue, Apr 13 2021, Han-Wen Nienhuys wrote: > On Tue, Apr 13, 2021 at 9:28 AM Ævar Arnfjörð Bjarmason > <avarab@gmail.com> wrote: >> > However, it is fundamentally blocked on someone willing to spend >> > some time reviewing the series; this seems to be out of my >> > control. >> >> I for one find it hard to follow re-rolls of this when past discussion >> isn't clarified/updated in commit messages/CLs. >> >> So in particular in v3[2] there was a whole discussion about what what >> this licence & external hosting of this codebase meant in practical >> terms. >> >> I vaguely recall that that was clarified in some way by you, but didn't >> find the relevant E-Mail. Something like Google's lawyers said something >> to the effect that this could just be added to git.git, no? Maybe that's >> incorrect, I don't remember. > > You're right, I didn't update the thread. The outcome is that the > library for now lives in https://github.com/hanwen/reftable while it's > not integrated in git.git. In this repo I can accept contributions > (including fixup changes posted to the git list) without requiring > CLAs. And once this lands if there's patches to reftable/* on this ML? Knowing would be good, a change to Documentation/SubmittingPatches et al in the next iteration even better :) >> I.e. if it's meant to be 100% externally maintained and "code-dumped" >> into git.git like we do with sha1collisiondetection/ that raises one set >> of concerns, but if it's meant to be "eaten" by git.git that poses >> another set of questions for the code review here. I.e. much of what >> you're doing in later patches in this series is introducing things that >> are redundant/odd if viewed if we're supposing that this code is meant >> to live in git.git. > > The code is meant to be eaten by git.git, but be amenable to being > used by libgit2 with minimal modifications. To that end, it tries to > use just functionality offered by git-compat-util. > > If you could point out specific oddities, that would be helpful. Things like different coding style, e.g. $(git grep '[!=]= NULL' -- reftable/) & comment style. Having Go-ish (or Google-ish?) *_test.c files instead of that living in t/helper/*. reftable/dump.c not using parse_options(). This having reftable_free() etc., which at least for in-tree use is redundant, see 8d128513429 (grep/pcre2: actually make pcre2 use custom allocator, 2021-02-18). Wondering if internal libraries (e.g. in basic.c) are there to avoid various kitchen-sink things existing in git.git itself, or because no existing thing fit the purpose. I'm not saying those things aren't OK or the "sorta-external" trade-off needs to change, just that reviewing it not knowing what the expected status is left me hanging. > As said earlier, the BSD license here is the most liberal I could > find, but I'm open to something else, if that makes integration in > both git and libgit2 possible. This was not discussed further, and > hence the "TODO: relicense?" comment. I don't per-se have issues with the license, just questions about what it means for the development flow. Let's say Junio merges this to master, and someone discovers a bug in it. Surely one of these happen: 1. We just take the patch, if it's a tree-wide patch someone at reftable.git would need to either look at GPLv2 patch or clean-room duplicate it somehow. 2. Junio refuses any suggested changes to the reftable/* directory, we tell people to submit an upstream PR, once that lands we update. So like sha1collisiondetection/ (well, sans the "Junio refusing", I think I un-forked that at least a couple of times). One of those means that e.g. if the change is to a strbuf API reftable/* needs we'd need to version that API or otherwise treat it as stable. As an aside, to your [1] again: At least to me reading a series on-list that has TODO comments in commit messages very much sounds like an RFC but not calling itself that, maybe I'm alone in that, but if not clearing this sort of thing up / documenting it might go far in getting more reviews. 1. https://lore.kernel.org/git/CAFQ2z_P=MqT81gLjov6A471Z9sd69qQTep8KG8M8=LO9pJtkpQ@mail.gmail.com/
diff --git a/reftable/LICENSE b/reftable/LICENSE new file mode 100644 index 000000000000..402e0f9356ba --- /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.