Perl modules dual licensing (was Re: Bioconductor package flowPeaks license Artistic 1.0?)

[Giovanni Biscuolo]

Hi zimoun

zimoun  writes:

[...]

> Where is the License of Perl 5 and below explicitly  defined? There is
> no pointer...

Ricardo pointed you to https://dev.perl.org/licenses/, that is a web
version of this 
https://perl5.git.perl.org/perl5.git/blob/HEAD:/README

Perl is dual licensed at least since 1994-10-17 (see the README history
[1]

> What I understand is: when the License of Perl 5

There is no "License of Perl 5", it is Perl 5 that is dual licensed

The same dual license scheme is usually (usually?!?) adopted by Perl
modules, at least those on CPAN
http://www.cpan.org/misc/cpan-faq.html#How_is_Perl_licensed

> and below is used, then the copyright holder chooses either the
> Artistic 1.0, either the GPL.  Then the License of Perl 5 and below is
> free but non-copyleft.

Since there is no "License of Perl 5" that license cannot be qualified
:-)

> Well, it appears to me a hack. I guess that there is a lot of Perl
> packages under Artistic 1.0 which seems an issue.

I don't know how many packages/modules are distributed only using
Artistic License 1.0, but please consider that as I said above that
*many* are dual licensed.

The fact that Perl modules are (must?) commonly dual licensed is
somewhat a mystery to me, but I do not care :-D

> So let create this License of Perl 5 and below saying: choose between
> Artistic 1.0 or GPL. And because you have this choice, everything is
> fine.
>
> I probably misread

No, you do not misread: dual licensing is used in many situation and is
non a "hack", it's the decision of the copyright holder to allow
different legal uses of the software

In this particular case, **fortunately** the dual licensing was adopted
"since the beginning" to fix the problems with Artistic License

[...]

Last things about names: since Oct 2019 [2] Perl 5 is Perl (Perl 4 is
gone long ago) and Perl 6 is Raku, so finally there is no more need to
say "Perl 5" :-)

Ciao! Gio'


[1] https://perl5.git.perl.org/perl5.git/history/HEAD:/README

[2] https://lwn.net/Articles/802329/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: [PATCH] Perl modules for HTML and XML

[Ricardo Wurmus]

Cyril Roelandt  writes:

> On 12/23/2015 11:53 AM, Ricardo Wurmus wrote:
>> (I’ll try to set up git send-email soon.)
>> 
> Seems ok, except for this:
>
> gnu/packages/perl.scm:5946:5: perl-unicode-linebreak-2015.12: sentences
> in description should be followed by two spaces; possible infraction at 104

Oh, thanks for catching this.  I fixed this and pushed the patches.

~~ Ricardo

Re: [PATCH] Perl modules for HTML and XML

[Cyril Roelandt]

On 12/23/2015 11:53 AM, Ricardo Wurmus wrote:
> (I’ll try to set up git send-email soon.)
> 
Seems ok, except for this:

gnu/packages/perl.scm:5946:5: perl-unicode-linebreak-2015.12: sentences
in description should be followed by two spaces; possible infraction at 104


Cyril.

[PATCH] Perl modules for HTML and XML

[Ricardo Wurmus]

(I’ll try to set up git send-email soon.)

>From d4f5da65aaa55df2880b3a1aac7705973e5ae272 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 22 Dec 2015 14:08:41 +0100
Subject: [PATCH 01/13] gnu: Add MIME::Charset.

* gnu/packages/perl.scm (perl-mime-charset): New variable.
---
 gnu/packages/perl.scm | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 95aa596..4abd997 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -2839,6 +2839,25 @@ follows LRU semantics, that is, the last n results, where n is specified as
 the argument to the CACHESIZE parameter, will be cached.")
 (license (package-license perl
 
+(define-public perl-mime-charset
+  (package
+(name "perl-mime-charset")
+(version "1.012")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://cpan/authors/id/N/NE/NEZUMI/"
+  "MIME-Charset-" version ".tar.gz"))
+  (sha256
+   (base32
+"1kfc5p4g1x9c0ffhg125wvhravcviny3alwrgnhnrm2a33ad3rff"
+(build-system perl-build-system)
+(home-page "http://search.cpan.org/dist/MIME-Charset;)
+(synopsis "Charset information for MIME messages")
+(description
+ "@code{MIME::Charset} provides information about character sets used for
+MIME messages on Internet.")
+(license (package-license perl
+
 (define-public perl-mime-types
   (package
 (name "perl-mime-types")
-- 
2.5.0

>From 2a799ea20c426e612b30f28311e809b18965ddd7 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 22 Dec 2015 14:09:20 +0100
Subject: [PATCH 02/13] gnu: Add Unicode::LineBreak.

* gnu/packages/perl.scm (perl-unicode-linebreak): New variable.
---
 gnu/packages/perl.scm | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 4abd997..7992156 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -5838,6 +5838,28 @@ else.")
 common serialisation formats such as JSON or CBOR.")
 (license (package-license perl
 
+(define-public perl-unicode-linebreak
+  (package
+(name "perl-unicode-linebreak")
+(version "2015.12")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://cpan/authors/id/N/NE/NEZUMI/"
+  "Unicode-LineBreak-" version ".tar.gz"))
+  (sha256
+   (base32
+"1d0nnc97irfpab4d3b2lvq22hac118k7zbfrj0lnxkbfwx7122cm"
+(build-system perl-build-system)
+(propagated-inputs
+ `(("perl-mime-charset" ,perl-mime-charset)))
+(home-page "http://search.cpan.org/dist/Unicode-LineBreak;)
+(synopsis "Unicode line breaking algorithm")
+(description
+ "@code{Unicode::LineBreak} implements the line breaking algorithm
+described in Unicode Standard Annex #14. The @code{East_Asian_Width} property
+defined by Annex #11 is used to determine breaking positions.")
+(license (package-license perl
+
 (define-public perl-universal-can
   (package
 (name "perl-universal-can")
-- 
2.5.0

>From 71295eed79eb83face000764844855922964111b Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 22 Dec 2015 14:12:49 +0100
Subject: [PATCH 03/13] gnu: Add String::Print.

* gnu/packages/perl.scm (perl-string-print): New variable.
---
 gnu/packages/perl.scm | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 7992156..cb369b3 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -4365,6 +4365,28 @@ CamelCase and back again.")
 known prefixes.")
 (license (package-license perl
 
+(define-public perl-string-print
+  (package
+(name "perl-string-print")
+(version "0.15")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://cpan/authors/id/M/MA/MARKOV/"
+  "String-Print-" version ".tar.gz"))
+  (sha256
+   (base32
+"1n9lc5dr66sg89hym47764fyfms7vrxrhwvdps2x8x8gxly7rsdl"
+(build-system perl-build-system)
+(propagated-inputs
+ `(("perl-unicode-linebreak" ,perl-unicode-linebreak)))
+(home-page "http://search.cpan.org/dist/String-Print;)
+(synopsis "String printing alternatives to printf")
+(description
+ "This module inserts values into (translated) strings.  It provides
+@code{printf} and @code{sprintf} alternatives via both an object-oriented and
+a functional interface.")
+(license (package-license perl
+
 (define-public perl-sub-exporter
   (package
 (name "perl-sub-exporter")
-- 
2.5.0

>From 3f491f2fa25d68e76f1d6838fbd974e8e47078ac Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 22 Dec 2015 14:30:27 +0100
Subject: 

Re: bug#17468: Perl modules

[Ludovic Courtès]

Fixed in 3a09e1d, which will be in 0.8.

Ludo’.

Re: Perl modules

[Andreas Enge]

On Sat, Dec 07, 2013 at 09:24:42PM +0100, Andreas Enge wrote:
 All very reasonable. Let us go for this (and I should add a section to the
 packaging guidelines later on).

Months later, here is a proposed patch in British English. Do we have a rule
on which spelling to use? British is what I learnt at school.
(I feel like starting a bikeshed discussion ;-).)

Andreas

From 97a3ac573edcb3046ee9655497a97bdf750090ee Mon Sep 17 00:00:00 2001
From: Andreas Enge andr...@enge.fr
Date: Sun, 11 May 2014 10:43:51 +0200
Subject: [PATCH] doc: Add a section on perl modules in the packaging
 guidelines.

* doc/guix.texi (Perl modules): New section explaining the naming of perl
modules.
---
 doc/guix.texi | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 2aacf5d..de50ae5 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2751,6 +2751,7 @@ needed is to review and apply the patch.
 * Package Naming::   What's in a name?
 * Version Numbers::  When the name is not enough.
 * Python Modules::   Taming the snake.
+* Perl Modules:: Little pearls.
 @end menu
 
 @node Software Freedom
@@ -2796,8 +2797,8 @@ Both are usually the same and correspond to the lowercase 
conversion of the
 project name chosen upstream.  For instance, the GNUnet project is packaged
 as @code{gnunet}.  We do not add @code{lib} prefixes for library packages,
 unless these are already part of the official project name.  But see
-@ref{Python Modules} for special rules concerning modules for
-the Python language.
+@ref{Python Modules} and @ref{Perl Modules} for special rules concerning
+modules for the Python and Perl languages.
 
 
 @node Version Numbers
@@ -2859,6 +2860,19 @@ for instance, the module python-dateutil is packaged 
under the names
 @code{python-dateutil} and @code{python2-dateutil}.
 
 
+@node Perl Modules
+@subsection Perl Modules
+
+Perl programs standing for themselves are named as any other package,
+using the lowercase upstream name.
+For perl packages containing a single class, we use the lowercase class name,
+replace all occurrences of @code{::} by dashes and prepend the prefix
+@code{perl-}.
+So the class @code{XML::Parser} becomes @code{perl-xml-parser}.
+Modules containing several classes keep their lowercase upstream name and
+are also prepended by @code{perl-}. Such modules tend to have the word
+@code{perl} somewhere in their name, which gets dropped in favour of the
+prefix. For instance, @code{libwww-perl} becomes @code{perl-libwww}.
 
 
 
-- 
1.8.4

Re: Perl modules

[John Darrington]

On Sun, May 11, 2014 at 10:56:38AM +0200, Andreas Enge wrote:
 On Sat, Dec 07, 2013 at 09:24:42PM +0100, Andreas Enge wrote:
  All very reasonable. Let us go for this (and I should add a section to 
the
  packaging guidelines later on).
 
 Months later, here is a proposed patch in British English. Do we have a 
rule
 on which spelling to use? British is what I learnt at school.
 
Ahh, but which variant of British English? Oxford or Cambridge?

 (I feel like starting a bikeshed discussion ;-).)

whichever, bike shed is two words.

J'
 


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Perl modules

[Ludovic Courtès]

Andreas Enge andr...@enge.fr skribis:

 On Sat, Dec 07, 2013 at 09:24:42PM +0100, Andreas Enge wrote:
 All very reasonable. Let us go for this (and I should add a section to the
 packaging guidelines later on).

 Months later, here is a proposed patch in British English. Do we have a rule
 on which spelling to use? British is what I learnt at school.
 (I feel like starting a bikeshed discussion ;-).)

I use American English, as the settings at the end of guix.texi enforce
for those using the Right Editor.  ;-)

I’d prefer to keep it that way, if that’s OK.  WDYT?

  @node Software Freedom
 @@ -2796,8 +2797,8 @@ Both are usually the same and correspond to the 
 lowercase conversion of the
  project name chosen upstream.  For instance, the GNUnet project is packaged
  as @code{gnunet}.  We do not add @code{lib} prefixes for library packages,
  unless these are already part of the official project name.  But see
 -@ref{Python Modules} for special rules concerning modules for
 -the Python language.
 +@ref{Python Modules} and @ref{Perl Modules} for special rules concerning
 +modules for the Python and Perl languages.

Should be @pxref{Python Modules} and @ref{Perl Modules} (info (texinfo) @ref).

 +For perl packages containing a single class, we use the lowercase class name,

“Perl”, capitalized.

Also, two spaces after end-of-sentence periods.

Thanks, that’s a useful addition.

Ludo’.

Re: Perl modules

[Andreas Enge]

Thanks for the comments, all implemented and pushed.

On Sun, May 11, 2014 at 11:54:02AM +0200, Ludovic Courtès wrote:
 Also, two spaces after end-of-sentence periods.

Just as a side note (side-note? sidenote?), in texinfo an end of sentence
period immediately followed by a line break is interpreted as such (with a
double space in the info browser), while in the string in the description
field of our package definitions it is not. So there one should not end
a line with a period.

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge andr...@enge.fr skribis:

 Thanks for the comments, all implemented and pushed.

Thanks!

 On Sun, May 11, 2014 at 11:54:02AM +0200, Ludovic Courtès wrote:
 Also, two spaces after end-of-sentence periods.

 Just as a side note (side-note? sidenote?), in texinfo an end of sentence
 period immediately followed by a line break is interpreted as such (with a
 double space in the info browser), while in the string in the description
 field of our package definitions it is not. So there one should not end
 a line with a period.

But there’s no tool that really “interprets” of what’s in the
‘description’ field[*].  What do you mean?

Ludo’.

[*] Actually, ‘fill-paragraph’ from (guix ui), which is used for the
output of ‘guix package --search’ does some very basic
interpretation.

Re: Perl modules

[Andreas Enge]

On Sun, May 11, 2014 at 01:31:12PM +0200, Ludovic Courtès wrote:
 But there’s no tool that really “interprets” of what’s in the
 ‘description’ field[*].  What do you mean?
 [*] Actually, ‘fill-paragraph’ from (guix ui), which is used for the
 output of ‘guix package --search’ does some very basic
 interpretation.

Well, the output of guix package --search has different line breaks than
those present in the string of the description field. So something modifies
it, maybe the scheme interpreter itself in what it does with multi-line
strings, maybe the function you mention. In any case, x.\nY may be output
as x. Y; so if we wish to have double spaces in the output, we need to
write x.  Y on the same line.

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge andr...@enge.fr skribis:

 On Sun, May 11, 2014 at 01:31:12PM +0200, Ludovic Courtès wrote:
 But there’s no tool that really “interprets” of what’s in the
 ‘description’ field[*].  What do you mean?
 [*] Actually, ‘fill-paragraph’ from (guix ui), which is used for the
 output of ‘guix package --search’ does some very basic
 interpretation.

 Well, the output of guix package --search has different line breaks than
 those present in the string of the description field. So something modifies
 it,

Yes, that’s ‘fill-paragraph’.

 maybe the scheme interpreter itself in what it does with multi-line
 strings, maybe the function you mention. In any case, x.\nY may be
 output as x. Y; so if we wish to have double spaces in the output,
 we need to write x.  Y on the same line.

That’s really a bug in ‘fill-paragraph’.

I’m filing it now and will look at it later, unless someone beats me.
;-)

Ludo’.

Re: Perl modules

[Andreas Enge]

On Fri, Dec 06, 2013 at 11:56:17PM +0100, Ludovic Courtès wrote:
 I would add the ‘perl-’ prefix, unless the package stands alone (for
 instance, Hydra would be called ‘hydra’, not ‘perl-hydra’.)

Yes, that would be as for python.

 For the rest of the name, I would take the Perl module name.  So
 ‘XML::Parser’ leads to ‘perl-xml-parser’, etc.
 
 In cases where there’s not a single module tree root, I would stick to
 the upstream name, removing any redundant ‘perl’ in the name.  So
 ‘libxml-perl’ (which provides modules under XML::, Data::Grove, etc.)
 would lead to ‘perl-libxml’.
 
 How does that sound?

All very reasonable. Let us go for this (and I should add a section to the
packaging guidelines later on).

Andreas

Perl modules

[Andreas Enge]

Hello,

it looks like I have stumbled upon an enormous dependency tree:

For kdelibs, I would like soprano;
for soprano, I would like redland;
for redland, I need rasqal;
for some tests of rasqal to work, I need perl-xml-dom;
for perl-xml-dom, I need libwww-perl;
for libwww-perl, I need a lot of packages:
Warning: prerequisite Encode::Locale 0 not found.
Warning: prerequisite File::Listing 6 not found.
Warning: prerequisite HTML::Entities 0 not found.
Warning: prerequisite HTML::HeadParser 0 not found.
Warning: prerequisite HTTP::Cookies 6 not found.
Warning: prerequisite HTTP::Daemon 6 not found.
Warning: prerequisite HTTP::Date 6 not found.
Warning: prerequisite HTTP::Negotiate 6 not found.
Warning: prerequisite HTTP::Request 6 not found.
Warning: prerequisite HTTP::Request::Common 6 not found.
Warning: prerequisite HTTP::Response 6 not found.
Warning: prerequisite HTTP::Status 6 not found.
Warning: prerequisite LWP::MediaTypes 6 not found.
Warning: prerequisite Net::HTTP 6.04 not found.
Warning: prerequisite URI 1.10 not found.
Warning: prerequisite URI::Escape 0 not found.
Warning: prerequisite WWW::RobotRules 6 not found.

This leads me to the question: How should the packages containing perl
modules be named, and in which files should they be defined?

So far, there are the following packages in xml.scm:
perl-xml-parser containing XML-Parser
perl-xml-parser-perlsax containing libxml-perl
perl-xml-simple containing XML-Simple

The second one is definitely a misnomer; I was looking for
XML::Parser::PerlSAX, and a search led me to the documentation page
  http://search.cpan.org/~kmacleod/libxml-perl-0.08/lib/XML/Parser/PerlSAX.pm
which is just one of the modules of libxml-perl
  http://search.cpan.org/~kmacleod/libxml-perl-0.08/

If we follow our standard naming scheme, then the packages should be called
xml-parser, libxml-perl and xml-simple. Notice that two of them do not
contain the word perl. Should we add perl in front then, similarly to
what we do with python modules? How about libxml-perl? Do we keep it as such,
or should we then call it perl-libxml-perl for consistency?

Concerning the files, maybe all perl modules should go into perl.scm?

Your opinions are welcome.

Andreas

Re: Perl modules

[Ludovic Courtès]

Andreas Enge andr...@enge.fr skribis:

 it looks like I have stumbled upon an enormous dependency tree:

 For kdelibs, I would like soprano;
 for soprano, I would like redland;
 for redland, I need rasqal;
 for some tests of rasqal to work, I need perl-xml-dom;
 for perl-xml-dom, I need libwww-perl;
 for libwww-perl, I need a lot of packages:

Ouch.  :-)

 This leads me to the question: How should the packages containing perl
 modules be named, and in which files should they be defined?

 So far, there are the following packages in xml.scm:
 perl-xml-parser containing XML-Parser
 perl-xml-parser-perlsax containing libxml-perl
 perl-xml-simple containing XML-Simple

 The second one is definitely a misnomer; I was looking for
 XML::Parser::PerlSAX, and a search led me to the documentation page
   http://search.cpan.org/~kmacleod/libxml-perl-0.08/lib/XML/Parser/PerlSAX.pm
 which is just one of the modules of libxml-perl
   http://search.cpan.org/~kmacleod/libxml-perl-0.08/

 If we follow our standard naming scheme, then the packages should be called
 xml-parser, libxml-perl and xml-simple. Notice that two of them do not
 contain the word perl. Should we add perl in front then, similarly to
 what we do with python modules? How about libxml-perl? Do we keep it as such,
 or should we then call it perl-libxml-perl for consistency?

I would add the ‘perl-’ prefix, unless the package stands alone (for
instance, Hydra would be called ‘hydra’, not ‘perl-hydra’.)

For the rest of the name, I would take the Perl module name.  So
‘XML::Parser’ leads to ‘perl-xml-parser’, etc.

In cases where there’s not a single module tree root, I would stick to
the upstream name, removing any redundant ‘perl’ in the name.  So
‘libxml-perl’ (which provides modules under XML::, Data::Grove, etc.)
would lead to ‘perl-libxml’.

How does that sound?

 Concerning the files, maybe all perl modules should go into perl.scm?

I don’t think so.  For instance, I think it’s OK to have perl-xml-* in
xml.scm, esp. because they are also used by ‘intltool’ for instance.
I’d use perl.scm for any Perl-specific library that doesn’t have a
better home (yeah, that’s very informal...)

WDYT?

Ludo’.