Date: Mon, 3 Jan 2022 20:32:22 +0300 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: LGPL code in /usr/tests? Message-ID: <CAOgwaMtn9Sqp7ZxWM4_KVMB-4JTBrN96xWZgCX-bwjvVwW3fPg@mail.gmail.com> In-Reply-To: <CAOtMX2jVS=qWzHtX3yw5_wYHOS02P7obmwo7rQ16%2BcJL=WOyOQ@mail.gmail.com> References: <CAOtMX2gp46301jOA2OG8bqxDgxspqSYPafGNtxdvqyO-nk2Qtg@mail.gmail.com> <CANCZdfr4WoZUNLzyK5%2BMJNi3c2k7v94LS99w-9-K4-Afr0JU-w@mail.gmail.com> <CAOgwaMtsj-YXb8fxnL9vaarV3bB7j%2BpFWakOH7Un=6w2Fc39=g@mail.gmail.com> <CAOtMX2iPxZWr_nc8uVEPhxgmLkdzKeMvH%2BtWU99u%2Bpk8Hs=3Aw@mail.gmail.com> <CAOgwaMuzMukKrgntYps6_rSO88=jMG6QLF0SVrs8r9kF=KesAA@mail.gmail.com> <CAOtMX2jVS=qWzHtX3yw5_wYHOS02P7obmwo7rQ16%2BcJL=WOyOQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000006eff9605d4b0e9d0 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 7:57 PM Alan Somers <asomers@freebsd.org> wrote: > On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk > <m.e.sanliturk@gmail.com> wrote: > > > > > > > > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers <asomers@freebsd.org> wrote: > >> > >> 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? > > > > > > > > > > You can fetch the LGPL licensed sources during compile time from outside > of the FreeBSD > > base known to the testing program . The user(s) of FreeBSD can also use > a similar facility . > > > > For example : > > > > I am developing mainly two programs : > > > > (1) Mathematical Analysis computations > > (2) A Multi-media information management system > > > > These programs are using parts taken from legally personally usable > sources which > > can not be used for a ( free or commercial ) distribution . During > program development , > > it is possible to use them , because they are in there just as a filler > for not-implemented-yet parts . > > > > To prevent unacceptable inclusion of such sources into my own > productions , I am > > using global directories outside of the program directories : > > > > /KBMS/Parts_to_ be_Removed/... ( Part specific directories ) > > /MAS/Parts_to_ be_Removed/... ( Part specific directories ) > > > > It is explicitly known that these directories and their contents can not > be used . > > There is no danger of including them erroneously . > > > > > > You can define such directories . During compilation you may fetch LGPL > licensed > > parts from these directories ( even though they may be on the Internet ) > . After compilation of > > the programs ( and if they are executed ) you may discard them . By > supplying a script to manage such issues , users of the FreeBSD may also > use the associated external directories created in their systems and used > during their works . > > > > > > The main problem for the LGPL licensed sources is the modifications > performed > > in them . If there are such parts they should be open sourced , not the > sources of the > > user sources . The closed source programs will not be affected from such > modifications . > > > > Some closed source program developers may not want to handle legal > implications of > > these modified or not modified LGPL licensed parts even when they are > distributed because any failure of distribution of especially modified > sources may cause significant trouble for them . To eliminate such > distribution related concerns , the best action may be to store > > these sources into a publicly accessible repository , modify these > sources in that repository and use them from this repository . In this > case , modifications in the main repository and excluding of these from > FreeBSD distributions will not affect FreeBSD users other than fetching > them when they are needed , which is legally acceptable and harmless . > > > > Generation of a package or port from this repository may be necessary > or not , > > I will not be able to say anything because I do not know . The port or > package > > generator persons would know such points . My opinion is that the above > model > > may not require either a port or a package separately because > everything necessary > > will be in the repository . > > > > > > > > Mehmet Erol Sanliturk > > > So you suggest that "make buildworld" downloads the libnfs sources? > That would be a big change from the current setup, where all sources > are assumed to be present when make starts. I expect that it might > break tools like "make release" and nanobsd, too. Of course, we could > always put these tests into tools/regression instead of tests/. That > would be easy. But then they wouldn't get run in CI. And I think > that CI is essential for any new tests. > > It is very likely that there will not be many ( or high frequency ) modifications in the repository of required LGPL licensed parts . Fetching and storing them into a directory outside of the source tree and keeping them in there will not be a violation of its license . If a modification is applied into their main repository , then again the action will be "fetch and store them , and keep them in there" . In this case , "make { buildworld | release }" or other processing steps will require only specification of the global directory of LGPL licensed sources ( outside of the FreeBSD base ) . These will not be included into FreeBSD base when it is distributed but only will be used during testing or other tasks where they are applied . Any user of the FreeBSD , will do a similar action in their "make { buildworld | release }" or other processing works . Since it is possible to keep the LGPL licensed sources ( by fetching modifications from its repository ) indefinitely , my opinion is that continuous use of these sources are legally possible and harmless . ( I am not a lawyer and my views do not constitute legal advice . ) If a user does not want to keep these LGPL licensed parts , she/he may discard the global directory contents when she/he completes her/his job , and again she/he may fetch and use them . Such an action will be decided by the user with respect to her/his needs and/or conventions . With respect to LGPL license such an action is not necessary if the above defined publically accessible repository is used . 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 > >> >>> > --0000000000006eff9605d4b0e9d0 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 7:57 PM Alan Somers <<a href=3D"mailto:asomers@freebsd.org">asomers@f= reebsd.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">On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk<br> <<a href=3D"mailto:m.e.sanliturk@gmail.com" target=3D"_blank">m.e.sanlit= urk@gmail.com</a>> wrote:<br> ><br> ><br> ><br> > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers <<a href=3D"mailto:asome= rs@freebsd.org" target=3D"_blank">asomers@freebsd.org</a>> wrote:<br> >><br> >> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk<br> >> <<a href=3D"mailto:m.e.sanliturk@gmail.com" target=3D"_blank">m= .e.sanliturk@gmail.com</a>> wrote:<br> >> ><br> >> ><br> >> ><br> >> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh <<a href=3D"mai= lto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com</a>> wrote:<br> >> >><br> >> >> Top posting my reactions (sorry)<br> >> >><br> >> >> I think 'in base as a private library, used only in t= he tests protected by MK_LGPL' is fine.<br> >> >><br> >> >> This would keep it in base, keep the testing happening, a= nd allow those who want<br> >> >> to omit it. This would also not run afoul of any companie= s that still have downloading<br> >> >> GPL'd software is a fireable offense, since all such = policies I heard about years ago<br> >> >> were specifically the GPL, not the LGPL). This is of cour= se a trade off between<br> >> >> getting something useful from the LGPL software (better t= esting) and our desires<br> >> >> not to have any in the tree at all, if possible. Adding a= knob would let it be shut<br> >> >> off easily with all the tests disabled that depend on it.= This is also in keeping with<br> >> >> our historical practices of having software with undesira= ble licenses as long as it<br> >> >> gets us something.<br> >> >><br> >> >> I think this is better than the ports options because it = will get more use and exposure<br> >> >> this way and is more likely to remain working (though wit= h our current CI setup<br> >> >> adding it as a dependency for that CI would be easy and g= ive us decent coverage).<br> >> >><br> >> >> Warner<br> >> >><br> >> ><br> >> ><br> >> ><br> >> > <a href=3D"https://en.wikipedia.org/wiki/GNU_Lesser_General_P= ublic_License" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.or= g/wiki/GNU_Lesser_General_Public_License</a><br> >> > GNU Lesser General Public License<br> >> ><br> >> > <a href=3D"https://en.wikipedia.org/wiki/Copyleft#Strong_and_= weak_copyleft" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.or= g/wiki/Copyleft#Strong_and_weak_copyleft</a><br> >> > Strong and weak copyleft<br> >> ><br> >> ><br> >> > "GNU Lesser General Public License" is a=C2=A0 WEAK= copyleft license ( it may be considered "benign" : it does not i= nvade the user software , affects only the modifications to the LGPL licens= ed software ) ,<br> >> ><br> >> > in spite of this ,<br> >> ><br> >> > "GNU General Public License" is a STRONG copyleft l= icense ( it may be considered "malignant" : it invades the user s= oftware as a whole ) .<br> >> ><br> >> ><br> >> > Using a ( LGPL licensed software ) for testing another softwa= re is not directly involved in the tested software .<br> >> ><br> >> > To eliminate possible doubts , if I were the decision maker a= bout how to use it , I would make it a port , and fetch it during testing a= s a dynamically loaded library ( manage it port with respect to its license= ) .<br> >> ><br> >> ><br> >> > Mehmet=C2=A0 Erol Sanliturk<br> >><br> ><br> ><br> ><br> ><br> ><br> >><br> >> The problem is that the library, not just the headers, needs to be= <br> >> present at compile time.=C2=A0 Or do you know a good workaround?<b= r> ><br> ><br> ><br> ><br> > You can fetch the LGPL licensed sources during compile time from outsi= de of the FreeBSD<br> > base known to the testing program . The user(s) of=C2=A0 FreeBSD can a= lso use a similar facility .<br> ><br> > For example :<br> ><br> > I am developing mainly two programs :<br> ><br> > (1) Mathematical Analysis computations<br> > (2) A Multi-media information management system<br> ><br> > These programs are using parts taken from legally personally usable so= urces=C2=A0 which<br> > can not be used for a ( free or commercial ) distribution . During pro= gram development ,<br> > it is possible to use them , because they are in there just as a fille= r for=C2=A0 not-implemented-yet parts .<br> ><br> > To prevent unacceptable inclusion of such sources into my own producti= ons , I am<br> > using global directories=C2=A0 outside of the program directories :<br= > ><br> > /KBMS/Parts_to_ be_Removed/... ( Part specific directories )<br> > /MAS/Parts_to_ be_Removed/... ( Part specific directories )<br> ><br> > It is explicitly known that these directories and their contents can n= ot be used .<br> > There is no danger of including them erroneously .<br> ><br> ><br> > You can define such directories . During compilation you may fetch LGP= L licensed<br> > parts from these directories ( even though they may be on the Internet= ) . After compilation of<br> > the programs ( and if they are executed ) you may discard them . By su= pplying a script to manage such issues , users of the FreeBSD may also use = the associated external directories created in their systems and used durin= g their works .<br> ><br> ><br> > The main problem for the LGPL licensed sources is the modifications pe= rformed<br> > in them . If there are such parts they should be open sourced , not th= e sources of the<br> > user sources . The closed source programs will not be affected from su= ch modifications .<br> ><br> > Some closed source program developers may not want to handle legal imp= lications of<br> > these modified or not modified LGPL licensed parts even when they are = distributed=C2=A0 because any failure of distribution of especially modifie= d sources may cause significant trouble for them . To eliminate such distri= bution related concerns , the best action may be to store<br> > these sources into a publicly accessible repository , modify these sou= rces in that repository and use them=C2=A0 from this repository . In this c= ase , modifications in the main repository and excluding of these from Free= BSD distributions will not affect FreeBSD users other than fetching them wh= en they are needed , which is legally acceptable and harmless .<br> ><br> > Generation of a package or port from this repository=C2=A0 may be nece= ssary or not ,<br> > I will not be able to say anything because I do not know . The port or= package<br> > generator persons would know such points . My opinion is that the abov= e model<br> > may not require either a port or a package separately because=C2=A0 ev= erything necessary<br> > will be in the repository .<br> ><br> ><br> ><br> > Mehmet Erol Sanliturk<br> <br></blockquote><div><br></div><div><br></div><div><br></div><div><br></di= v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> So you suggest that "make buildworld" downloads the libnfs source= s?<br> That would be a big change from the current setup, where all sources<br> are assumed to be present when make starts.=C2=A0 I expect that it might<br= > break tools like "make release" and nanobsd, too.=C2=A0 Of course= , we could<br> always put these tests into tools/regression instead of tests/.=C2=A0 That<= br> would be easy.=C2=A0 But then they wouldn't get run in CI.=C2=A0 And I = think<br> that CI is essential for any new tests.<br> <br></blockquote><div><br></div><div><br></div><div><br></div><div><br></di= v><div><div style=3D"font-family:tahoma,sans-serif;font-size:large" class= =3D"gmail_default">It is very likely that there will not be many ( or high = frequency ) modifications in <br></div><div style=3D"font-family:tahoma,san= s-serif;font-size:large" class=3D"gmail_default">the repository of required= LGPL licensed parts .=C2=A0 <br></div><div style=3D"font-family:tahoma,san= s-serif;font-size:large" class=3D"gmail_default"><br></div><div style=3D"fo= nt-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default">Fetchi= ng and storing them into a directory outside of the source tree and <br></d= iv><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gm= ail_default">keeping them in there will not be a violation of its license .= <br></div><div style=3D"font-family:tahoma,sans-serif;font-size:large" clas= s=3D"gmail_default">If a modification is applied into their=C2=A0 main repo= sitory , then again the action will be <br></div><div style=3D"font-family:= tahoma,sans-serif;font-size:large" class=3D"gmail_default">"fetch and = store them , and keep them in there" .</div><div style=3D"font-family:= tahoma,sans-serif;font-size:large" class=3D"gmail_default">In this case , &= quot;make { buildworld=C2=A0 | release }" or other processing steps wi= ll require only specification of the global directory of LGPL licensed sour= ces ( outside of the FreeBSD base ) . <br></div><div style=3D"font-family:t= ahoma,sans-serif;font-size:large" class=3D"gmail_default">These will not be= included into FreeBSD base when it is distributed <br></div><div style=3D"= font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default">but = only will be used during testing or other tasks where they are applied . <b= r></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">Any user of the FreeBSD , will do a = similar action in their "make { buildworld=C2=A0 | release }" </d= iv><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gm= ail_default">or other processing works . </div><br></div><div><br></div><di= v><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gma= il_default">Since it is possible to keep the LGPL licensed sources ( by fet= ching modifications from its repository ) indefinitely , my opinion</div><d= iv style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_d= efault">is that continuous use of these sources are legally possible and ha= rmless .</div><div style=3D"font-family:tahoma,sans-serif;font-size:large" = class=3D"gmail_default">( I am not a lawyer and my views do not constitute = legal advice . )<br></div><br></div><div><br></div><div><br></div><div><div= style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_def= ault">If a user does not want to keep these LGPL licensed parts , she/he ma= y discard the</div><div style=3D"font-family:tahoma,sans-serif;font-size:la= rge" class=3D"gmail_default">global directory contents when she/he complete= s her/his job , and again she/he <br></div><div style=3D"font-family:tahoma= ,sans-serif;font-size:large" class=3D"gmail_default">may fetch and use them= . Such an action will be decided by the user with respect to</div><div sty= le=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default= ">her/his needs and/or conventions . With respect to LGPL license such an a= ction is not <br></div><div style=3D"font-family:tahoma,sans-serif;font-siz= e:large" class=3D"gmail_default">necessary if the above defined publically = accessible repository is used .</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></di= v><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gma= il_default">Mehmet Erol Sanliturk<br></div><br></div><div><br></div><div><b= r></div><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(2= 04,204,204);padding-left:1ex"> ><br> ><br> ><br> ><br> >><br> >><br> >> ><br> >> ><br> >> ><br> >> ><br> >> >><br> >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <<a href= =3D"mailto:asomers@freebsd.org" target=3D"_blank">asomers@freebsd.org</a>&g= t; wrote:<br> >> >>><br> >> >>> I recently ran into a bug in fusefs that can only be = triggered when<br> >> >>> NFS exports a FUSE file system.=C2=A0 That makes it v= ery difficult to write<br> >> >>> an automated test.=C2=A0 My options are basically:<br= > >> >>><br> >> >>> * Add an fhgetdirentries(2) syscall that is like getd= irentries, but<br> >> >>> takes a fhandle_t* argument instead of a file descrip= tor.<br> >> >>> * Actually start nfsd during the test, and export the= temporary FUSE filesystem.<br> >> >>><br> >> >>> The first option sounds like way too much non-test co= de to change.<br> >> >>> Plus, I may need to add thread() and fhwrite() syscal= ls 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 f= ile system?=C2=A0 Mounting<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 t= o communicate directly<br> >> >>> with nfsd from the test code.=C2=A0 That's possib= le, but writing NFS RPCs<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 con= trib/.=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 ac= ceptable?=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 mu= st 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 ju= st wouldn't work<br> >> >>> unless libnfs-python is installed from ports.=C2=A0 B= ut 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<br> >> >>> test logic.<br> >> >>> * Store the tests in the base system, but detached fr= om the build.<br> >> >>> Then create a port that builds them by mounting SRC_B= ASE, much like<br> >> >>> devel/py-libzfs does.=C2=A0 It would then install the= m 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 l= ibnfs 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 exam= ples, or even import them.<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> --0000000000006eff9605d4b0e9d0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMtn9Sqp7ZxWM4_KVMB-4JTBrN96xWZgCX-bwjvVwW3fPg>