Date: Sun, 2 Jan 2022 23:30:36 -0700 From: Warner Losh <imp@bsdimp.com> To: Alan Somers <asomers@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: LGPL code in /usr/tests? Message-ID: <CANCZdfr4WoZUNLzyK5%2BMJNi3c2k7v94LS99w-9-K4-Afr0JU-w@mail.gmail.com> In-Reply-To: <CAOtMX2gp46301jOA2OG8bqxDgxspqSYPafGNtxdvqyO-nk2Qtg@mail.gmail.com> References: <CAOtMX2gp46301jOA2OG8bqxDgxspqSYPafGNtxdvqyO-nk2Qtg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000039f6c105d4a7a9ce Content-Type: text/plain; charset="UTF-8" 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 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 > > --00000000000039f6c105d4a7a9ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Top posting my reactions (sorry)</div><div><br></div>= <div>I think=C2=A0'in base as a private library, used only in the tests= protected by MK_LGPL' is fine.</div><div><br></div><div>This would kee= p it in base, keep the testing happening, and allow those who want</div><di= v>to omit it. This would also not run afoul of any companies that still hav= e downloading</div><div>GPL'd software is a fireable offense, since all= such policies I heard about years ago</div><div>were specifically the GPL,= not the LGPL). This is of course a trade off between</div><div>getting som= ething useful from the LGPL software (better testing) and our desires</div>= <div>not to have any in the tree at all, if possible. Adding a knob would l= et it be shut</div><div>off easily with all the tests disabled that depend = on it. This is also in keeping with</div><div>our historical practices of h= aving software with undesirable=C2=A0licenses as long as it</div><div>gets = us something.</div><div><br></div><div>I think this is better than the port= s options because it will get more use and exposure</div><div>this way and = is more likely to remain working (though with our current CI setup</div><di= v>adding it as a dependency for that CI would be easy and give us decent co= verage).</div><div><br></div><div>Warner</div><br><div class=3D"gmail_quote= "><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 31, 2021 at 2:22 PM Ala= n Somers <<a href=3D"mailto:asomers@freebsd.org">asomers@freebsd.org</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I re= cently ran into a bug in fusefs that can only be triggered when<br> NFS exports a FUSE file system.=C2=A0 That makes it very difficult to write= <br> an automated test.=C2=A0 My options are basically:<br> <br> * Add an fhgetdirentries(2) syscall that is like getdirentries, but<br> takes a fhandle_t* argument instead of a file descriptor.<br> * Actually start nfsd during the test, and export the temporary FUSE filesy= stem.<br> <br> The first option sounds like way too much non-test code to change.<br> Plus, I may need to add thread() and fhwrite() syscalls too, for other<br> NFS-related test cases.=C2=A0 The second option would also be a lot of<br> work, but at least the work would all be confined to the test code.<br> However, what would I do once I've exported the file system?=C2=A0 Moun= ting<br> it with the NFS client would add several more layers to the stack<br> under test.=C2=A0 I'm not even sure that it's safe to self-mount an= <br> exported file system.=C2=A0 Another option would be to communicate directly= <br> with nfsd from the test code.=C2=A0 That's possible, but writing NFS RP= Cs<br> by hand is very cumbersome, and it would obscure the test logic.=C2=A0 A<br= > better option is to use libnfs.=C2=A0 The API is just what I would need.<br= > However, it's licensed under the LGPL 2.1.=C2=A0 I know that we as a<br= > project decided to import no new GPLish code into contrib/.=C2=A0 But this<= br> code would never be used outside of /usr/tests, so it wouldn't even<br> affect many production builds.=C2=A0 Would that be acceptable?=C2=A0 The<br= > workarounds are ugly:<br> <br> * Create a new port for all libnfs-dependent tests.=C2=A0 This would be<br> hard to maintain, because the content of the tests must be so<br> dependent on the base version of the OS.<br> * Write the tests in Python using libnfs-python.=C2=A0 The tests could<br> still be compiled as part of the base system, they just wouldn't work<b= r> unless libnfs-python is installed from ports.=C2=A0 But this is awkward<br> because the tests are currently C++.=C2=A0 So I would have to embed a<br> Python interpreter into the C++ code.=C2=A0 It would really obfuscate the<b= r> test logic.<br> * Store the tests in the base system, but detached from the build.<br> Then create a port that builds them by mounting SRC_BASE, much like<br> devel/py-libzfs does.=C2=A0 It would then install them in /usr/local/tests.= <br> This is probably the least-bad option if I can't import libnfs into<br> contrib/.<br> <br> What do you think?=C2=A0 Is it acceptable to import libnfs intro contrib/?<= br> It's LGPL, except for a few headers that are BSD and some examples<br> that are GPLv3.=C2=A0 But we needn't use the examples, or even import t= hem.<br> <br> <a href=3D"https://github.com/sahlberg/libnfs" rel=3D"noreferrer" target=3D= "_blank">https://github.com/sahlberg/libnfs</a><br>; <br> </blockquote></div></div> --00000000000039f6c105d4a7a9ce--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr4WoZUNLzyK5%2BMJNi3c2k7v94LS99w-9-K4-Afr0JU-w>