Here's another couple
by David Cantrell
xmalloc.c from tmux:
/*
* Author: Tatu Ylonen <ylo(a)cs.hut.fi>
* Copyright (c) 1995 Tatu Ylonen <ylo(a)cs.hut.fi>, Espoo, Finland
* All rights reserved
* Created: Mon Mar 20 22:09:17 1995 ylo
*
* Versions of malloc and friends that check their results, and never return
* failure (they call fatal if they encounter an error).
*
* As far as I am concerned, the code I have written for this software
* can be used freely for any purpose. Any derived versions of this
* software must be clearly marked as such, and if the derived work is
* incompatible with the protocol description in the RFC file, it must be
* called by a name other than "ssh" or "Secure Shell".
*/
Which to me means this originated from the original ssh, not that that's
relevant. Just historical. So how does this one match?
And what about:
/*
* Portions Copyright (c) 1995 by International Business Machines, Inc.
*
* International Business Machines, Inc. (hereinafter called IBM) grants
* permission under its copyrights to use, copy, modify, and distribute this
* Software with or without fee, provided that the above copyright notice and
* all paragraphs of this notice appear in all copies, and that the name of IBM
* not be used in connection with the marketing of any product incorporating
* the Software or modifications thereof, without specific, written prior
* permission.
*
* To the extent it has a right to do so, IBM grants an immunity from suit
* under its patents, if any, for the use, sale or manufacture of products to
* the extent that such products are used for performing Domain Name System
* dynamic updates in TCP/IP networks by means of the Software. No immunity is
* granted for any product per se or for any other function of any product.
*
* THE SOFTWARE IS PROVIDED "AS IS", AND IBM DISCLAIMS ALL WARRANTIES,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
* PARTICULAR PURPOSE. IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL,
* DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ARISING
* OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN
* IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES.
*/
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1 year, 3 months
xscreensaver and x11-ssh-askpass licenses
by David Cantrell
Happy New Year, everyone!
Among the various packages I maintain is one called x11-ssh-askpass. The
project itself is old but still runs and there are users. I am trying to
generate an SPDX license expression for this package and am asking for help
for clarification.
x11-ssh-askpass uses code from xscreensaver (jwz.org/xscreensaver). In the
Fedora package for xscreensaver we call it MIT licensed. The xscreensaver
project provides sample spec file to build and RPM and in that spec file they
call themselves BSD licensed. However, I see this at least in xscreensaver.c:
/* xscreensaver, Copyright © 1991-2022 Jamie Zawinski <jwz(a)jwz.org>
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation. No representations are made about the suitability of this
* software for any purpose. It is provided "as is" without express or
* implied warranty.
*
Would we call this MIT? It begins mostly the same way but reduces the as-is
paragraph to I guess the last two sentences. Or would this be more ISC or
even HPND? ISC doesn't feel right but also feels less wrong somehow to me.
HPND....???
With the xscreensaver license sorted out, that leaves the remaining original
code in x11-ssh-askpass which carries this license:
The remaining portions fall under the following copyright and license:
by Jim Knoble <jmknoble(a)pobox.com>
Copyright (C) 1999,2000,2001 Jim Knoble
Permission to use, copy, modify, distribute, and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and
that both that copyright notice and this permission notice appear in
supporting documentation.
+------------+
| Disclaimer |
+------------+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
express or implied, including but not limited to the warranties of
merchantability, fitness for a particular purpose and
noninfringement. In no event shall the author(s) be liable for any
claim, damages or other liability, whether in an action of contract,
tort or otherwise, arising from, out of or in connection with the
software or the use or other dealings in the software.
Again....MIT, ISC, HPND, something else? Anyone have any ideas?
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1 year, 3 months
Guidelines for dealing with licensing issues in distributed packages
by Florian Weimer
What's the best way to raise licensing issues in already-added packages?
I think there are largely two cases:
* Fedora and its distributors comply with the licensing terms, but the
license is not obviously on Fedora's allowed list. An example would
be an obscure field-of-use restriction (as in the JSON license).
* Fedora and its distributors appear violating the license. An example
would be a package that ships a pre-built Linux kernel binary without
the required GPL notices, and without corresponding soruce code.
Do these two cases need to be treated differently? In the past, I may
have filed bugs in Bugzilla, but this might be construed as a bit rude.
I looked at <https://docs.fedoraproject.org/en-US/legal/> and couldn't
find any discussion of this topic. Sorry if I missed it.
Thanks,
Florian
1 year, 3 months
SPDX Office hours
by Miroslav Suchý
Hello.
the owners of SPDX Change proposal want to have this Change as smooth as possible. And we decided to setup Office hours.
Do you have any questions about SPDX migration?
Do you hesitate about what steps you should take?
How to proceed with your package? We will do our best to help you.
This is intended to be bi-weekly.
Every time in a different time, to match the time of different people in different time zones.
The first round will happen on Tuesday 2023-01-17 16:00-17:00 UTC. (17pm CET, 11am EST)
Google Meet joining info
Video call link: https://meet.google.com/xob-irug-qqd
Or dial: (CZ) +420 234 610 745 PIN: 559 590 845#
More phone numbers: https://tel.meet/xob-irug-qqd?pin=3490720094637
Or join via SIP: sip:3490720094637@gmeet.redhat.com
Miroslav
1 year, 3 months
License updates: c4core, grpc, libfplll, python-graph-tool, python-mapbox-earcut
by Ben Beasley
I am about to update a few packages that use header-only libraries (and which do not use them only for tests that are not installed, as is often the case with e.g. doctest-static) to include the licenses of those libraries in their SPDX license expressions. The rationale is that header-only libraries are otherwise treated as a kind of static library, and their implementations are compiled into the binary RPMs, so the licenses of the header-only libraries should be included too.
The License for c4core will be updated from MIT AND BSL-1.0 to MIT AND BSL-1.0 AND BSD-2-Clause AND (Apache-2.0 OR MIT) because it BuildRequires debugbreak-static, which is BSD-2-Clause, and fast-float-static, which is Apache-2.0 OR MIT.
The License for grpc will be updated from Apache-2.0 AND BSD-3-Clause AND MIT to Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT because it BuildRequires xxhash-static, which is BSD-2-Clause. This can be linked as a shared library or used as a header-only library (as in this case) depending on whether XXH_INCLUDE_ALL is defined.
The License for libfplll will be updated from LGPL-2.1-or-later AND MIT to LGPL-2.1-or-later AND MIT AND CC0-1.0 because it BuildRequires json-static, which is MIT AND CC0-1.0 (the latter because it includes hedley, another header-only library; see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/91#note_1151..., https://gitlab.com/fedora/legal/fedora-license-data/-/issues/32#note_1045..., https://gitlab.com/fedora/legal/fedora-license-data/-/issues/32#note_1045..., and https://github.com/nemequ/hedley/issues/56 for the full story on this).
The License for python-graph-tool will be updated from LGPL-3.0-or-later AND BSL-1.0 to LGPL-3.0-or-later AND BSL-1.0 AND GPL-3.0-or-later AND MIT AND (MIT OR Apache-2.0) because it BuildRequires CGAL-static, which hasn’t yet been converted to SPDX but should be LGPL-3.0-or-later AND GPL-3.0-or-later AND BSL-1.0 AND MIT, and pcg-cpp-static, which is MIT OR Apache-2.0.
The License for python-mapbox-earcut will be updated from ISC to ISC AND BSD-3-Clause because it BuildRequires pybind11-static, which is BSD-3-Clause.
1 year, 3 months
rust-regex-syntax package license change: added Unicode-DFS-2016 license
by Fabio Valentini
Hi all,
With the update to the regex-syntax crate package that I'm building
right now, the license will change from "MIT OR Apache-2.0" to "(MIT
OR Apache-2.0) AND Unicode-DFS-2016".
The project includes code that is derived from Unicode data files, and
it already shipped a license text for the Unicode-DFS-2016 license for
this reason - but the SPDX license string in upstream crate metadata
doesn't reflect this fact. It also appears that the inclusion of the
additional license file was made after the package was initially
reviewed for Fedora, and as a result, previous versions of this
package didn't include the Unicode license in its License tag.
I have also opened an upstream discussion about this, since I believe
that the upstream license specifier is wrong (i.e. missing " ... AND
Unicode-DFS-2016"), but upstream developers don't appear convinced
(even though similar changes were already made in equivalent cases for
other Rust projects):
https://github.com/rust-lang/regex/discussions/933
This change will probably have at least some "ripple effect" across
Rust packages in Fedora once they are rebuilt against this new
version, since basically everything depends on the "regex" crate
(which depends on regex-syntax), either directly, or indirectly.
I'm pretty sure that this package now has the the correct license tag
(i.e. project has two parts: first part is dual-licensed "MIT OR
Apache-2.0", second part is derived from Unicode data and is licensed
"Unicode-DFS-2016", so the license tag should reflect *both* parts),
but if I am wrong about this, please get my attention, so I can revert
this change in a timely manner.
Fabio
1 year, 3 months
Where are license files expected to reside?
by Mattia Verga
Does the license files of an installed foo package need to reside under /usr/share/licenses/foo/ or can they reside anywhere and the packager just needs to ensure they're installed?
The question comes out from a review of a python package [1]: since python package already installs license files properly marked as such into the dist-info dir of the package, do we have to install them using the %license tag also? I would expect them to be under /usr/share/licenses but there's nothing in the packaging guidelines about this.
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2133080#c16
1 year, 3 months
Re: Where are license files expected to reside?
by Mattia Verga
Il 04/01/23 19:11, Ben Beasley ha scritto:
> There is an FPC issue open to clarify this in the guidelines, since it comes up over and over in package reviews. The conclusion has always been that license files do not have to be in a particular directory. Someone needs to come up with a simple and well-worded statement on the matter and open a PR to update the guidelines.
>
> https://pagure.io/packaging-committee/issue/1223
>
Thanks, I wasn't aware of that ticket. It's still not clear to me, in
the ticket it is said "%license is mandatory", but doesn't %license
macro copy files under /usr/share/licenses in addition to adding the tag?
As a personal note, I don't like this solution, as you need to inspect
the built RPM to check that the license files are really installed,
while explicitly set them in the specfile is much more straightforward.
Mattia
1 year, 3 months
