From nobody Mon Jan 3 17:32:22 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC2A11939943 for ; Mon, 3 Jan 2022 17:33:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSNB45Q0Sz4pM6; Mon, 3 Jan 2022 17:33:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id s1so71310016wrg.1; Mon, 03 Jan 2022 09:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j5fl/73F2nZvRFrMTHlS3G6K17DA4DJVN3Q7WDU5n7g=; b=Lhbvzf/Qf+hGiEkFar+cmQnoyWEcZ47Zht0Vm+R3o+YHm30GLteaX6sFFz9tV/XGY5 /AQbSKWLja50hwLT3GRr9s0p/0RlP/AULbMU0CIb4/utEIpUsfk9gskZeAlfIo0Zy21o cMa2mOnjYhgdBTapCDNLDglvbegVCnK6CaFP2rZYIFA6tCN5vpq6+8eMQibVqKUIKfHS YHFa1JDAvuumo/vI2Odq1kTIDwQ/fiL7nSs/gfslyFOJadELaOoFwXwZBHLauohBqM7G XJ9iysWzkjKQCCUajkY75RtsKJOGTiGdpoLgP6tlZiqBoatRrGRBtSbJpv4iHinT0lWt ViHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j5fl/73F2nZvRFrMTHlS3G6K17DA4DJVN3Q7WDU5n7g=; b=mjLdIxEdPmwMxdt0v7Tky6xGjV8TBIFDDWtZ8tob7B5FJ3wlmNKwb5/ILS6YlLf4xs kFQI4+hDObehGYVMAHOCQEsayzEWfvCCAcbhq5HfpLsYo/7JDCL5yg9t0IytJnXC4IP8 9W/iwhpvogpx20EryVbWsYrVezg49ukfObddAXqZTCj4GUcylycTXFvOaW9kSFaGE8Tt xGhVcH3zoa4AARG7VEHFSPPMt9dq17cuPMpYoy9Q1kEf6hrxWgoMY1BXfY748DGUs7E9 1q13Sk402Se1HU7JqAMJp824rPHIEGDFL2ytjjNKYNaNswFhBk/l226d33OMtubCfcGK DcYQ== X-Gm-Message-State: AOAM530fLzeocYdMXD8fkehXAydvoQQyAR1/u3Bndgn8WX2hN576ZZHS WTdIOXT6dWwfgSB346+wO03EIrerHFv8ng/E3vczmDgfV4A9zQ== X-Google-Smtp-Source: ABdhPJwQp+ZKBE15BNIfAlYINqESRGRp4nUfKfZ8prXnDK7iuWPVMEcRSifASpD2ZBFQAoie60CwRMzsXEcB7XBoaCc= X-Received: by 2002:adf:e0c8:: with SMTP id m8mr17758596wri.609.1641231179250; Mon, 03 Jan 2022 09:32:59 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Mon, 3 Jan 2022 20:32:22 +0300 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Alan Somers Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000006eff9605d4b0e9d0" X-Rspamd-Queue-Id: 4JSNB45Q0Sz4pM6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000006eff9605d4b0e9d0 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 7:57 PM Alan Somers wrote: > On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk > wrote: > > > > > > > > On Mon, Jan 3, 2022 at 5:47 PM Alan Somers wrote: > >> > >> On Mon, Jan 3, 2022 at 12:37 AM Mehmet Erol Sanliturk > >> wrote: > >> > > >> > > >> > > >> > On Mon, Jan 3, 2022 at 9:31 AM Warner Losh 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 > 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


On Mon, Jan 3, 2022 = at 7:57 PM Alan Somers <asomers@f= reebsd.org> wrote:
On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk
<m.e.sanlit= urk@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 t= he tests protected by MK_LGPL' is fine.
>> >>
>> >> This would keep it in base, keep the testing happening, a= nd allow those who want
>> >> to omit it. This would also not run afoul of any companie= s 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 cour= se a trade off between
>> >> getting something useful from the LGPL software (better t= esting) 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 undesira= ble 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 wit= h our current CI setup
>> >> adding it as a dependency for that CI would be easy and g= ive us decent coverage).
>> >>
>> >> Warner
>> >>
>> >
>> >
>> >
>> > https://en.wikipedia.or= g/wiki/GNU_Lesser_General_Public_License
>> > GNU Lesser General Public License
>> >
>> > https://en.wikipedia.or= g/wiki/Copyleft#Strong_and_weak_copyleft
>> > Strong and weak copyleft
>> >
>> >
>> > "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 ) ,
>> >
>> > in spite of this ,
>> >
>> > "GNU General Public License" is a STRONG copyleft l= icense ( it may be considered "malignant" : it invades the user s= oftware as a whole ) .
>> >
>> >
>> > Using a ( LGPL licensed software ) for testing another softwa= re is not directly involved in the tested software .
>> >
>> > 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= ) .
>> >
>> >
>> > Mehmet=C2=A0 Erol Sanliturk
>>
>
>
>
>
>
>>
>> The problem is that the library, not just the headers, needs to be=
>> present at compile time.=C2=A0 Or do you know a good workaround? >
>
>
>
> You can fetch the LGPL licensed sources during compile time from outsi= de of the FreeBSD
> base known to the testing program . The user(s) of=C2=A0 FreeBSD can a= lso 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 so= urces=C2=A0 which
> can not be used for a ( free or commercial ) distribution . During pro= gram development ,
> it is possible to use them , because they are in there just as a fille= r for=C2=A0 not-implemented-yet parts .
>
> To prevent unacceptable inclusion of such sources into my own producti= ons , I am
> using global directories=C2=A0 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 n= ot be used .
> There is no danger of including them erroneously .
>
>
> You can define such directories . During compilation you may fetch LGP= L 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 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 .
>
>
> The main problem for the LGPL licensed sources is the modifications pe= rformed
> in them . If there are such parts they should be open sourced , not th= e sources of the
> user sources . The closed source programs will not be affected from su= ch modifications .
>
> Some closed source program developers may not want to handle legal imp= lications of
> 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
> 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 .
>
> Generation of a package or port from this repository=C2=A0 may be nece= ssary 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 abov= e model
> may not require either a port or a package separately because=C2=A0 ev= erything necessary
> will be in the repository .
>
>
>
> Mehmet Erol Sanliturk





=C2=A0
So you suggest that "make buildworld" downloads the libnfs source= s?
That would be a big change from the current setup, where all sources
are assumed to be present when make starts.=C2=A0 I expect that it might break tools like "make release" and nanobsd, too.=C2=A0 Of course= , we could
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
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 .=C2=A0

Fetchi= ng 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=C2=A0 main repo= sitory , then again the action will be
"fetch and = store them , and keep them in there" .
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 ) .
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=C2=A0 | release }"
or other processing works .


Since it is possible to keep the LGPL licensed sources ( by fet= ching modifications from its repository ) indefinitely , my opinion
is that continuous use of these sources are legally possible and ha= rmless .
( 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 ma= y discard the
global directory contents when she/he complete= s 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 a= ction is not
necessary if the above defined publically = accessible repository is used .


Mehmet Erol Sanliturk




=C2=A0
>
>
>
>
>>
>>
>> >
>> >
>> >
>> >
>> >>
>> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers <asomers@freebsd.org&g= t; wrote:
>> >>>
>> >>> I recently ran into a bug in fusefs that can only be = triggered when
>> >>> NFS exports a FUSE file system.=C2=A0 That makes it v= ery difficult to write
>> >>> an automated test.=C2=A0 My options are basically: >> >>>
>> >>> * Add an fhgetdirentries(2) syscall that is like getd= irentries, but
>> >>> takes a fhandle_t* argument instead of a file descrip= tor.
>> >>> * Actually start nfsd during the test, and export the= temporary FUSE filesystem.
>> >>>
>> >>> The first option sounds like way too much non-test co= de to change.
>> >>> Plus, I may need to add thread() and fhwrite() syscal= ls too, for other
>> >>> NFS-related test cases.=C2=A0 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 f= ile system?=C2=A0 Mounting
>> >>> it with the NFS client would add several more layers = to the stack
>> >>> under test.=C2=A0 I'm not even sure that it's= safe to self-mount an
>> >>> exported file system.=C2=A0 Another option would be t= o communicate directly
>> >>> with nfsd from the test code.=C2=A0 That's possib= le, but writing NFS RPCs
>> >>> by hand is very cumbersome, and it would obscure the = test logic.=C2=A0 A
>> >>> better option is to use libnfs.=C2=A0 The API is just= what I would need.
>> >>> However, it's licensed under the LGPL 2.1.=C2=A0 = I know that we as a
>> >>> project decided to import no new GPLish code into con= trib/.=C2=A0 But this
>> >>> code would never be used outside of /usr/tests, so it= wouldn't even
>> >>> affect many production builds.=C2=A0 Would that be ac= ceptable?=C2=A0 The
>> >>> workarounds are ugly:
>> >>>
>> >>> * Create a new port for all libnfs-dependent tests.= =C2=A0 This would be
>> >>> hard to maintain, because the content of the tests mu= st be so
>> >>> dependent on the base version of the OS.
>> >>> * Write the tests in Python using libnfs-python.=C2= =A0 The tests could
>> >>> still be compiled as part of the base system, they ju= st wouldn't work
>> >>> unless libnfs-python is installed from ports.=C2=A0 B= ut this is awkward
>> >>> because the tests are currently C++.=C2=A0 So I would= have to embed a
>> >>> Python interpreter into the C++ code.=C2=A0 It would = really obfuscate the
>> >>> test logic.
>> >>> * Store the tests in the base system, but detached fr= om the build.
>> >>> Then create a port that builds them by mounting SRC_B= ASE, much like
>> >>> devel/py-libzfs does.=C2=A0 It would then install the= m in /usr/local/tests.
>> >>> This is probably the least-bad option if I can't = import libnfs into
>> >>> contrib/.
>> >>>
>> >>> What do you think?=C2=A0 Is it acceptable to import l= ibnfs intro contrib/?
>> >>> It's LGPL, except for a few headers that are BSD = and some examples
>> >>> that are GPLv3.=C2=A0 But we needn't use the exam= ples, or even import them.
>> >>>
>> >>> https://github.com/sahlberg/libnfs
>> >>>
--0000000000006eff9605d4b0e9d0--