3:10 p.m.
On Tue, Jun 14, 2022 at 3:04 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
Ah yes, the old - add some extra stuff to the standard LGPL or GPL license header...
which really doesn't seem to do anyone downstream any favors, but I digress.
Note - the project does include a full copy of the standard LGPL in the repo. This
license notice seems to appear in another .txt file at the top-level, but more notably
(and more expected) as the license notice in the actual source files, see:
https://github.com/mjsottile/sfsexp/blob/master/src/cstring.c
I think the operative question is: Could this additional stuff in the license header be
seen to modify the standard terms of LGPL-2.1
It's really just the first paragraph at issue as the rest of the license header is
the standard language LGPL recommends in "how to apply these license terms"
Here are my thoughts below, by sentence. I'll be curious to hear if Richard agrees!
On 6/12/22 4:38 PM, Ian McInerney wrote:
When verifying the license for sfsexp
(https://bugzilla.redhat.com/show_bug.cgi?id=2095717) in my review, I noticed it appears
to have a modification to the LGPLv2+ license on it. The full license text provided by the
package is:
Copyright (2003-2006). The Regents of the University of California.
usual copyright notice - nothing unusual here
This
material was produced under U.S. Government contract W-7405-ENG-36 for Los
Alamos National Laboratory, which is operated by the University of
California for the U.S. Department of Energy.
This statement is informational, nothing that could be considered a license term here.
The U.S. Government has rights
to use, reproduce, and distribute this software.
This also seems like a simply statement of fact/reality.
NEITHER THE GOVERNMENT NOR
THE UNIVERSITY MAKES ANY WARRANTY, EXPRESS OR IMPLIED, OR ASSUMES ANY
LIABILITY FOR THE USE OF THIS SOFTWARE.
Not sure why someone felt the need to add this when it's covered in the standard
license notice, but more importantly, this more specific version of disclaimer of warranty
- that is, "express or implied" is stated in the LGPL license, so I do not see
this as adding anything more/different.
If software is modified to produce
derivative works, such modified software should be clearly marked, so as not
to confuse it with the version available from LANL.
LGPL section 2(b) states, "You must cause the files modified to carry prominent
notices stating that you changed the files and the date of any change." which I'd
consider functionally the same as "carry prominent notices", so I also don't
see this as adding anything more/different.
This is really the only somewhat interesting issue. I agree this
doesn't say anything more restrictive than what you (nominally) have
in LGPLv2.1. There's a long tradition in FOSS (in Fedora, certainly)
of treating "should" (which is ambiguous in English) as not referring
to something mandatory.
Additionally, this library is free software; you can redistribute it
and/or
modify it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of the
License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
for more details.
You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, U SA
LA-CC-04-094
(taken from https://github.com/mjsottile/sfsexp/blob/master/COPYING).
This to me reads as a modification to the normal LGPL (since it puts requirements that
derivative works be clearly marked as distinct). Is this modification acceptable for
inclusion in Fedora?
Given I don't think anything in the "custom" license notice doesn't
add, takeaway or modify the standard terms of the LGPL-21., I'd just consider this as
LGPL-2.1-or-later.
I'd consider it not meaningfully different from LGPLv2.1-or-later.
Whether it is properly representable as SPDX: LGPL-2.1-or-later is
something Jilayne and I are currently discussing off-list, but that is
not really pertinent to Ian's question (but does relate to the ongoing
project to migrate to use of SPDX identifiers in spec file License:
fields).
Richard