Message ID | pull.1081.v3.git.git.1632841817.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Adds reftable library code from https://github.com/hanwen/reftable. | expand |
"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes: > The reftable format is described in Documentation/technical/reftable.txt. > > This is a fully reentrant implementation of reading and writing the reftable > file format, and should be suitable for embedding in libgit2 too. It does > not hook the code up to git to function as a ref storage backend yet. Elsewhere you solicited comments on the "RFC - add LICENSE" step. As long as the copyright holders of this library are happy with BSD, I do not see a problem with your plan in which the project borrows this code under the license and then owns it, giving access to others under the same license. If somebody sees problems with it, please raise your hands ;-) Thanks.
Patch 1, was discussed before and might be solved in a better way as an alternative. Patch 2 and 3 are "nice to have" for portability and hopefully not controversial but could be dropped, if someone feels strongly against it. Patch 4 is not something I'd found failing anywhere, but the fact that Microsoft mentions it is only supported as an extension and it needs to be supported by the dynamic linker and I couldn't find anything clear about it in POSIX means, that is probably safer this way. [PATCH 1/4] fixup! reftable: add a heap-based priority queue for [PATCH 2/4] fixup! reftable: implement stack, a mutable database of [PATCH 3/4] config.mak.uname: last release and snapshots of Minix [PATCH 4/4] reftable: avoid non portable compile time pointer to
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > Patch 1, was discussed before and might be solved in a better way as an > alternative. > > Patch 2 and 3 are "nice to have" for portability and hopefully not controversial > but could be dropped, if someone feels strongly against it. > > Patch 4 is not something I'd found failing anywhere, but the fact that Microsoft > mentions it is only supported as an extension and it needs to be supported by > the dynamic linker and I couldn't find anything clear about it in POSIX means, > that is probably safer this way. All of them look sensible. Thanks.
On Tue, Sep 28 2021, Junio C Hamano wrote: > "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> The reftable format is described in Documentation/technical/reftable.txt. >> >> This is a fully reentrant implementation of reading and writing the reftable >> file format, and should be suitable for embedding in libgit2 too. It does >> not hook the code up to git to function as a ref storage backend yet. > > Elsewhere you solicited comments on the "RFC - add LICENSE" step. > > As long as the copyright holders of this library are happy with BSD, > I do not see a problem with your plan in which the project borrows > this code under the license and then owns it, giving access to > others under the same license. > > If somebody sees problems with it, please raise your hands ;-) No objection, but as noted in previous discussions about it I think we should have some clarity about what it means for contributors. I.e. that when they're contributing to reftable/ it's BSD license, but for the rest of the codebase it's GPLv2. I've just submitted a series to address that more generally: https://lore.kernel.org/git/cover-0.5-00000000000-20211002T091212Z-avarab@gmail.com/ I think with that clarification of what these in-tree subdirectory "COPYING" files mean the only thing left is for the "RFC" label to be dropped here. From what I as not-a-lawyer think I know about how licenses work the concept that we can have BSD licensed content in-tree that can be extracted and legally used by anyone outside of it seems rather dubious. I.e. if I author a cross-tree where "reftable/" uses some updated API, isn't the result a derived work and now GPLv2 and not "cleanly" BSD licensed? But that's a separate question, and ultimately a worry for any out-of-tree users. So I don't really care. I also believe that we've had that situation before with (I think) libgit2 taking snapshots of our "xdiff", so maybe it's already deemed to be a complete non-issue. All I'd like is for contributors to git.git not to be confused, which I think with my series above won't be the case.