On Mon, Aug 1, 2022 at 6:45 PM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote: > > Since a lot of code is going to have a LOT of different licences which for some seem to grow every minor upstream release it would be better for the RPM License tag to have something like: > > License: It's complicated. (Please see /usr/share/<package-name>/licences for a complete list.) > > otherwise I am worried we will run into some sort of string length limit in RPM or other tooling. I'm not sure whether there's a limit to the length of RPM Tags. But I started doing something similar for Rust packages for another reason: To ensure informational value of the License string for end users. Especially for Rust binaries that have a large dependency tree, just collecting the License strings of all components and concatenating them would result in a string that is comically long (even with deduplication of non-unique values), and would be completely useless for actually providing information to users of a package. I know that the new licensing guidelines discourage "simplification" when combining Licenses from multiple components, but I also think that providing a string that's hundreds of characters long defeats the purpose, and does not actually provide anything of value to users. Instead, I put the "simplified" license string into the License tag (which is seen by users), and put the full license breakdown of all components into a separate file (which can be several hundred lines long / several KB big, which is why I don't just paste its contents into the .spec file as a comment). I'm pretty sure that satisfies both requirements (providing information to the user *and* keeping accurate license information) - something like: License: ASL 2.0 and BSD and MIT # LICENSE.dependencies contains a full license breakdown Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
