On Tue, Jun 14, 2022 at 4:11 PM Richard Fontana <[email protected]> wrote: > > On Tue, Jun 14, 2022 at 3:04 PM Jilayne Lovejoy <[email protected]> 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). >
This is one of those examples of something where I don't think it's worth actually capturing as something distinctly different from the standard LGPL-2.1-or-later / LGPL-2.1+ / LGPLv2+ identifier. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ legal mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
