This discussion made me look into this: https://github.com/ruby/rdoc/pull/1019/filesThis means that RDoc now embeds Racc. Luckily, the embedding is mentioned in Racc README.rdoc [1]:
~~~ Note that you do NOT need to follow ruby license for your own parser (racc outputs). You can distribute those files under any licenses you want. ~~~ and source code [2]: ~~~ # As a special exception, when this code is copied by Racc # into a Racc output file, you may use that output file # without restriction. ~~~ So this seem to be explicit "don't bother" exception.However, shouldn't we require such license for every tool which produces some content? IMHO, e.g. GCC is probably not any different, after all. It takes source code and embeds itself (in fragments) into the code producing some binary.
What also bothers me, that while I have learnt now that the embedding is fine from licensing POV, I don't have any meaningful way to share this knowledge more broadly.
Vít [1] https://github.com/ruby/racc#label-License[2] https://github.com/ruby/racc/blob/5eb07b28bfb3e193a1cac07798fe7be7e1e246c4/lib/racc/parser.rb#L8-L10
Dne 28. 10. 23 v 18:05 Richard Fontana napsal(a):
On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote:Below, I'm collecting a list of observations of what I believe is the current approach in this area, as taken by package maintainers carrying out the SPDX conversion. To me, it strongly suggest that the SPDX identifiers we derive today do not accurately reflect binary RPM package licensing, even when lots of package maintainers put in the extra effort to determine binary package licenses.I recently noticed something that could be added to this list. There's a package that generates a '-docs' subpackage using Doxygen. Apparently Doxygen injects various pieces of minified JavaScript (mostly from the jQuery ecosystem, mostly MIT-licensed) in a way that is not obvious from analyzing the source code of the package that uses Doxygen. I assume this must be compliant with Fedora packaging guidelines -- although I could not verify this from reading Fedora guidelines on bundling and JavaScript. Anyway, I would guess no Fedora package maintainer of a package that has a Doxygen docs subpackage is taking this issue into account when thinking about License: tags. Should they? I am having trouble seeing why the licensing of the Doxygen pieces should be deliberately ignored. But I also am not sure if a Fedora package maintainer should realistically be expected to know that this situation occurs. I was moving toward the view that if the package build process results in the inclusion of some licensed material from another package, this can be ignored if (a) the inclusion occurs in huge numbers of Fedora packages and (b) most normal Fedora installs will have the other package. I was thinking that would take care of Florian's gcc and glibc statically-linked startup code examples, but surely neither (a) nor (b) apply to the Doxygen case which seems sort of analogous. Richard _______________________________________________ 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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital 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
