Date: Mon, 3 Jan 2022 11:06:20 -0700 From: Warner Losh <imp@bsdimp.com> To: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> Cc: Alan Somers <asomers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: LGPL code in /usr/tests? Message-ID: <CANCZdfpHPP98SJaO0xjeb-%2BjtzCh7ittysGTjuZg6pdvdb7Rzw@mail.gmail.com> In-Reply-To: <CAOgwaMtn9Sqp7ZxWM4_KVMB-4JTBrN96xWZgCX-bwjvVwW3fPg@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> <CAOgwaMtn9Sqp7ZxWM4_KVMB-4JTBrN96xWZgCX-bwjvVwW3fPg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000061365205d4b161e8 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> wrote: > > > 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 . > All of that is covered by our existing practice of storing LGPL code in src/gnu/lib. We cover it in the handbook already. Since it is publicly available forever, storing it there will have no impact that's any different than libdialog or libreadline has has in the past. Warner > 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 >> >> >>> >> > --00000000000061365205d4b161e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk &l= t;<a href=3D"mailto:m.e.sanliturk@gmail.com">m.e.sanliturk@gmail.com</a>>= ; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div dir= =3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-seri= f;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 &l= t;<a href=3D"mailto:asomers@freebsd.org" target=3D"_blank" rel=3D"noreferre= r">asomers@freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2= 04);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" rel=3D"nor= eferrer">m.e.sanliturk@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" rel=3D"noreferrer">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" r= el=3D"noreferrer">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" rel=3D"noreferrer">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 noreferrer" target=3D"_blank">https://en.w= ikipedia.org/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 noreferrer" target=3D"_blank">https://en.w= ikipedia.org/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></div></div></blockquote></div><= /div><div dir=3D"auto"><br></div><div dir=3D"auto">All of that is covered b= y our existing practice of storing LGPL code in src/gnu/lib. We cover it in= the handbook already. Since it is publicly available forever, storing it t= here will have no impact that's any different than libdialog or libread= line has has in the past.</div><div dir=3D"auto"><br></div><div dir=3D"auto= ">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"g= mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g= mail_quote"><div><div style=3D"font-family:tahoma,sans-serif;font-size:larg= e" class=3D"gmail_default"><br></div><div style=3D"font-family:tahoma,sans-= serif;font-size:large" class=3D"gmail_default">Mehmet Erol Sanliturk<br></d= iv><br></div><div><br></div><div><br></div><div><br></div><div><br></div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,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" rel=3D"noreferrer">asomer= s@freebsd.org</a>> 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 noreferrer" target=3D"_blank">https://github.com/sahlberg/libnf= s</a><br> >> >>><br> </blockquote></div></div> </blockquote></div></div></div> --00000000000061365205d4b161e8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpHPP98SJaO0xjeb-%2BjtzCh7ittysGTjuZg6pdvdb7Rzw>