Re: LGPL code in /usr/tests?

On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk
<m.e.sanliturk@gmail.com> wrote:
>
>
>
> 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

The problem is that the library, not just the headers, needs to be
present at compile time.  Or do you know a good workaround?

>
>
>
>
>>
>> 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
>>>