From nobody Mon Jan 3 14:47:42 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 6FA3F1933F3F for ; Mon, 3 Jan 2022 14:48:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (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 4JSJWj2g9Bz3pC9 for ; Mon, 3 Jan 2022 14:48:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f169.google.com with SMTP id w80so16827633oie.9 for ; Mon, 03 Jan 2022 06:48:01 -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; bh=k+OxMAnRRM/2K+ajJAatU7ptb76GJHe0O0AjOs7SCos=; b=HlDySeXEEo6T+2fDuWgg7E/1T6P30qtSlXO7jgnzTjevfGUhM74i4uG7wjfGbCgzv2 U9ob0SspoUpdy7XkGx9J0OL3e5ho5wnRe0fst/NJydQX6Uux2suDaNztgXsLKx9sAwuh qA55XhvP4jTGr2tjiI+0mvJe6Q9liQvWCKeaGm/mFTfjbHsGdm/ZSAU6aNinN4qOJ3hS eSLIwTr85JNk6hpM/VaUnQO+ovssqPdtkiFdvALN+Ow/YzwhOz4U9qf0aXuRNm+N4WiR fVaip9zVkXQPMKlKifQa5KiY4GMtyJFZ41FA5REavOg3nwW6yz5QjWpnOXiLvHWaQEoX Jn3Q== X-Gm-Message-State: AOAM530seGulItH9SN4Jm9JgflFnAuuK0r/icKb86KX/5i2ubDvil7MC z/B0hMo4j7HSvYPMsLoLeNoNnZ9V4LkD2YMG8NA= X-Google-Smtp-Source: ABdhPJw5ppq4hFqc9y2fpKDkotjopYZ+tmYLOGNIitifZkbALNxvsA5DyLrvDvgrqOFgkLD7SfCJ2CaTpdT3ieZxbXU= X-Received: by 2002:aca:1001:: with SMTP id 1mr35418685oiq.55.1641221273913; Mon, 03 Jan 2022 06:47:53 -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 07:47:42 -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" X-Rspamd-Queue-Id: 4JSJWj2g9Bz3pC9 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 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? > > > > >> >> 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 >>>