Date: Mon, 3 Jan 2022 21:37:00 +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: <CAOgwaMtnQ3DNSYv%2BJN1dsi1qH5=4ZJw=tmM6rVLRM0eCe6gUUQ@mail.gmail.com> In-Reply-To: <CANCZdfpHPP98SJaO0xjeb-%2BjtzCh7ittysGTjuZg6pdvdb7Rzw@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> <CANCZdfpHPP98SJaO0xjeb-%2BjtzCh7ittysGTjuZg6pdvdb7Rzw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000008aa1ab05d4b1d05a Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 9:06 PM Warner Losh <imp@bsdimp.com> wrote: > > > 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 > > You are right . If src/gnu/lib is included in FreeBSD base AND some users want to exclude these from the FreeBSD base ( or releases ) then a possible action would be my suggestion ( as move it into , for example , /gnu/lib/... and exclude it from the FreeBSD base , by supplying its Internet access link in releases ) among other ( possibly many ) alternatives . > >> 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 >>> >> >>> >>> >> --0000000000008aa1ab05d4b1d05a 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:06 PM 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"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" target=3D"_blank">m.e.sanlitur= k@gmail.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 dir=3D"ltr"><div style=3D"font-family:taho= ma,sans-serif;font-size:large"><br></div></div><br><div class=3D"gmail_quot= e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 3, 2022 at 7:57 PM Ala= n Somers <<a href=3D"mailto:asomers@freebsd.org" rel=3D"noreferrer" targ= et=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">On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol= Sanliturk<br> <<a href=3D"mailto:m.e.sanliturk@gmail.com" rel=3D"noreferrer" target=3D= "_blank">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" rel=3D"noreferrer" 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" rel=3D"noreferrer" = 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" rel=3D"noreferrer" 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 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">It is v= ery likely that there will not be many ( or high frequency ) modifications = in <br></div><div style=3D"font-family:tahoma,sans-serif;font-size:large">t= he repository of required LGPL licensed parts .=C2=A0 <br></div><div style= =3D"font-family:tahoma,sans-serif;font-size:large"><br></div><div style=3D"= font-family:tahoma,sans-serif;font-size:large">Fetching and storing them in= to a directory outside of the source tree and <br></div><div style=3D"font-= family:tahoma,sans-serif;font-size:large">keeping them in there will not be= a violation of its license .<br></div><div style=3D"font-family:tahoma,san= s-serif;font-size:large">If a modification is applied into their=C2=A0 main= repository , then again the action will be <br></div><div style=3D"font-fa= mily:tahoma,sans-serif;font-size:large">"fetch and store them , and ke= ep them in there" .</div><div style=3D"font-family:tahoma,sans-serif;f= ont-size:large">In this case , "make { buildworld=C2=A0 | release }&qu= ot; or other processing steps will require only specification of the global= directory of LGPL licensed sources ( outside of the FreeBSD base ) . <br><= /div><div style=3D"font-family:tahoma,sans-serif;font-size:large">These wil= l not be included into FreeBSD base when it is distributed <br></div><div s= tyle=3D"font-family:tahoma,sans-serif;font-size:large">but only will be use= d during testing or other tasks where they are applied . <br></div><div sty= le=3D"font-family:tahoma,sans-serif;font-size:large"><br></div><div style= =3D"font-family:tahoma,sans-serif;font-size:large">Any user of the FreeBSD = , will do a similar action in their "make { buildworld=C2=A0 | release= }" </div><div style=3D"font-family:tahoma,sans-serif;font-size:large"= >or other processing works . </div><br></div><div><br></div><div><div style= =3D"font-family:tahoma,sans-serif;font-size:large">Since it is possible to = keep the LGPL licensed sources ( by fetching modifications from its reposit= ory ) indefinitely , my opinion</div><div style=3D"font-family:tahoma,sans-= serif;font-size:large">is that continuous use of these sources are legally = possible and harmless .</div><div style=3D"font-family:tahoma,sans-serif;fo= nt-size:large">( I am not a lawyer and my views do not constitute legal adv= ice . )<br></div><br></div><div><br></div><div><br></div><div><div style=3D= "font-family:tahoma,sans-serif;font-size:large">If a user does not want to = keep these LGPL licensed parts , she/he may discard the</div><div style=3D"= font-family:tahoma,sans-serif;font-size:large">global directory contents wh= en she/he completes her/his job , and again she/he <br></div><div style=3D"= font-family:tahoma,sans-serif;font-size:large">may fetch and use them . Suc= h an action will be decided by the user with respect to</div><div style=3D"= font-family:tahoma,sans-serif;font-size:large">her/his needs and/or convent= ions . With respect to LGPL license such an action is not <br></div><div st= yle=3D"font-family:tahoma,sans-serif;font-size:large">necessary if the abov= e defined publically accessible repository is used .</div></div></div></div= ></blockquote></div></div><div dir=3D"auto"><br></div></div></blockquote><d= iv><br></div><div><br></div><div><br></div><div><br></div><div><br></div><d= iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto">All of tha= t 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 libdia= log or libreadline has has in the past.</div><div dir=3D"auto"><br></div><d= iv dir=3D"auto">Warner</div><div dir=3D"auto"><br></div></div></blockquote>= <div><br></div><div><br></div><div><br></div><div><div style=3D"font-family= :tahoma,sans-serif;font-size:large" class=3D"gmail_default">You are right .= =C2=A0 <br></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">If=C2=A0=C2=A0 src/gnu/lib = =C2=A0 is included in FreeBSD base=C2=A0 AND=C2=A0 some users want to exclu= de these</div><div style=3D"font-family:tahoma,sans-serif;font-size:large" = class=3D"gmail_default">from the FreeBSD base ( or releases )<br></div><div= style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_def= ault"><br></div><div style=3D"font-family:tahoma,sans-serif;font-size:large= " class=3D"gmail_default">then=C2=A0 a possible action would be my suggesti= on <br></div><div style=3D"font-family:tahoma,sans-serif;font-size:large" c= lass=3D"gmail_default">( as move it into , for example ,=C2=A0=C2=A0=C2=A0 = /gnu/lib/...=C2=A0=C2=A0=C2=A0 and exclude it from the FreeBSD base ,</div>= <div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail= _default">by supplying its Internet access link in releases )</div><div sty= le=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default= ">among other ( possibly many ) alternatives .<br></div><div style=3D"font-= family:tahoma,sans-serif;font-size:large" class=3D"gmail_default"></div></d= iv><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"auto"><div dir=3D"auto"></div><div dir=3D"auto"><div= class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d= iv dir=3D"ltr"><div class=3D"gmail_quote"><div><div style=3D"font-family:ta= homa,sans-serif;font-size:large"><br></div><div style=3D"font-family:tahoma= ,sans-serif;font-size:large">Mehmet Erol Sanliturk<br></div></div></div></d= iv></blockquote></div></div></div></blockquote><div>=C2=A0</div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">= <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= "><div dir=3D"ltr"><div class=3D"gmail_quote"><div><div style=3D"font-famil= y:tahoma,sans-serif;font-size:large"></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" rel=3D"noreferrer" target=3D"_blank">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> </blockquote></div></div> --0000000000008aa1ab05d4b1d05a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMtnQ3DNSYv%2BJN1dsi1qH5=4ZJw=tmM6rVLRM0eCe6gUUQ>