And checking the Ruby repository, which has yet another copy of Racc does not contain the original *.ry files, while it contains the processed *.rb files with embedded Racc:
https://github.com/ruby/ruby/blob/14fa5e39d72c84d3e12e10dc5d77a6e6200c10f5/lib/rdoc/rd/block_parser.rb#L8 What a mess.The worst thing is that it appears to me, that often only we care about such subtleties.
Vít Dne 30. 10. 23 v 13:32 Vít Ondruch napsal(a):
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-L10Dne 28. 10. 23 v 18:05 Richard Fontana napsal(a):On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer <fwei...@redhat.com> 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 SPDXidentifiers we derive today do not accurately reflect binary RPM package licensing, even when lots of package maintainers put in the extra effortto 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@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
