From nobody Mon Jan 3 07:37:13 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 40F31192C620 for ; Mon, 3 Jan 2022 07:37:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 4JS6zV0MLPz4T09; Mon, 3 Jan 2022 07:37:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id n10-20020a7bc5ca000000b00345c520d38eso17922586wmk.1; Sun, 02 Jan 2022 23:37:58 -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=tRT+Z1E4vD6PjbyOdutkFa8Ibg3UEMaJ9r3IJojqqzs=; b=egJKE95Gmay2Ed2LPsoAfXCNGmcQ6d/BgVHfcEMVZLkxJOxZBvx16UXb2G73PeDP32 sirL56bZtVxInH5GgHrJzhcVf3vKO+8Xjsz3idUrsJiToTiLknTODIdFaSV/JkXUy9wG EhcaeBIYmlnOGZUYOqR2z7QdMDzQQbiAP29AbLP3PWhtmBR0e7edDOpq+BTgdMT+XVWJ 7OcmLY6+lxbn+aO11H7JTHNWX8uUGWQrs04TfrTthn+cwHHHDzK2Lqv1ZLAVivR3kDo7 L8LHlZrueB0fLfHbe+p5jqTna+9aE51tHsujD4o+TW9PPiyqIfN7r4ussIAi7wM20NDn B9Fg== 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=tRT+Z1E4vD6PjbyOdutkFa8Ibg3UEMaJ9r3IJojqqzs=; b=Kgnr6Ro6f7RIFL35jCta/6VmvPczW5GIJb6+BqwCRq4dM2wDVKg8eM6Y8HcmiogYfS wTCS95jMMJegmt5ijCB1aetz8aTL/hq0dhIAKo1Meh9A/YR1effvMoxyMcJuQSr5kDDG /liB3NkMOSNUF3aYaY+wg+cgqN0zN7G2I40Xe52iISo8H/+uoPNIZW6GOqAGxf6xI5tg ky9yrVl7I9+M3xiuh5zekIbtoZBtVhJWP0GyKqdxNMf2EJ0DAmStogkoPHeEbJNrnWsl VrnqwuFM87m+iBOXvVaEqvqNSGIeEvRyatmrjLkN5NbIsFmaA4HLwMZP6Qg3tt+frvf6 t4uA== X-Gm-Message-State: AOAM533cpZ7L50swJM7nvlg7TQtCISpBmrJMy0A0XXJEvPK2rXlM1OPy LBeMU1gT6eGWi9Ui846UISe4v0xjFOWUE5uSBsucxVTb62rs0w== X-Google-Smtp-Source: ABdhPJwtXmasIOVZd0ceQoR8y9sSZrOv7Wrq1JcR1kyiHsY0eemqwN1tX3lRzJ8uQz1Uo56envDHWtx+G2cAvv9KCdA= X-Received: by 2002:a05:600c:3c9b:: with SMTP id bg27mr37610829wmb.163.1641195469843; Sun, 02 Jan 2022 23:37:49 -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 10:37:13 +0300 Message-ID: Subject: Re: LGPL code in /usr/tests? To: Warner Losh Cc: Alan Somers , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000fcb10105d4a898a6" X-Rspamd-Queue-Id: 4JS6zV0MLPz4T09 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 --000000000000fcb10105d4a898a6 Content-Type: text/plain; charset="UTF-8" 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 > 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 >> >> --000000000000fcb10105d4a898a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022 = at 9:31 AM Warner Losh <imp@bsdimp.com= > wrote:
=
Top posting my reactions (sorry)

=
I think=C2=A0'in base as a private library, used only in the tests= protected by MK_LGPL' is fine.

This would kee= p 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 hav= e 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 som= ething 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 l= et it be shut
off easily with all the tests disabled that depend = on it. This is also in keeping with
our historical practices of h= aving software with undesirable=C2=A0licenses as long as it
gets = us something.

I think this is better than the port= s 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 co= verage).

Warner

<= br>


GNU Lesser General Public L= icense

Strong and weak copyleft
<= div>

"GNU Lesser Genera= l 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 software ) ,

in spite of this ,<= br>

"GNU = General Public License" is a STRONG copyleft license ( it may be consi= dered "malignant" : it invades the user software as a whole ) .


Using a ( LGPL = licensed software ) for testing another software is not directly involved i= n the tested software .

To elimin= ate 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=C2=A0 Erol Sanliturk



=C2=A0
=
On Fri, Dec 31, 20= 21 at 2:22 PM Alan Somers <asomers@freebsd.org> wrote:
I recently ran into a bug in fusefs that c= an only be triggered when
NFS exports a FUSE file system.=C2=A0 That makes it very difficult to write=
an automated test.=C2=A0 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 filesy= stem.

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.=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 file system?=C2=A0 Moun= ting
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 to communicate directly=
with nfsd from the test code.=C2=A0 That's possible, but writing NFS RP= Cs
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 contrib/.=C2=A0 But this<= br> code would never be used outside of /usr/tests, so it wouldn't even
affect many production builds.=C2=A0 Would that be acceptable?=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 must 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 just wouldn't work unless libnfs-python is installed from ports.=C2=A0 But 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 from the build.
Then create a port that builds them by mounting SRC_BASE, much like
devel/py-libzfs does.=C2=A0 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?=C2=A0 Is it acceptable to import libnfs intro contrib/?<= br> 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 examples, or even import t= hem.

https://github.com/sahlberg/libnfs

--000000000000fcb10105d4a898a6--