V Tue, Jul 30, 2024 at 05:46:56PM -0400, Richard Fontana napsal(a):
> On Tue, Jul 30, 2024 at 1:24 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
> >
> >> perl-RPC-XML hobbes1069 jplesnik ppisar
> >
> > This one I have no idea what to do with:
> > License: (Artistic 2.0 or Artistic or LGPLv2) and (Artistic 2.0 or LGPLv2)
>
> Just looked at this - it seemed to me that the author had intended to
> relicense from "Artistic" (not clear whether that referred to
> Artistic-1.0 or Artistic-1.0-Perl in SPDX parlance) to (again in SPDX
> parlance) Artistic-2.0 OR LGPL-2.1-only. I.e. I didn't see anything
> that seemed to obviously be licensed under Artistic-1.0* and the
> author seemed to (in later statements) use "Artistic License"
> specifically to mean Artistic-2.0. However, I only took a quick look.
> :)
>
There are usefull comments in the spec file above the License tag. One of
the comments states that (Artistic 2.0 or Artistic or LGPLv2) is used by
etc/make_method file. That file reads:
# See "LICENSE AND COPYRIGHT" in the documentation for licensing and
# redistribution terms.
[...]
=head1 LICENSE AND COPYRIGHT
This module and the code within are released under the terms of the Artistic
License 2.0
(http://www.opensource.org/licenses/artistic-license-2.0.php). This code may
be redistributed under either the Artistic License or the GNU Lesser General
Public License (LGPL) version 2.1
(http://www.opensource.org/licenses/lgpl-2.1.php).
See how the author is not congruent when naming Artistic-like licenses.
The relicensing attempt, Richard mentioned, is documented in README.license:
Consider this confirmation that you may distribute it under the Artistic
License 2.0, as specified at
http://www.opensource.org/licenses/artistic-license-2.0.php
I am in the process of revising the licensing on all of my modules to be
dual-licensed under the above and also LGPL 2.1 as specified at
http://www.opensource.org/licenses/lgpl-2.1.php
However, because of other patches that have to be applied, integrated and
tested, it may be some time before a new RPC-XML release is made. Please take
this message as explicit permission to package and release under the licensing
terms you require. Thank you.
[...]
From: "Nick B" <nsboyle@xxxxxxxxx>
[...]
I can package it under 2.0, but I need your confirmation via e-mail
that this is okay. Let me know your thoughts on this.
It's obvious that we are permitted to use Artistic-2.0. It's obvious that the
author intends to dual-license (Artistic-2.0 OR LGPL-2.1-only), but is not
yet clear whether he has already finished the relicensing. But going back to
etc/make_method, we are granted ("Artistic License" OR LGPL-2.1-only). Hence
I spelled the Callaway License tag as (Artistic 2.0 or Artistic or LGPLv2).
Simply naming all options, no effective licensing performed.
The problem with conversion to SPDX is that "Artistic" maps to multiple
Artistic-1.0-* license and we don't know which one it is. Also Fedora is not
willing to throw in free-standing for-Fedora-inapplicable Artistic-1.0-*
licenses into License tags.
So I agree with Richard, that the best option is remove the Artistic-1.0-*
options from the SPDX License tag. I.e. convert Callaway (Artistic 2.0 or
Artistic or LGPLv2) fragment into SPDX (Artistic-2.0 OR LGPL-2.1-only)
fragment.
I will convert the package for you.
-- Petr
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
