On 6/14/22 2:20 PM, Neal Gompa wrote:
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.
yeah, I find comfort in that LGPL says "must" which is obligatory
language, whereas their addition says "should" - I look at that as not
imposing more than LGPL already requires, but also not rising to the
level of an "exception".
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).
For the purposes of capturing the license in the spec file in Fedora for
this package, I think 1) Ian did the exactly right thing by raising this
question here; 2) good to have a closer look; and 3) the spec file
License: field can fairly state LGPL-2.0-or-later
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.
Something that is legally not substantively different is not worth
capturing in the License: field of the spec file. However, if the
additional paragraph purported to modify the existing terms of LGPL-2.1
(what if it said, "No commercial use" or "You must also send us an email
letting us know where you are using this project" for example) - then
the answer would likely be different. There will be these kinds
case-by-case scenarios that need a closer look. There is no way around
that reality. But also remember you aren't the "audience" for the spec
License: field - all the downstream recipients are.
Anyway, let's not worry about the many other possiblities and focus on
the question at hand, so Ian is not delayed in the rest of his work :)
_______________________________________________
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
