SPDX license ids are used in SPDX SBOMs that are intended to describe large workI 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),
Fedora license tag should NOT provide approximate license. It should provide exact license.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]).
True. We are trying to improve it. Every day. I have just packaged another dependency for a tool that will be helpfull.
You can use OSUOSL instance of fossology https://fossology.osuosl.org/repo/ with login:password: fossy:fossy
Or you can use scancode-toolkit from Copr repo https://copr.fedorainfracloud.org/coprs/eclipseo/scancode-toolkit/
The command to do the analysis is then:
$ scancode --license --html /tmp/spdx.html --json /tmp/spdx.json --license-references .
The output is then:
http://miroslav.suchy.cz/fedora/spdx-reports/mutt.html
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.
Great. I did not know this.
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 Zlib 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 packaged webapp.
There is many ways to do it. We are all exploring various ways. If this is better for you then use it. I am afraid this will not work for noarch packages.
On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:On Sun, Sep 17, 2023 at 11:37 AM Mark Wielaard <mark@xxxxxxxxx> wrote: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 copyright year).
The SPDX uses markup which allows variation in license. E.g. when you look at
https://spdx.org/licenses/BSD-3-Clause.html the red parts allow variations. What and how is better visible in source:
https://github.com/spdx/license-list-XML/blob/main/src/BSD-3-Clause.xml
Tags <copyrightText> allows any variations. <alt> allows only regexp variations.
OK, so how would we do this for this Hybrid BSD license?And what is "well defined"?
Open issue with your proposal at
https://gitlab.com/fedora/legal/fedora-license-data
"well defined" means that there will be common consensus that the
definition is clear. :)
What is the goal of dropping the effective license and make packagers 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 documentation: "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 upstream?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 license".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.
No.
This was maybe enough in past when industry used OSS projects rarely. Now it is used masively. And we want that industry complies with our OSS licenses. If we want this then we should provide good overview what licenses are used.
E.g., your mutt package. The upstream claims it is
GPL-2.0-or-later
https://gitlab.com/muttmua/mutt/-/blob/master/COPYRIGHT?ref_type=heads
but there is
https://gitlab.com/muttmua/mutt/-/blob/master/wcwidth.c?ref_type=heads#L8
which is HPND-Markus-Kuhn. And now imagine that there is
user/company for which HPND-Markus-Kuhn license is
problematic and they cannot use it. If you use only
License: GPL-2.0-or-later
they will never know. But when you use
License: GPL-2.0-or-later AND HPND-Markus-Kuhn
then it is pretty easy for them to do the audit and avoid
this package and use alternative.
This example may look artificial, but I know a lot of
companies that want to avoid GPL-3.0-or-later. And Fedora itself
avoids many licenses that other find ok. E.g. JSON or
BSD-3-Clause-Clear
https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/
I disagree. As I mentioned SPDX defines whole SBOM model exactly for large projects and large deployments.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.
This is not standard. This is habit. Very far from any possible
automation and machine parsing.
Just dropping the license tags from the spec file is an interesting idea. Would we then adopt something like a separate copyright file like Debian does?
Likely. It needs to be proposed as Change and discussed and
approved. I expect a LOT of discussion about it.
I will be very glad if somebody will drive this.
-- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
-- _______________________________________________ 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
