tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: LICENSE in lang/perl5/Makefile



Greg Troxel wrote:
"Johnny C. Lam" <jlam%pkgsrc.org@localhost> writes:

Klaus Heinz wrote:
I just noticed that lang/perl5/Makefile contains

  #LICENSE=gnu-gpl-v2

Does this mean we chose the GPL of the two available alternatives
(GPL/Artistic)?
This seems like an oversight.  We want to redistribute under the terms
of the Artistic license.

I don't see how our LICENSE tags affects terms; it is intended to
communicate to potential users, not to have any legal effect.  A
recipient of binary packages would seem free to choose terms from the
original package, following either choice from perl, regardless of our
LICENSE tag.

But I agree that this is messy.

The point I was trying to make was that as a pkgsrc user, the most liberal license under which I may use and redistribute perl is the Artistic license, so that is the one that should be named by the LICENSE variable. Given that we can't really list multiple licenses, setting LICENSE to the most liberal license seems like the best alternative.

I guess it makes sense to choose the same licence for all the Perl
packages that say "under the same licence as Perl" or use "license:
perl" in META.yml.
Yes, this makes good sense.

It may be that we should add licenses/perl-license (perhaps just
referring to permission to copy under either gpl2 or artistic) and add
perl-license to DEFAULT_ACCEPTABLE_LICENESES in license.mk.

Yes, I think this is probably best. I think "artistic-license" is the better name, especially as I've seen other software projects using this license.

The basic problem is that our licensing framework does not have a way to
express dual licensing such as perl's, and also can't express that one
must simultaneously comply with multiple licenses in order to
redistribute.

Yes, this seems tricky to tackle in a nice way.

The real question is how hard to try to fix the underlying expressivity
problem, keeping in mind that performing logic with legal documents
basically doesnt' really work, and how hard to try to accomodate common
multiple-license situations.  I don't have a strong opinion yet.

In the somewhat common situation of dual-licensing, I think we can accommodate this by allowing LICENSE to be a list instead of a single variable. Still, I agree that extending pkgsrc in this way without having a plan for the "must simultaneously comply with multiple licenses" case would seem premature.

        Cheers,

        -- Johnny C. Lam



Home | Main Index | Thread Index | Old Index