So I tried to figure out what all this really meant in practice by
transforming some of my Fedora packages. But almost immediate ran into
conflicts with how SPDX defines license identifiers and expressions.
I think the main conflict is that SPDX identifiers and expressions are
meant to apply to individual source files (and not describe the general
intended license of the larger work), where the Fedora spec file
License tags is meant to provide the approximate license of the
(sub)package as a whole (which can consist of multiple larger, possibly
independently licensed, works).
Also I found the tooling around this hard to use/understand. It seems
various tools just haven't caught up or aren't even packaged for Fedora
itself and are only available in some giant container image blob (e.g.
fossology, really a webapp that you then should run "locally", which I
never could get working [or simply didn't understood how to use]).
For the elfutils project Housam Alamour created a new eu-srcfiles
utility for version 0.190 (already packaged for Fedora 37..Rawhide),
which might be helpful for native ELF plus DWARF based packages. At the
moment it does require you have the build requires and debugsources
installed, but a newer version will query debuginfod for that.
With that we might be able to build somewhat simpler command line tools
to help packagers extract all the license snippets found in the source
files included in each binary.
e.g. for the mutt package, you can get a rough estimate of licenses
used in all the binaries using (if that is really what you are
insisting packagers do instead of just using the declared licenses):
$ dnf install mutt
$ dnf builddep mutt
$ dnf debuginfo-install mutt
$ for i in `rpm -ql mutt`; do eu-elfclassify --elf --file $i; \
if [ $? -eq 0 ]; then eu-srcfiles --exec $i; fi; done | sort -u \
| xargs licensecheck --shortname-scheme spdx | cut -f2- -d: \
| sort -u | sed -z -e 's/\n / AND /g'
GPL-2.0-or-later AND GPL-3.0-or-later AND HPND-sell-variant AND LGPL
AND LGPL-2.1-or-later AND *No copyright* GPL-2.0-or-later AND *No
copyright* public-domain AND *No copyright* UNKNOWN AND UNKNOWN AND
Which still requires lots of investigation (there are various
UNKNOWNs), but might be a good starting point. At least for me
something like that would be much more usable than a container image
On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:
On Sun, Sep 17, 2023 at 11:37 AM Mark Wielaard <mark(a)klomp.org>
> To be clear I don't mind using a different set of short-hands in the
> License tags. Although it feels a little odd to try to create separate
> identifiers for lax-permissive MIT/BSD like licenses which sometimes
> just different in one or two words.
FWIW, usually a difference of one or two words wouldn't be enough to
result in creation of a distinct SPDX identifier. The standard applied
by SPDX is, informally, whether the difference is "legally
substantive" (this has its flaws but seems to work OK in practice).
But then for the Hybrid BSD license that parts of bzip and valgrind
uses it actually has different identifiers depending on the version of
the package (it actually has both bzip2-1.0.5 and bzip2-1.0.6 which are
literally exactly the same except for the version string and the
I think anyone should be free to propose a new umbrella identifier
SPDX expression format) that would cover multiple licenses, as we've
done with `LicenseRef-Fedora-Public-Domain` and
`LicenseRef-Fedora-UltraPermissive`. The important thing is that it be
well defined in some way.
OK, so how would we do this for this Hybrid BSD license?
And what is "well defined"?
> > > What is the goal of dropping the effective license and
> > > list all the licences of some code snippets originally incorporated
> > > under lax-permissive licenses? Is that not just make work for the
> > > packager if upsteam just uses one effective license?
> > One rationale is given in Fedora legal
> > "There is no agreed-upon set of criteria or rules under which one can
> > make conclusions about “effective” licenses or reduce composite
> > license expressions to something simpler."
> Isn't that not just like most other things fedora, we follow
> upstream. Upstream states the (effective) license and we just adopt
> that. If we notice that there might be a bug and the effective license
> isn't exactly as the upstream project states, then we fix that
I basically don't recognize "effective license" as a valid concept. I
see people using it, perhaps increasingly, but I never see any
definition of what it means.
It sounds like you are using it to mean "whatever the upstream project
seems to say the license is, despite possible evidence to the
contrary". I'm not sure that's how other people are using "effective
I would call it the intended license. Normally an (upstream) project
declares their intended license by placing a COPYING or LICENSE
document at the top-level (or different ones in subdirs if different
parts have different intended licenses). That intended license is the
effective license, meaning the license you would have to follow when
redistributing the project. Any other licenses used in the project
would only have requirements that are subsumed by the intended license.
I think Jilayne would disagree with this, but in practice, I also
don't see what we could fix upstream, since there is no standard for
how you communicate or document what the effective license is
(regardless of what it means). The only related standard I know of for
documenting licensing of projects is REUSE (https://reuse.software
which I think implicitly also rejects the concept of "effective
Both REUSE and SPDX are intended to be used at the individual source
file level. Trying to use them at the binary or package level as Fedora
wants to do seems to bring up these conflicts yes.
That doesn't mean there aren't "standards" for this. Like I said
upstream often has a top-level LICENSE, COPYING or README file
declaring the intended license. There also often is a NOTICES file
listing any legal notices subsumed by the intended/effective license.
> > Basically, everyone has been making up their own
> > for deciding what an "effective license" is, with no consistencies
> > across upstream packages and Fedora package maintainers.
> Is this really a problem? Could you show an example where an upstream
> or package maintainer stated in the license tag that the effective
> license was say "GPLv3+", but it would have been more "correct"
> that it was "GPL-3.0-or-later AND GPL-3.0-or-later WITH
> Autoconf-exception-generic-3.0 AND GPL-3.0-or-later WITH
> Bison-exception-2.2 AND GPL-2.0-or-later AND GPL-2.0-or-later WITH
> Autoconf-exception-generic AND LGPL-2.1-or-later AND LGPL-2.0-or-later
> AND X11"?
I will not argue this, but I will make two observations. One is
something I've said before, which is that people seem to be
complaining about the current standards for license tags only when
they are lengthy. I think it would be more consistent to argue that we
don't need license tags at all. I have no attachment to RPM-style
license tags, though Red Hat finds them marginally useful for some
What are the purposes for which Red Hat finds the spec license tags
Just dropping the license tags from the spec file is an interesting
idea. Would we then adopt something like a separate copyright file like
The other thing is that the discipline that produces license tags at
this level of detail is what is needed to uncover licensing problems
in packages, from Fedora's perspective as a distribution that aims to
be made up of free software. That is, the detailed license tags are a
side effect of a valuable license review process and I would be
concerned that falling back on an effective license approach would
result in the loss of the benefits we get from that process, which
actually long precede the abandonment of the Callaway system.
I do agree that a license review process is useful. But I don't agree
this process can be condensed into a "tag" (not even with an expression
You've contributed to glibc, so you probably know that for many
(almost 20 years?) glibc gave the impression that its license, its
effective license if you will, was LGPLv2.1 or later (except for parts
that are under the GPL) but it included a substantial amount of code
under a license that, by the mid-2000s, Debian and later Fedora came
to regard as non-free. I am speaking of the famous Sun RPC license,
which prohibits distribution in isolation, a common type of
proprietary license restriction.
In that scenario, if you had a license tag that just says
"LGPL-2.1-or-later" you are concealing the fact that there is also
some code under a license that cannot be assimilated with LGPL (other
than by adopting a clever post hoc interpretation which cannot
possibly be what Sun Microsystems had in mind in the 1980s) and that
is not even free software. It seems to me that at the very least the
license tag, if you're going to have license tags at all, should say
"LGPL-2.1-or-later AND LicenseRef-Assorted-Other-Free-Software AND
LicenseRef-sun-rpc". But if there's a practice of just relying on
whatever the effective license seems to be, you would be inclined not
to notice a license like this in the first place. This is why the
issue was first surfaced by Debian, I think. To your later point about
Debian copyright files, it is obviously true that you don't need to
have a license tag system like Fedora has for this to happen.
Right, that is the job of a licence legal review process. In the above
case I would say it was just a bug in the upstream package that a
distro caught and which was fixed upstream. I think it would have been
silly to (retroactively) add some extra "tagging" for a license notice
that was in error instead of just fixing the license so that it was
actually compatible with the LGPL (which is what happened).
While the Sun RPC problem *may* have been excised from glibc, just
last year we found another license in glibc (and at least one other
package), this time an IBM license , that we consider non-free by
present day standards, in that case because it involves a patent
license grant that discriminates according to specific use cases. I
think we should aspire to finding, *exposing*, and fixing these kinds
of problems. Exposing should mean at a minimum that we don't
perpetuate a community-wide decades-old practice of covering these
problems up, which seems to be one practical effect of indulging in
effective licensing. I realize all this doesn't itself justify the
resulting use of complex composite SPDX expressions.
Right, I assume you are talking about the resolv code which carries a
patent notice from IBM saying they might sue you if you use that code
for anything else than doing DNS resolving over TCP/IP. Which is indeed
a odd notice. Happy you found it and you are making IBM fix it. But
IMHO it is just an unintended, license, bug in the upstream package. It
will be fixed, so no need for some complicated license tag.
> It seems that the "enumeration" expression is not that
easy to create
> objectively. If only because it is actually hard to know which sources
> to scan to get the license/permission snippets (just the upstream tar
> ball, the sources as created by fedpkg prep, those actually included
> in the binaries which depend on the build environment, etc.)
Similar points have been raised by others. I think a good solution is
to reformulate what we mean by "enumeration" so that it is more
practical for Fedora package maintainers. I don't think it is a good
solution to just give up and no longer review package source code for
inclusion of licenses that conflict with Fedora licensing policies.
I hope the new eu-srcfiles tool can help. But I also hope we aren't
really going to try to cram all found legal snippets into matching
license tags in the spec files. If we really want to somehow ship all
these legal notices (and we already do, because we do just distribute
the srpms, but maybe for some reason you would like to include them all
in each binary (sub) package? Then lets adopt something like the Debian
copyright file or NOTICES file and also ask upstream to adopt that.
> And what is the actual purpose and goal of including them in the
For me, it's that there's no good argument for throwing away the
information once you have it. You've reviewed a given package and
let's say you've identified five applicable licenses (let's assume we
know what applicable means). How do you then decide what information
to hide? I think you are saying, "review the package thoroughly, but
don't report what you find in the license tag, just pick the
license(s) the upstream project indicates are effective". As suggested
above, I'm not opposed to something similar to this approach (I think
Jilayne would disagree though) provided that we always expose licenses
that are not classified as 'allowed' for Fedora.
I think I agree with you that we shouldn't "throw away" any such legal
notices we found. But I don't agree SPDX license tag identifiers in
spec files are a good way to keep such notices.
> > Also, I don't think "snippets" are the
typical case. Often the non-GPL
> > license will appear to cover a whole file or perhaps a set of multiple
> > files. I have found it somewhat common for a Fedora package to include
> > multiple "merely aggregated" works which may be under the GPL and
> > other licenses. That's mere aggregation based on the license steward's
> > traditional guidance on interpretation of the GPL. In those scenarios
> > attempts to apply an effective license theory that ignores the non-GPL
> > license seem to embody a misunderstanding of the orthodox
> > interpretation of the GPL.
> That is not my experience from working on some larger code bases. For
> example when we were integrating GNU Classpath/IcedTea/OpenJDK I went
> over all the code to make sure we could merge the code bases. The top
> level LICENSE file explains the (effective) licenses. And every source
> code file has a header explaining the (effective) license for that
> file (GPLv2 or GPLv2-plus-classpath-exception). But it also includes
> lots of notices like:
> * This file is available under and governed by the GNU General Public
> * License version 2 only, as published by the Free Software Foundation.
> * However, the following notice accompanied the original version of this
> * file and, per its terms, should not be removed:
> * Copyright (c) 2004 World Wide Web Consortium,
> * (Massachusetts Institute of Technology, European Research Consortium for
> * Informatics and Mathematics, Keio University). All Rights Reserved. This
> * work is distributed under the W3C(r) Software License  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.
> *  http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
So in that example, I understand you believe that there is an
effective license, but it can't be said that the W3C license is not
also an applicable license, or, if it is, then why should it not be
It is applicable, but subsumed by the GPLv2. It should never be removed
since that is just rude (and also the notice and the effective license
say such notices may not be removed).
You can argue that the W3C license isn't worth including in the
license tag, but that requires some formulation of a policy for what
kinds of licenses can and can't be excluded. ,
If the source, like in this case, explicitly says it is not the
effective license of the file then it doesn't need to be mentioned.
Likewise if there is an explicit intended license for the larger work
that subsumes all such legal notices they don't need to be mentioned,
as long as the (source) package does contain all such notices.
> Something similar is done in glibc. For example several files I
> contributed to were adapted from some BSD release and have a file
> header saying the file is copyright the Free Software Foundation,
> Inc. This file is part of the GNU C Library. And the state they are
> distributed under the GNU Lesser General Public License 2.1 or
> later. But also have the original BSD notice in the file:
> * Copyright (c) 1990, 1993, 1994
> * The Regents of the University of California. All rights reserved.
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in the
> * documentation and/or other materials provided with the distribution.
> * 4. Neither the name of the University nor the names of its contributors
> * may be used to endorse or promote products derived from this software
> * without specific prior written permission.
> * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
> * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
> * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> But this is not the (effective) licenses, and there is no way to use
> the code under that license, since all contributions since 1994 have
> been done under the LGPL.
Again, someone is making an assumption that something is there that is
still subject to that license, because otherwise it could be removed.
No it cannot be removed. And no it doesn't mean it is still subject to
that license. There is a Ship of Theseus argument to be made to just
remove to no longer applicable notice. But a) that would just be rude.
And b) the notice itself and the effective license both explicitly say
you must retain the notice.
In review of Fedora packages over the past year, we have found a
number of cases where it seems clear a license notice no longer
applies to anything in the package, or never applied in the first
place. In at least one of those cases we recommended to the upstream
project that it remove the "phantom" license notice.
That sounds like bad advise IMHO. It also destroys historical
> Likewise for valgrind we have examples of the above. For example
> dhat tool which have a GPLv2+ copyright and license header, but also
> Parts of this file are derived from Firefox, copyright Mozilla Foundation,
> and may be redistributed under the terms of the Mozilla Public License
> Version 2.0, as well as under the license of this project. A copy of the
> Mozilla Public License Version 2.0 is available at at
> Again, although there is a reference to MPLv2 here, the code is only
> available under GPLv2+.
But that notice literally says there is code available under MPL 2.0.
If the notice is incorrect, that is a bug that should be fixed
upstream. But a mere conflict with a project's conception of what its
effective license is would not mean that the license notice is
In the case of relicensing MPLv2 to GPLv2+ you could indeed argue that
no notice at all should remain in the source file to the MPLv2. The
MPLv2 does indeed require you remove all MPL notices when converting a
source file to the GPL. But again I consider it rude to not even
mention the origin of the source code and provide a (historical)