Re: LGPL code in /usr/tests?
- Reply: Alan Somers : "Re: LGPL code in /usr/tests?"
- In reply to: Warner Losh : "Re: LGPL code in /usr/tests?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 03 Jan 2022 07:37:13 UTC
On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <email@example.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 <firstname.lastname@example.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 >> >>