On Sat, Nov 25, 2023 at 11:22 AM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote: > > Dne 24. 11. 23 v 20:07 Mark Wielaard napsal(a): > > I 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), > > SPDX license ids are used in SPDX SBOMs that are intended to describe large work > > 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). > > Fedora license tag should NOT provide approximate license. It should provide exact license. > This is *never* going to be possible as things currently work. This is *explicitly* why we document the License tag as informational. It's *all* best-effort. https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_field > 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/ > > 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. > > I disagree. As I mentioned SPDX defines whole SBOM model exactly for large projects and large deployments. > > 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. > Licenses aren't for machines, they are for people. That's why some licenses have actual requirements or specifications of how to apply licenses. Please keep that in mind. > > 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. > Please no. When debbuild adapted RPM spec to build Debian packages, the %copyrightdata section was added[1][2] for this purpose. But it's excessively tedious to use and maintain per-file license data. I vastly prefer our License tag over having to do something like DEP5[3]. [1]: https://github.com/debbuild/debbuild/commit/91699c5a714fe6a80b55763be84e5fb48385d556 [2]: https://github.com/debbuild/debbuild/commit/ddfc6d783b0d37093816a6c74ee680632eb5d7ae [3]: https://dep-team.pages.debian.net/deps/dep5/ -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
