LGPL code in /usr/tests?

From: Alan Somers <asomers_at_freebsd.org>
Date: Fri, 31 Dec 2021 21:21:19 UTC
I recently ran into a bug in fusefs that can only be triggered when
NFS exports a FUSE file system.  That makes it very difficult to write
an automated test.  My options are basically:

* Add an fhgetdirentries(2) syscall that is like getdirentries, but
takes a fhandle_t* argument instead of a file descriptor.
* Actually start nfsd during the test, and export the temporary FUSE filesystem.

The first option sounds like way too much non-test code to change.
Plus, I may need to add thread() and fhwrite() syscalls too, for other
NFS-related test cases.  The second option would also be a lot of
work, but at least the work would all be confined to the test code.
However, what would I do once I've exported the file system?  Mounting
it with the NFS client would add several more layers to the stack
under test.  I'm not even sure that it's safe to self-mount an
exported file system.  Another option would be to communicate directly
with nfsd from the test code.  That's possible, but writing NFS RPCs
by hand is very cumbersome, and it would obscure the test logic.  A
better option is to use libnfs.  The API is just what I would need.
However, it's licensed under the LGPL 2.1.  I know that we as a
project decided to import no new GPLish code into contrib/.  But this
code would never be used outside of /usr/tests, so it wouldn't even
affect many production builds.  Would that be acceptable?  The
workarounds are ugly:

* Create a new port for all libnfs-dependent tests.  This would be
hard to maintain, because the content of the tests must be so
dependent on the base version of the OS.
* Write the tests in Python using libnfs-python.  The tests could
still be compiled as part of the base system, they just wouldn't work
unless libnfs-python is installed from ports.  But this is awkward
because the tests are currently C++.  So I would have to embed a
Python interpreter into the C++ code.  It would really obfuscate the
test logic.
* Store the tests in the base system, but detached from the build.
Then create a port that builds them by mounting SRC_BASE, much like
devel/py-libzfs does.  It would then install them in /usr/local/tests.
This is probably the least-bad option if I can't import libnfs into

What do you think?  Is it acceptable to import libnfs intro contrib/?
It's LGPL, except for a few headers that are BSD and some examples
that are GPLv3.  But we needn't use the examples, or even import them.