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
The 'sgx-sdk' package is currently open for review with a view to
adding to Fedora:
One of the last stumbling blocks is that it includes a copy of the
"dlmalloc" code under the CC0 license, which is now a forbidden
code license for packages being newly added to Fedora.
The authors of sgx-sdk have contacted the original author of
dlmalloc, and he apparently suggested that since CC0 is a public
domain license, they can just add a second license header of their
choosing to the source files and Fedora can then ignore the orignial
This smells fishy to me, as I can't come with rationale for why
adding a second "BSD" license header to the source file and justify
Fedora ignoring the original CC0. The original code would still
explicitly not have a patent grant, and an extra license doesn't
seem to alter that fact.
It was pointed out that this approach has already been taken by
OpenJDK, where they took CC0 code and added a GPL-v2-only header:
OpenJDK though would be grandfathered in, since it existed in
Fedora before CC0 was forbidden, so I'm not sure that can be
relied on as a precedent.
I am not a lawyer, so I want an expert opinion on this suggestion
that adding a 2nd license header allows Fedora to ignore the
original CC0 license. If it is true, then it would appear to
make the whole exercise of banning CC0 effectively pointless.
I had also suggested downgrading to an older version of dlmalloc
which had the CC Public Domain license, rather than CC0, but the
sgx-sdk maintainers rejected that as they're concerned it has
security relevant flaws.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
I think Richard said that he would start a thread like this, but it
hasn't happened, so I feel like should get this off my chest now.
starts with this:
| No “effective license” analysis
| The License: field is meant to provide a simple enumeration of the
| licenses found in the source code that are reflected in the binary
| package. No further analysis should be done regarding what the
| "effective" license is, such as analysis based on theories of GPL
| interpretation or license compatibility or suppositions that
| “top-level” license files somehow negate different licenses appearing
| on individual source files.
This is contradictory. I think there are two aspects here:
* Determine possible licenses that end up in the binary package.
* Perform algebraic simplifications on the license list.
Both analyses are forms of effective licensing analysis. Of course, you
cannot derive an SPDX identifier without doing any analysis. However, I
strongly believe that the first approach (determining the binary package
license) is itself a form of effective licensing analysis, and similar
reasons for package maintainers not doing this applies. The derived
SPDX identifier will reflect both the package source code and what went
into the build system.
Below, I'm collecting a list of observations of what I believe is the
current approach in this area, as taken by package maintainers carrying
out the SPDX conversion. To me, it strongly suggest that the SPDX
identifiers we derive today do not accurately reflect binary RPM package
licensing, even when lots of package maintainers put in the extra effort
to determine binary package licenses.
* Most package maintainers probably assume that License: tags on all
built RPMs (source RPMs and binary RPMs) should reflect binary package
contents, at least when all subpackages are considered in aggregate.
Often, Source RPMs contain the same License: line as binary RPMs.
* No algebraic simplifications on License: lines are performed.
* All forms of dynamic linking are ignored for License: tags. This
covers ELF (e.g., C, C++), but also Python, Java, and other languages
with late binding.
* C/C++ header file contents is ignored for License: tags, regardless of
header file complexity (e.g., substantial code in templates or inline
functions is not treated specially).
* Statically linked GCC and glibc startup code is ignored and does not
show up in License: lines. The license of glibc startup code isn't
even in SPDX yet, so it's not just Fedora who is ignoring this.
* Statically linked libgcc support code is ignored (e.g., outline
atomics on aarch64, FMV support code on x86-64). This code comes with
the compiler, but is compiled from C sources that ship with the
compiler. These items overlap with the startup code, but licensing
could theoretically be different.
* Some shared objects come with statically linked support code. I doubt
that many package maintainers are aware of that, so they effectively
ignore the licensing impact of that. It's structurally similar to
inline functions and templates in header files.
* Output from source code generations such as autoconf, bison and flex
is often (but not always) ignored, in some cases even if the generated
code ships in the source RPM and is compiled as-is, without
regeneration. (autoconf can generate more than just build scripts.)
* Licenses of crate build-dependencies end up in License: tags of RPM
packages. This is a form of static linking analysis for which we have
tooling, and it is mandated by the guidelines. It only covers the
Rust part, other gaps for filling out License: are still there. (I
don't know if the generated License: tags are accurate for individual
subpackages; it seems unlikely.) Go might have something similar.
* Sometimes we ignore upstream SPDX identifiers if we believe them to be
incorrect, but that approach is not consistent, as far as I know.
* Apparently, there seems to be some confusion whether AND or OR is the
right separator for SPDX tags in License: lines.
* Some package maintainers, when translating to SPDX, merely translate
the existing License: line as best as they can, without looking at the
actual sources or produced binaries.
I looked around a bit and there are no documented product requirements
internally, so I don't think we can justify investing in tooling or
training to improve data quality. (I'll keep digging, though.)
In the light of this, I would like to suggest updating the guidelines in
the following way:
The License: line should be based on the sources only. Using a tool
such as Fossology to discover relevant licenses and their SPDX tags is
sufficient. No analysis how licenses from package source code or the
build environment propagate into binary RPMs should be performed.
Individual SPDX identifiers that a tool has listed should be separated
by AND. Package maintainers are encouraged to re-run license analysis
tooling on the source code as part of major package rebases, and
update the License: tag accordingly.
To me, that seems to be much more manageable.
Webkitgtk has interresting file:
The file has this content:
* SPDX-FileCopyrightText: 2021 GNOME Foundation
* SPDX-License-Identifier: Apache-2.0 OR GPL-3.0-or-later
And that is all. No other content is there. So it is literaly an empty file with license declaration.
Should this license be honored and put in License tag of spec file? Or is it copyright of not-copyrightable file and
should be ignored?
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
I was updating the spec file of perl-Math-Random-ISAAC and wanted to
migrate the License field to the SPDX format.
The license field says "MIT or GPL+ or Artistic" but the upstream
package README says:
" Legally speaking, this package and its contents are:
Copyright (c) 2011 by Jonathan Yu <jawnsy(a)cpan.org>.
But this is really just a legal technicality that allows the author to
offer this package under the public domain and also a variety of licensing
options. For all intents and purposes, this is public domain software,
which means you can do whatever you want with it.
The software is provided "AS IS", without warranty of any kind, [...]"
Can anyone tell me how I express this in SPDX terms?
I have submitted rpm-local-generator-support package for a review .
It can't be simpler:
It essentially just creates empty file and places it into directory
structure. I have used `License: MIT` tag, because what else.
But the package review correctly pointed out that I should also ship the
license file, which would substantially complicate everything.And now I
wonder, is there even anything what would be licensable? Is the empty
file created somewhere in the directory structure worth of anything? Can
the License tag be omitted and would the file be covered by the default
Fedora license for .spec files?