davorg writes "It seems that Debian have decided to remove "perlreftut" from their distribution. Full discussion here." Legalism 1, pragmatism 0.
I'm a free software fanatic (well, sometimes), and I appreciate Debian sticking to their guns
Re:"Severity: serious"
blech on 2003-08-13T13:42:10
Quoting from Don Armstrong's post (Message-ID: ), the problem is as follows:
"DFSG 10 says that the Artistic license can be assumed to meet the DFSG."
It does, but we're not dealing with the Artistic license here... this is an Artistic License with an additional rider with strange interactions.
The "rider" (right at the top of the discussion) is:
"Distribution Conditions"
Copyright 1998 The Perl Journal.
When included as part of the Standard Version of Perl, or as part of its complete documentation whether printed or otherwise, this work may be distributed only under the terms of Perl's Artistic License. Any distribution of this file or derivatives thereof outside of that package require that special arrangements be made with copyright holder.Re:"Severity: serious"
jdavidb on 2003-08-13T14:03:10
I've personally about had it up to here with contradictory distribution guidelines. I'm fed up with people who want to say, "This software is GPL unless you put it on a CD." I support every author's right to set distribution terms for their own software, but from one programmer to another, I want to say, "If you don't get the point, stay out until you do."
More and more licenses keep popping up, and more and more special exceptions. All this does is make things confusing. I think the best advice I ever saw was in Karl Fogel's CVS and Open Source development book: decide if you want "copyleft" or not, and then use the ("modified") BSD license or GPL accordingly. Don't thrust another license with new twists upon the world so that we have to reevaluate completely new terms every time we get a new package.
Interesting, the GNU project attempts to prevent this problem by copyrighting the GPL and denying the right to use a modified version. The GNU GPL is itself non-free.
:) [Although I guess you could say it's analogous to a cover text from the GNU FDL.] From my point of view, if you muck up and make contradictory terms in your license, I'm going to take it how I like it and leave the burden on you to give me legal notice if you think I'm doing something to violate your terms. So, I received a Perl distribution under the terms of the Artistic License, and that grants me the right to extract any portion of the distribution and reuse it. As near as I can tell, the right is granted by his statement that the file comes under the Artistic license when included with the Perl distribution. If that right is not granted, then his statement that the file comes under the Artistic license is false. I realize that probably isn't sufficient for Debian.
If nothing else, maybe Debian making examples out of license muddling like this will slowly encourage people to just stick with default licenses.
Distributing as non-free violates terms
jdavidb on 2003-08-13T14:05:14
Oh, and it seems to me that splitting out the file into a non-free package and distributing it breaks the author's terms. At that point, it's not part of the Perl distribution!
Re:Distributing as non-free violates terms
sky on 2003-08-13T14:38:09
Put then Debian is already breaking the author of perls term in the AL, and distributes a non standard perl.Re:Distributing as non-free violates terms
jdavidb on 2003-08-13T14:49:04
Yeah, but Debian is distributing under GPL. Or something. Say, this dual-licensing thing sure is confusing!
:) Re:"Severity: serious"
rob_au on 2003-08-13T13:42:41
From my reading of the thread from the Debian bug list, the issue centers around the distribution conditions outlined in the perlreftut document.These conditions limit the distribution of the document outside of the "standard version" of Perl or as part of its complete documentation without special arrangement from the copyright holder (TPJ). This contravenes the first point of the Debian Free Software Guidelines (DFSG) which mandate free redistribution - From the Debian Free Software Guidelines:
The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.It would appear that it is for this reason primarily that issue has been taken with the perlreftut documentation.
(Though I have to admit I'm confused about the non-free status too)
Re:Already corrected?
Juerd on 2003-08-13T15:26:22
I don't know if anything changed in perlreftut. Google Groups doesn't know about any change.
Anyway, the *current* perl in Debian does not include perlreftut.:(
Frankly, it is just silly hair splitting.
Re:Irrelevant
rafael on 2003-08-13T13:43:36
Don't you always do things that involves ithread support ?;-) Re:Irrelevant
sky on 2003-08-13T13:50:52
Not at all! I have multiple perls installed:)
/usr/local/perl/58/ /usr/local/perl/58t/ /usr/local/perl/58td/ /usr/local/perl/58d/ /usr/local/perl/58_64/ /usr/local/perl/bl/ /usr/local/perl/bld/ /usr/local/perl/blt/ /usr/local/perl/mtd/ And so on
:)
Re:Working Perl
chip on 2003-08-13T14:10:15
Package management systems like dpkg and rpm simply don't cooperate with CPAN. They need to know what files are installed and what packages installed them, and CPAN installations are far too undisciplined to report what's been installed and where (and, even more important in some ways, what's been removed). And then there are the dependency tracking issues.In short, if you use rpm or dpkg, you shouldn't be using CPAN in the first place. This has nothing to do with the skill or dedication of the packagers. It's a fundamental incompatibility.
Re:Working Perl
PerfDave on 2003-08-13T14:15:48
Certainly in Debian, a few CPAN modules are packaged as libfoo-perl. There has been talk IIRC of a Debian-specific version of CPAN.pm or something similar which will inform apt (probably by wrapping the equivs package) when new perl modules are installed or upgraded by CPAN.
It would in theory be possible to "automatically" convert every module on CPAN to a Debian module. Perhaps we need to set up apt.perl.org as some kind of automagic gateway
;) Re:Working Perl
Juerd on 2003-08-13T15:29:09
It would in theory be possible to "automatically" convert every module on CPAN to a Debian module.
In practice too. Well, not *every* module, but every module that is packaged in the standard way can be very easily compiled into a.deb:
apt-get install dh-make-perl
dh-make-perl --build --cpan Foo::Bar
or
dh-make-perl --build --cpanplus Foo::Bar
You can supply --install if you want the new.deb to be installed immediately. Re:Working Perl
nik on 2003-08-13T20:46:46
It would in theory be possible to "automatically" convert every module on CPAN to a Debian module. Perhaps we need to set up apt.perl.org as some kind of automagic gateway;) This is already possible on the *BSD systems, with a clever hack called BSDPAN. This is a modification to the Perl build on those systems that sticks some hooks in to the ExtUtils::* modules, so that 'perl Makefile.PL; make; make test; make install' also registers the module's files with the local package management system.
BSDPAN.ppt is the slides for a lightening talk I gave about this to London.pm.
N
Re: Packaging CPAN
alessio on 2003-08-14T10:24:07
I have just started to use and I am quite happy of cpan2rpm, which of course could be enhanced in a number of ways.Re:Working Perl
raptor555 on 2003-08-27T08:15:07
Gentoo has done it already... i.e.
#g-cpan.pl MODULE
makes a.ebuild and installs the module Re:Working Perl
ajs on 2003-08-13T18:06:08
In short, if you use rpm or dpkg, you shouldn't be using CPAN in the first place
I assume you mean that you should be wrapping CPAN modules into RPMs or DEBs for local use rather than using the CPAN.pm system to install. I would agree with that. If you're suggesting that you should not be using CPAN as a whole, then I would strongly disagree. That's what makes Perl as useful as it is!Re:Working Perl
chip on 2003-08-13T20:10:41
Indeed, I meant not to use CPAN.pm the module. CPAN the archive is, as always, indispensable.
I don't see that this is a serious issue. Not at the moment anyway. Debian have noticed something which might violate their terms of distribution, and as a precautionary measure they've removed it from their packages. If that removal was in itself against the terms of somebody's license, then they're in a no-win position so it doesn't really matter which evil they commit.
Instead of pointing fingers and bashing Debian for doing things in a particular way, we need a nice mature discussion between the Perl and Debian communities, and the owner of the rights to perlreftut, and I'm sure the matter will be quickly resolved to the satisfaction of all involved.
