Re: LGPL code in /usr/tests?

On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <imp@bsdimp.com> wrote:

> Top posting my reactions (sorry)
>
> I think 'in base as a private library, used only in the tests protected by
> MK_LGPL' is fine.
>
> This would keep it in base, keep the testing happening, and allow those
> who want
> to omit it. This would also not run afoul of any companies that still have
> downloading
> GPL'd software is a fireable offense, since all such policies I heard
> about years ago
> were specifically the GPL, not the LGPL). This is of course a trade off
> between
> getting something useful from the LGPL software (better testing) and our
> desires
> not to have any in the tree at all, if possible. Adding a knob would let
> it be shut
> off easily with all the tests disabled that depend on it. This is also in
> keeping with
> our historical practices of having software with undesirable licenses as
> long as it
> gets us something.
>
> I think this is better than the ports options because it will get more use
> and exposure
> this way and is more likely to remain working (though with our current CI
> setup
> adding it as a dependency for that CI would be easy and give us decent
> coverage).
>
> Warner
>
>


https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
GNU Lesser General Public License

https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft
Strong and weak copyleft


"GNU Lesser General Public License" is a  WEAK copyleft license ( it may be
considered "benign" : it does not invade the user software , affects only
the modifications to the LGPL licensed software ) ,

in spite of this ,

"GNU General Public License" is a STRONG copyleft license ( it may be
considered "malignant" : it invades the user software as a whole ) .


Using a ( LGPL licensed software ) for testing another software is not
directly involved in the tested software .

To eliminate possible doubts , if I were the decision maker about how to
use it , I would make it a port , and fetch it during testing as a
dynamically loaded library ( manage it port with respect to its license ) .


Mehmet  Erol Sanliturk





> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <asomers@freebsd.org> wrote:
>
>> 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
>> contrib/.
>>
>> 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.
>>
>> https://github.com/sahlberg/libnfs
>>
>>