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#sourcelicense> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
