Re: LGPL code in /usr/tests?

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 .


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