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