Date: Mon, 3 Jan 2022 19:31:33 +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: <CAOgwaMuzMukKrgntYps6_rSO88=jMG6QLF0SVrs8r9kF=KesAA@mail.gmail.com> In-Reply-To: <CAOtMX2iPxZWr_nc8uVEPhxgmLkdzKeMvH%2BtWU99u%2Bpk8Hs=3Aw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000ee500205d4b00f39 Content-Type: text/plain; charset="UTF-8" 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 > > > > > > > > > > >> > >> 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 > >>> > --000000000000ee500205d4b00f39 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 5:47 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 12:37 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 9:31 AM Warner Losh <<a href=3D"mailto:imp@b= sdimp.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 the tests = protected by MK_LGPL' is fine.<br> >><br> >> This would keep it in base, keep the testing happening, and allow = those who want<br> >> to omit it. This would also not run afoul of any companies that st= ill 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 course a trad= e off between<br> >> getting something useful from the LGPL software (better testing) a= nd our desires<br> >> not to have any in the tree at all, if possible. Adding a knob wou= ld 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 undesirable licen= ses 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 with our cur= rent CI setup<br> >> adding it as a dependency for that CI would be easy and give us de= cent coverage).<br> >><br> >> Warner<br> >><br> ><br> ><br> ><br> > <a href=3D"https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Lic= ense" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/GN= U_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_copy= left" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Co= pyleft#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 invade the= user software , affects only the modifications to the LGPL licensed softwa= re ) ,<br> ><br> > in spite of this ,<br> ><br> > "GNU General Public License" is a STRONG copyleft license ( = it may be considered "malignant" : it invades the user software a= s a whole ) .<br> ><br> ><br> > Using a ( LGPL licensed software ) for testing another software is not= directly involved in the tested software .<br> ><br> > 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 dynam= ically loaded library ( manage it port with respect to its license ) .<br> ><br> ><br> > Mehmet=C2=A0 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"> 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?<br></block= quote><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 can f= etch the LGPL licensed sources during compile time from outside of the Free= BSD</div><div style=3D"font-family:tahoma,sans-serif;font-size:large" class= =3D"gmail_default">base known to the testing program . The user(s) of=C2=A0= FreeBSD can also use a similar facility .</div><div style=3D"font-family:t= ahoma,sans-serif;font-size:large" class=3D"gmail_default"><br></div><div st= yle=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_defaul= t">For example :</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">I am developing mainly = two programs :</div><div style=3D"font-family:tahoma,sans-serif;font-size:l= arge" class=3D"gmail_default"><br></div><div style=3D"font-family:tahoma,sa= ns-serif;font-size:large" class=3D"gmail_default">(1) Mathematical Analysis= computations <br></div><div style=3D"font-family:tahoma,sans-serif;font-si= ze:large" class=3D"gmail_default">(2) A Multi-media information management = system</div><div style=3D"font-family:tahoma,sans-serif;font-size:large" cl= ass=3D"gmail_default"><br></div><div style=3D"font-family:tahoma,sans-serif= ;font-size:large" class=3D"gmail_default">These programs are using parts ta= ken from legally personally usable sources=C2=A0 which <br></div><div style= =3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default">= can not be used for a ( free or commercial ) distribution . During program = development , <br></div><div style=3D"font-family:tahoma,sans-serif;font-si= ze:large" class=3D"gmail_default">it is possible to use them , because they= are in there just as a filler for=C2=A0 not-implemented-yet parts .<br></d= iv><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gm= ail_default"><br></div><div style=3D"font-family:tahoma,sans-serif;font-siz= e:large" class=3D"gmail_default">To prevent unacceptable inclusion of such = sources into my own productions , I am</div><div style=3D"font-family:tahom= a,sans-serif;font-size:large" class=3D"gmail_default">using global director= ies=C2=A0 outside of the program directories :</div><div style=3D"font-fami= ly:tahoma,sans-serif;font-size:large" class=3D"gmail_default"><br></div><di= v style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_de= fault">/KBMS/Parts_to_ be_Removed/... ( Part specific directories )<br></di= v><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gma= il_default">/MAS/Parts_to_ be_Removed/... ( Part specific directories )</di= v><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gma= il_default"><br></div><div style=3D"font-family:tahoma,sans-serif;font-size= :large" class=3D"gmail_default">It is explicitly known that these directori= es and their contents can not be used .</div><div style=3D"font-family:taho= ma,sans-serif;font-size:large" class=3D"gmail_default">There is no danger o= f including them erroneously .</div><div style=3D"font-family:tahoma,sans-s= erif;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;font-size:large" class=3D"gmai= l_default">You can define such directories . During compilation you may fet= ch LGPL licensed <br></div><div style=3D"font-family:tahoma,sans-serif;font= -size:large" class=3D"gmail_default">parts from these directories ( even th= ough they may be on the Internet ) . After compilation of</div><div style= =3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default">= the programs ( and if they are executed ) you may discard them . By supplyi= ng a script to manage such issues , users of the FreeBSD may also use the a= ssociated external directories created in their systems and used during the= ir works . <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,s= ans-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">The = main problem for the LGPL licensed sources is the modifications performed <= br></div><div style=3D"font-family:tahoma,sans-serif;font-size:large" class= =3D"gmail_default">in them . If there are such parts they should be open so= urced , not the sources of the</div><div style=3D"font-family:tahoma,sans-s= erif;font-size:large" class=3D"gmail_default">user sources . The closed sou= rce programs will not be affected from such modifications .</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" clas= s=3D"gmail_default">Some closed source program developers may not want to h= andle legal implications of</div><div style=3D"font-family:tahoma,sans-seri= f;font-size:large" class=3D"gmail_default">these modified or not modified L= GPL licensed parts even when they are distributed=C2=A0 because any failure= of distribution of especially modified sources may cause significant troub= le for them . To eliminate such distribution related concerns , the best ac= tion may be to store <br></div><div style=3D"font-family:tahoma,sans-serif;= font-size:large" class=3D"gmail_default">these sources into a publicly acce= ssible repository , modify these sources in that repository and use them=C2= =A0 from this repository . In this case , modifications in the main reposit= ory and excluding of these from FreeBSD distributions will not affect FreeB= SD users other than fetching them when they are needed , which is legally a= cceptable and harmless .</div><div style=3D"font-family:tahoma,sans-serif;f= ont-size:large" class=3D"gmail_default"><br></div><div style=3D"font-family= :tahoma,sans-serif;font-size:large" class=3D"gmail_default">Generation of a= package or port from this repository=C2=A0 may be necessary or not , <br><= /div><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"= gmail_default">I will not be able to say anything because I do not know . T= he port or package <br></div><div style=3D"font-family:tahoma,sans-serif;fo= nt-size:large" class=3D"gmail_default">generator persons would know such po= ints . My opinion is that the above model <br></div><div style=3D"font-fami= ly:tahoma,sans-serif;font-size:large" class=3D"gmail_default">may not requi= re either a port or a package separately because=C2=A0 everything necessary= <br></div><div style=3D"font-family:tahoma,sans-serif;font-size:large" cla= ss=3D"gmail_default">will be in the repository .<br></div><div style=3D"fon= t-family:tahoma,sans-serif;font-size:large" class=3D"gmail_default"><br></d= iv><div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gm= ail_default"><br></div><div style=3D"font-family:tahoma,sans-serif;font-siz= e:large" 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></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"><br></div></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"> <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>> wrote:<b= r> >>><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 very diffi= cult 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 temporar= y FUSE filesystem.<br> >>><br> >>> The first option sounds like way too much non-test code to cha= nge.<br> >>> Plus, I may need to add thread() and fhwrite() syscalls too, f= or 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 syste= m?=C2=A0 Mounting<br> >>> it with the NFS client would add several more layers to the st= ack<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 communi= cate directly<br> >>> with nfsd from the test code.=C2=A0 That's possible, but w= riting NFS RPCs<br> >>> by hand is very cumbersome, and it would obscure the test logi= c.=C2=A0 A<br> >>> better option is to use libnfs.=C2=A0 The API is just what I w= ould need.<br> >>> However, it's licensed under the LGPL 2.1.=C2=A0 I know th= at 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&#= 39;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 tes= ts could<br> >>> still be compiled as part of the base system, they just wouldn= 't work<br> >>> unless libnfs-python is installed from ports.=C2=A0 But this i= s 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 ob= fuscate the<br> >>> test logic.<br> >>> * Store the tests in the base system, but detached from the bu= ild.<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 li= bnfs into<br> >>> contrib/.<br> >>><br> >>> What do you think?=C2=A0 Is it acceptable to import libnfs int= ro 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 them.<br> >>><br> >>> <a href=3D"https://github.com/sahlberg/libnfs" rel=3D"noreferr= er" target=3D"_blank">https://github.com/sahlberg/libnfs</a><br>; >>><br> </blockquote></div></div> --000000000000ee500205d4b00f39--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMuzMukKrgntYps6_rSO88=jMG6QLF0SVrs8r9kF=KesAA>