Re: LGPL code in /usr/tests?

On Mon, Jan 3, 2022 at 9:06 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Mon, Jan 3, 2022, 10:32 AM Mehmet Erol Sanliturk <
> m.e.sanliturk@gmail.com> wrote:
>
>>
>>
>> On Mon, Jan 3, 2022 at 7:57 PM Alan Somers <asomers@freebsd.org> wrote:
>>
>>> 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.
>>>
>>>
>>
>>
>>
>> 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 .
>>
>
>







> All of that is covered by our existing practice of storing LGPL code in
> src/gnu/lib. We cover it in the handbook already. Since it is publicly
> available forever, storing it there will have no impact that's any
> different than libdialog or libreadline has has in the past.
>
> Warner
>
>


You are right .

If   src/gnu/lib   is included in FreeBSD base  AND  some users want to
exclude these
from the FreeBSD base ( or releases )

then  a possible action would be my suggestion
( as move it into , for example ,    /gnu/lib/...    and exclude it from
the FreeBSD base ,
by supplying its Internet access link in releases )
among other ( possibly many ) alternatives .



>
>> Mehmet Erol Sanliturk
>>
>

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