Date: Mon, 3 Jan 2022 10:37:13 +0300 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Alan Somers <asomers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: LGPL code in /usr/tests? Message-ID: <CAOgwaMtsj-YXb8fxnL9vaarV3bB7j%2BpFWakOH7Un=6w2Fc39=g@mail.gmail.com> In-Reply-To: <CANCZdfr4WoZUNLzyK5%2BMJNi3c2k7v94LS99w-9-K4-Afr0JU-w@mail.gmail.com> References: <CAOtMX2gp46301jOA2OG8bqxDgxspqSYPafGNtxdvqyO-nk2Qtg@mail.gmail.com> <CANCZdfr4WoZUNLzyK5%2BMJNi3c2k7v94LS99w-9-K4-Afr0JU-w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000fcb10105d4a898a6 Content-Type: text/plain; charset="UTF-8" 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 >> >> --000000000000fcb10105d4a898a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:tahoma,sans-serif;font-size:large"><br></div></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 3, 2022 = at 9:31 AM Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com= </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">= <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></blockquote><div><= br></div><div><br></div><div><br></div><div><a href=3D"https://en.wikipedia= .org/wiki/GNU_Lesser_General_Public_License">https://en.wikipedia.org/wiki/= GNU_Lesser_General_Public_License</a></div><div>GNU Lesser General Public L= icense<br></div><div><br></div><div><a href=3D"https://en.wikipedia.org/wik= i/Copyleft#Strong_and_weak_copyleft">https://en.wikipedia.org/wiki/Copyleft= #Strong_and_weak_copyleft</a></div><div>Strong and weak copyleft<br></div><= div><br></div><div><br></div><div><span class=3D"gmail_default" style=3D"fo= nt-family:tahoma,sans-serif;font-size:large">"</span>GNU Lesser Genera= l Public License<span class=3D"gmail_default" style=3D"font-family:tahoma,s= ans-serif;font-size:large">" is a=C2=A0 WEAK copyleft license ( it may= be considered "benign" : it does not invade the user software , = affects only the modifications to the LGPL licensed software ) , <br></span= ></div><div><span class=3D"gmail_default" style=3D"font-family:tahoma,sans-= serif;font-size:large"><br></span></div><div><span class=3D"gmail_default" = style=3D"font-family:tahoma,sans-serif;font-size:large">in spite of this ,<= br></span></div><div><span class=3D"gmail_default" style=3D"font-family:tah= oma,sans-serif;font-size:large"><br></span></div><div><span class=3D"gmail_= default" style=3D"font-family:tahoma,sans-serif;font-size:large">"GNU = General Public License" is a STRONG copyleft license ( it may be consi= dered "malignant" : it invades the user software as a whole ) .<b= r></span></div><div><br></div><div><br></div><div><div style=3D"font-family= :tahoma,sans-serif;font-size:large" class=3D"gmail_default">Using a ( LGPL = licensed software ) for testing another software is not directly involved i= n the tested software . </div></div><div><br></div><div><div style=3D"font-= family:tahoma,sans-serif;font-size:large" class=3D"gmail_default">To elimin= ate 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 ) .</div><div style=3D= "font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default"><br= ></div><div style=3D"font-family:tahoma,sans-serif;font-size:large" class= =3D"gmail_default"><br></div><div style=3D"font-family:tahoma,sans-serif;fo= nt-size:large" class=3D"gmail_default">Mehmet=C2=A0 Erol Sanliturk</div><di= v style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_de= fault"><br></div><div style=3D"font-family:tahoma,sans-serif;font-size:larg= e" class=3D"gmail_default"></div><br></div><div><br></div><div>=C2=A0</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"><div dir=3D"ltr"><div cla= ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 31, 20= 21 at 2:22 PM Alan Somers <<a href=3D"mailto:asomers@freebsd.org" target= =3D"_blank">asomers@freebsd.org</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">I recently ran into a bug in fusefs that c= an 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> </blockquote></div></div> --000000000000fcb10105d4a898a6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMtsj-YXb8fxnL9vaarV3bB7j%2BpFWakOH7Un=6w2Fc39=g>