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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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@xxxxxxxxx/

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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux