Subject: Re: [PATCH v3 00/19] Adds reftable library code from https://github.com/hanwen/reftable.

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Sat, 02 Oct 2021 11:20:29 +0200

On Tue, Sep 28 2021, Junio C Hamano wrote:

> "Han-Wen Nienhuys via GitGitGadget" <[email-masked]> 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/[email-masked]/

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.