[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-legal-list] Re: Artistic license

Tom spot Callaway wrote:
> So, ignoring GPL or Artistic...
> We're down to these 44 packages. We need to send each of the packager
> maintainer(s) an email, asking them to contact upstream and convince
> them to relicense to Artistic 2.0
> (http://www.perlfoundation.org/artistic_license_2_0) or dual license
> with some other license on our "good list" (GPL or Artistic is fine).

Perhaps before that we should ensure that the packages are marked
correctly.  I took a quick look at the the first item on the list,
cpan2rpm, and it appears to be completely wrong (which is a shame if
I'm right, as the license has been incorrect for many years).

The tarball's LICENSE file is GPLv2.  The cpan2rpm script itself says
it is GPLv2 or later.  Grepping the cpan2rpm source for Artistic

$ grep -ri artistic .
./Changes:changed default for license to "Artistic" as most modules are released under Perl's own license.
./cpan2rpm:        license           => "Artistic",
./cpan2rpm:The license header specified in the spec file.  This field is also sometimes referred to as I<Copyright>, but I<License> is a more suitable name and has become more common.  Defaults to C<Artistic>, Perl's own license.

Those all reference what the program will use as the default License:
tag in the spec files it generates.  It has nothing to do with the
cpan2rpm license at all, so far as I can tell (corrections are
welcome, I've been told I occasionally make mistakes, both large and
small :).

So, I'd suggest that the first step is to ask the maintainers of these
packages to double check that they are marked correctly.  Then if they
truly are Artistic 1.0, they should ask upstream about the possibility
of relicensing.

If you think it'd be worth the time, I'd be happy to split the list of
44 packages with some other folks and check the licenses thoroughly.
It might save us time in auditing them later and we could then give
the maintainer's more concrete advice ("change your license tag tag to
..." or "please ask upstream to relicense").

Obviously, it's easier if the maintain can just do this work for us.
But I figured I'd mention that I was willing to do some of it if it
would help expedite the process and avoid hassling maintainers too

Without looking back in my archives, did the notice on the licensing
changes ask maintainers to do any sort of verification that the
license tag was set correctly?  If not, it wouldn't hurt to make that
request.  Some packages have been around a long time and may have
changed maintainers several times.  I'm sure not all maintainers think
to check the license tags when they take over a package.  But if we're
asking them to make a change anyway, we ought to ask them to make some
small effort to verify that the current license tag is accurate before
they just replace it with the new short name.

Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Damn you vile woman, you've impeded my work since the day I escaped
your vile womb!
    -- Stewie Griffin

Attachment: pgpxtLhUxyRnZ.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]