V Wed, Jul 27, 2022 at 12:01:34AM -0400, Richard Fontana napsal(a):
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar ppisar@redhat.com wrote:
I'm slightly surprised that you decided to hide the unapproved license part "Artistic-1.0-Perl" from "GPL-1.0-or-later OR Artistic-1.0-Perl" expression.
I understand it makes the License tag more comprehensible.
On the other hand, I worry it will complicate merging user-supplied patches back to upstreams. Because users contributing to Fedora will see only GPL, hence they will understand their patches are GPL. But then upstream will assume or insisit on the full "GPL-1.0-or-later OR Artistic-1.0-Perl" combination. The will make a friction because Fedora maintainers will need to renegotiate a license of the patch with the patch author to get the "OR Artistic-1.0-Perl" part back. (Though I admin this case quite theoritical. I haven't seen many patches from Fedora users. Fedora-origin patches are usually authored by Fedora maintainers.)
Does hiding the unapproved licenses from a License tag also influnce which license files are packaged with %license macro? Should we because of that start removing Artistic-1.0-Perl texts from Perl packages?
OK, after some deliberation, we've decided to give an exception to packages containing Perl code that use the Perl 5 GPL|Artistic dual license. These packages can continue to represent the dual license in the License: field.
It is possible that a similar exception might be granted in the future in some comparable case involving some other dual license and some other community, but I have a feeling there isn't any.
Note that we have an open issue to reassess the various pre-Artistic 2.0 versions of the Artistic License.
I can see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/37. I wasn't aware about it. Allowing Artistic-1.0-Perl would palliate the above mentioned worry.
As for this, though, and again after much deliberation, we've decided to keep the status of Artistic-1.0-Perl as not-allowed.
Thanks for the guidance.
-- Petr