I started packaging Cavil and I stumbled upon this gem
there are more like this.
It has a SPDX header that say it is MIT license. But it is just test whether Cavil can detect the SPDX header.
The code and project itself is GPL-2.0-only.
What is the license of that file? Is it GPL-2.0-only and we ignore the header because the meaning is just to test code
and not declare license. Or we cannot ignore it and the license of that file is MIT?
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
valgrind as a whole is licensed under the GPLv2+, but has a couple of
development headers, all separately packaged in the valgrind-devel
subpackage) with a lax-permissive license. Since they are meant to
embed valgrind specific (code) annotations into other
programs/libraries they carry an explicit exception from the GPL.
There are 7 such files, all exactly the same, except for the embedded
file name, "This file is part of..." description and Copyright notice.
See below for the exact text and variants.
It would be nice to give this binary subpackage its own License tag.
But I have some trouble figuring out which (SPDX) tag to use.
The closest seems to be what SPDX calls "bzip2-1.0.6" (which kind of
makes sense since Julian Seward started both the bzip2 and valgrind
I could use that identifier. But it seems to be an oddly specific
identifier, for an older version of bzip2. And the Fedora bzip2 package
just uses BSD-4-Clause. I could also use BSD-4-Clause since that is
more generic. But the text of what SPDX calls BSD-4-Clause doesn't
really match (so maybe the Fedora bzip2 package got that wrong?)
What would be to best license tag to use here?
They all look as follows:
/* -*- c -*-
Notice that the following BSD-style license applies to this one
file (valgrind.h) only. The rest of Valgrind is licensed under the
terms of the GNU General Public License, version 2, unless
otherwise indicated. See the COPYING file in the source
distribution for details.
This file is part of Valgrind, a dynamic binary instrumentation
Copyright (C) 2000-2017 Julian Seward. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. The origin of this software must not be misrepresented; you must
not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
3. Altered source versions must be plainly marked as such, and must
not be misrepresented as being the original software.
4. The name of the author may not be used to endorse or promote
products derived from this software without specific prior written
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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.
Notice that the above BSD-style license applies to this one file
(valgrind.h) only. The entire rest of Valgrind is licensed under
the terms of the GNU General Public License, version 2. See the
COPYING file in the source distribution for details.
They only differ in "this one file
([valgrind|cachegrind|callgrind|drd|helgrind|memcheck|dhat].h) only" at
the top and the bottom. And the description and Copyright notice.
This file is part of Cachegrind, a high-precision tracing profiler
built with Valgrind.
Copyright (C) 2023-2023 Nicholas Nethercote. All rights reserved.
This file is part of callgrind, a valgrind tool for cache simulation
and call tree tracing.
Copyright (C) 2003-2017 Josef Weidendorfer. All rights reserved.
This file is part of DRD, a Valgrind tool for verification of
Copyright (C) 2006-2020 Bart Van Assche <bvanassche(a)acm.org>.
All rights reserved.
This file is part of Helgrind, a Valgrind tool for detecting errors
in threaded programs.
Copyright (C) 2007-2017 OpenWorks LLP
This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2017 Julian Seward. All rights reserved.
This file is part of DHAT, a Valgrind tool for profiling the
heap usage of programs.
Copyright (C) 2020 Nicholas Nethercote. All rights reserved.
-------- Přeposlaná zpráva --------
Předmět: SPDX Statistics - Origin of Species edition
Datum: Fri, 24 Nov 2023 07:42:38 +0100
Od: Miroslav Suchý <msuchy(a)redhat.com>
Společnost: Red Hat Czech, s.r.o.
Komu: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
I have started looking at Cavil - tool that audit the licensing info after each commit.
The process of adding the licenses on list is still very slow recently.
Now lets dive into numbers:
Two weeks ago we had:
> * 23365 spec files in Fedora
> * 29583license tags in all spec files
> * 12255 tags have not been converted to SPDX yet
> * 5577tags can be trivially converted using `license-fedora2spdx`
> * Progress: 58.95% ░░░░░█████ 100%
> ELN subset:
> 623 out of 3969 packages are not converted yet (progress 84%)
Today we have:
* 23426 spec files in Fedora
* 29916license tags in all spec files
* 12081 tags have not been converted to SPDX yet
* 5482tags can be trivially converted using `license-fedora2spdx`
* Progress: 59.62% ░░░░░█████ 100%
655 out of 3798 packages are not converted yet (progress 82.75%)
Graph of these data with the burndown chart:
The list of packages needed to be converted is here:
List by package maintainers is here
List of packages from ELN subset that needs to be converted:
New version of fedora-license-data has been released. With 5 new licenses (plus some public domain declarations). 16
licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data)
Legal docs and especially
was updated too.
New projection when we will be finished is 2024-10-05 (+16 days from last report). Pure linear approximation.
If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license
tag matches SPDX formula, you can put your package on ignore list
Either pull-request or direct email to me is fine.
Why Origin of Species edition? On today's date at 1859 was published Charles Darwin's book On the Origin of Species -
first scientific work that species evolves over generations through natural selection. It took Darwin 20 years to write
this book and he delayed it because he wanted finish his book about coral reefs first. The book had several edition and
sixth edition was the first one that used the word "evolution".
I'm currently working on packaging cargo-deny, and it includes (a very
old version) of a compressed form of the SPDX license data from
The package needs the SPDX license-list-data in a format that can be
read by "askalono", and it is used to match unknown license files with
licenses known to SPDX. I was able to include a new version of that
data by rebuilding that compressed blob from the SPDX
license-list-data on GitHub.
However, I could not determine under which license terms this data is
made available. The repository for spdx/license-list-data only states
that all contents are automatically generated from
https://github.com/spdx/license-list-XML, which itself specifies no
license for the data, either.
I assume this data is redistributable *somehow*? The documentation
explains how to *use* the data for various purposes, but not which
license (if any) applies to it.
Note that the existing askalono-cli package also bundles this data,
which seems to have been missed during the original package review. I
will apply any necessary changes both to cargo-deny (which is still
being reviewed) and askalono-cli.
On Sun, Nov 12, 2023 at 9:42 AM Michael Catanzaro <mcatanzaro(a)redhat.com> wrote:
> On Sun, Nov 12 2023 at 01:48:25 PM +0100, Robert-André Mauchin
> <zebob.m(a)gmail.com> wrote:
> > So while I appreciate the caution, I think it's OK to just enable the
> > BMFF code by
> > default (perhaps have an option to disable it, if someone is still
> > for some reason worried,
> > but imo that would be an unfounded worry). Otherwise most of the
> > modern image codecs (jp2,
> > jxl, avif and heic) end up being unsupported by default, for no good
> > reason, which seems a
> > suboptimal situation.
> Hi, Fedora already supports all of these except for HEIC (for good
> reasons). Honestly it doesn't seem like there is a real serious concern
Indeed. This was already vetted some time ago and was deemed okay.
We don't ship HEIC because of HEVC, which *does* have concerns.
真実はいつも一つ！/ Always, there's only one truth!
In order to update Exiv2, we need to know if this is okay to enable BMFF support. Patents
have theoretically expired and it is enabled by default in the latest version.
Upstream seems to think it is okay because it is over 20 years old. Also other packages in
Fedora are already using it, av1, jpeg-xl, any mp4 decoding.
By Jon Sneyers, one of the author of JPEG-XL:
I think this caution is erring on the side of paranoia, and possibly based on a
ISOBMFF is pretty old, old enough for it to be impossible to still have applicable
patents (patents expire after 20 years). It is a simple box-based container format that is
used by many formats, including MP4, JPEG 2000, and JPEG XL.
One particular use of ISOBMFF is HEIF, which is more recent, and for which there
actually are known patent claims by Nokia. HEIF does use the generic ISOBMFF box structure
and extends it by defining mechanisms to do cropping, layering, grids, rotation etc, which
are described in the HEIF spec. HEIF can be used with various payloads: when used with HEVC
it is called HEIC, when used with AV1 it is called AVIF.
While most people would consider patents on a container format ridiculous, it is a fact
that, at least in theory, if you use HEIF, you might risk patent litigation. Note that it
would not be the application implementor who could be sued, but the end-user who uses the
implementation and thereby possibly needs a patent license from Nokia.
This is only true specifically for HEIF though, not for ISOBMFF in general. Parsing the
MP4 or JPEG 2000 container (which do not use HEIF) carries absolutely no risk in terms of
patents, since they only use ISOBMFF, not HEIF. The same is true for JPEG XL, which has
explicitly avoided using the HEIF container exactly for this reason.
TL;DR: ISOBMFF is OK, HEIF might be risky.
So just to be clear: reading BMFF is not an issue, it is over 20 years old so even if
it was an issue in the past (it wasn't) it now certainly isn't anymore.
Reading HEIF-specific boxes is something else, but as long as Exiv2 is not doing that,
there obviously is no issue either. Note that other FOSS tools like libheif and libavif
actually do read those boxes, and they do seem to get away with it (but I can understand why
you wouldn't want to do that; those boxes are from 2015 and Nokia does claim patents on them
so it will only really be 'safe' to use that functionality in 2035).
So while I appreciate the caution, I think it's OK to just enable the BMFF code by
default (perhaps have an option to disable it, if someone is still for some reason worried,
but imo that would be an unfounded worry). Otherwise most of the modern image codecs (jp2,
jxl, avif and heic) end up being unsupported by default, for no good reason, which seems a
Could we come to a resolution of that situation quickly?
Have a great sunday.
I wanted to send a pull request to the python-dateutil package to change:
License: BSD-3-Clause and Apache-2.0
License: BSD-3-Clause AND Apache-2.0
However, the comment above the License tag made me curious:
# According to the LICENSE file:
# - BSD License applies to all code, even that also covered by ASL 2.0
# - ASL 2.0 applies to all contributions after 2017-12-01,
The license file:
> ...snip Apache-2.0...
> The above license applies to all contributions after 2017-12-01, as well as
> all contributions that have been re-licensed (see AUTHORS file for the list of
> contributors who have re-licensed their code).
> ...snip BSD-3-Clause...
> The above BSD License Applies to all code, even that also covered by Apache 2.0.
In other words. There is a subset of the code which is covered by Apache-2.0
and *at the same time* all of the code is covered by BSD-3-Clause.
Is that an OR case?
Should the license tag be:
License: (Apache-2.0 AND BSD-3-Clause) OR BSD-3-Clause
(We can either pick BSD-3-Clause for everything OR a combination of both.)
Or should it be:
License: (Apache-2.0 OR BSD-3-Clause) AND BSD-3-Clause
(Some code is BSD-3-Clause and for the rest we can pick either one of them.)
Or is it an AND case (the code is covered by both license "together" (whatever
that means)? In that case, should it be:
License: (Apache-2.0 AND BSD-3-Clause) AND BSD-3-Clause
Or is the current license tag more or less correct:
License: Apache-2.0 AND BSD-3-Clause