From nobody Mon Jan 3 16:56:49 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 EE8B419321A3 for ; Mon, 3 Jan 2022 16:57:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 4JSMNg6F3wz4j3P for ; Mon, 3 Jan 2022 16:57:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f47.google.com with SMTP id w19-20020a056830061300b0058f1dd48932so43764550oti.11 for ; Mon, 03 Jan 2022 08:57:07 -0800 (PST) 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:content-transfer-encoding; bh=OLTkNO3h6bZQbupevbaL4l4yKokfB74b2E6JIjXyoS4=; b=j+jzP43TXFiIFpnBWs7t78w9vnjLHWGl8S+d2oCLnBvJAM1tY2VWOqltrSq0aHH+gh JHSNcFrGdxiCdtGLXmiZ/zeE+/jdXz3ByKqlHvlxQWp2RAUjs3pqYA9p+i/yvoeIQVCz wtqCy2IJkZ1YNmMTgMvzW6ZxdJtjba2sNBeVjnTTOJDwqZ2HR7SfQBDogK14DufwunkE URvKhpJjFL1rD9yj7EmP/SSShNxpaodVu6CQNC4aBVjG1TOJVrRMCn86JILoN0jxd9wO vsjVd5iYHnBTJGVUkTsVW5JK0Ew1/AxiTMky1AkyfkkrtfE5foJ9nOyMF9Lvc+TARjUW uMBg== X-Gm-Message-State: AOAM531NPzhwTV8gqmzxWaJz+iiZZETdNmw6qRiPJ0zAxLHRDjcHsDhZ e+NKOf56lbFVb2aby1u5EATm56IfopFRBmBoI36KZnP2 X-Google-Smtp-Source: ABdhPJxX8Q7haapwWPQ0iQ4VI+PCDMI0znKB2D//Z/u4Hd6ORH98BttpC+MZvdo3L67x0yaSj3IruQShK7fg9fWHsbQ= X-Received: by 2002:a9d:554f:: with SMTP id h15mr34388717oti.111.1641229020914; Mon, 03 Jan 2022 08:57:00 -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: Alan Somers Date: Mon, 3 Jan 2022 09:56:49 -0700 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Mehmet Erol Sanliturk Cc: Warner Losh , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JSMNg6F3wz4j3P X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 protect= ed by MK_LGPL' is fine. >> >> >> >> This would keep it in base, keep the testing happening, and allow tho= se 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 o= ff 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 als= o 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 mor= e use and exposure >> >> this way and is more likely to remain working (though with our curren= t CI setup >> >> adding it as a dependency for that CI would be easy and give us decen= t 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 m= ay 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 dynam= ically 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 sourc= es which > can not be used for a ( free or commercial ) distribution . During progra= m development , > it is possible to use them , because they are in there just as a filler f= or 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 l= icensed > 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 suppl= ying a script to manage such issues , users of the FreeBSD may also use the= associated external directories created in their systems and used during t= heir works . > > > The main problem for the LGPL licensed sources is the modifications perfo= rmed > in them . If there are such parts they should be open sourced , not the s= ources 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 implic= ations of > these modified or not modified LGPL licensed parts even when they are dis= tributed because any failure of distribution of especially modified source= s may cause significant trouble for them . To eliminate such distribution r= elated concerns , the best action may be to store > these sources into a publicly accessible repository , modify these source= s in that repository and use them from this repository . In this case , mo= difications in the main repository and excluding of these from FreeBSD dist= ributions 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 pa= ckage > generator persons would know such points . My opinion is that the above m= odel > 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. > > > > >> >> >> > >> > >> > >> > >> >> >> >> On Fri, Dec 31, 2021 at 2:22 PM Alan Somers wro= te: >> >>> >> >>> 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 wri= te >> >>> 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 oth= er >> >>> 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? Mounti= ng >> >>> 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 direct= ly >> >>> 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 thi= s >> >>> 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 wor= k >> >>> 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/test= s. >> >>> 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 the= m. >> >>> >> >>> https://github.com/sahlberg/libnfs >> >>>