Re: LGPL code in /usr/tests?

On Mon, Jan 3, 2022 at 9:32 AM Mehmet Erol Sanliturk
<m.e.sanliturk@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 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.

>
>
>
>
>>
>>
>> >
>> >
>> >
>> >
>> >>
>> >> 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
>> >>>