On Tue, Oct 27, 2020 at 01:48:31PM -0500, Eric Blake wrote: > On 10/27/20 1:38 PM, Richard W.M. Jones wrote: > > This library proved useful in nbdkit where we need to construct an > > array or vector of arbitrary objects, with the easy ability to append > > at the end. Wherever code uses realloc(3) to build an array of > > objects is a candidate for replacement by this library. > > --- > > Makefile.am | 1 + > > common/utils/Makefile.am | 44 ++++++++++ > > common/utils/vector.c | 51 +++++++++++ > > common/utils/vector.h | 177 +++++++++++++++++++++++++++++++++++++++ > > configure.ac | 1 + > > 5 files changed, 274 insertions(+) > > > > > +++ b/common/utils/Makefile.am > > @@ -0,0 +1,44 @@ > > +# nbdkit > > +# Copyright (C) 2019 Red Hat Inc. > > +# > > +# Redistribution and use in source and binary forms, with or without > > +# modification, are permitted provided that the following conditions are > > +# met: > > Since we are lifting straight from nbdkit, this is fine (our one-way > license conversion at play). It does mean we have a risk in the > opposite direction (any improvement made here can't easily be pushed > back to nbdkit unless the author is okay with the difference in license).
I think we're OK as long as we keep the BSD-ish license on these files? That way changes made to these files (only) would be under the same license as nbdkit. Of course we end up with a franken-license but at least it's not as bad as QEMU (!) and the whole thing should still be LGPLv2+ (AIUI/IANAL/E&OE/...) > As long as we are lifting this, should we also list automatic cleanup > usage, where we then demand modern gcc/clang as compiler? While I don't object to it, I didn't need automatic cleanup for this patch so I didn't copy that one across. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
