V Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer napsal(a):
* 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.
That's a shortcomming of RPM. It reuses License tag of the main subpackage
for
source RPM. Current RPM has a new SourceLicesne tag
<
https://rpm-software-management.github.io/rpm/manual/spec.html#sourcelice...
to for those willing to declare a distinct license of the sources.
* 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.
I guess you realy mean a code which is dynamically linked into a process at
run-time. E.g. a library linked to an application. Not listing a license of
that library in an RPM package of the application makes perfect sense for me:
The packaged application does not contain a code of the library when the
application is distributed in a form of the binary RPM package. Even after
installing the package, the application still does not contain the library
code. It's when the application is executed and a dynamic linker links in the
library code. At that point the application's license changes.
* 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.)
There is no mean of retrieving the licenses of these third-party pieces of
code at build time of my package. I do not want to hardcode their license and
then worry about keeping them in sync.
Are you willing to define %glibc_startup_code_license macro delivered within
glibc-devel so that I can use it in License of my packages?
In ideal world I'd rather see compilers, linkers, and other processors to
process the license metadata automatically. The SPDX identifiers of input and
output files could be stored in file extended attributes. rpmbuild would then
simply collect these attributes and paste them into License tag.
It reminds a vision of reproducible builds. A similarly noble, yet
unachievable goal.
* Sometimes we ignore upstream SPDX identifiers if we believe them to
be
incorrect, but that approach is not consistent, as far as I know.
Not only SPDX identifiers. I saw similar issues with license headers or even
whole license texts. Many times upstreams declare "this file comes from..."
and then forget to properly declare it's license or carry a copy of the
license as mandated by an origin license of the file.
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.
Yes, that's a very realistic approach of what we can expect from the
packagers.
I only worry whether the resulting License tag will be any helpful for our
users. E.g. most of the subpackages of perl.spec are "GPL-1.0-or-later OR
Artistic-1.0-Perl". With your approach their license tag would gain
a ridiculous license identifiers that are not really contained.
-- Petr