[Python-Dev] Packaging the PyPI version of the SSL module for Debian

[Bill Janssen]

As some of you know, I've provided a PyPI version of the 2.6/3.x "ssl"
module, for use with older versions of Python.  I've received this request
to tweak it for Debian, and I thought I'd ask those of you who may have
already done it for advice on the various issues Cyril raises here.  I'm not
Debian-knowledgable, myself.

Bill

---------- Forwarded message ----------
From: Cyril Brulebois <kibi at debian.org>
Date: Mon, Jul 14, 2008 at 11:37 AM
Subject: Packaging (python-)ssl for Debian
To: python.ssl.maintainer at gmail.com


Hi,

I've noticed the following Request For Packaging [1], and it turned out
that it was exactly what I was looking for (a real ssl module, not just
read/write on a socket). So I started packaging it for Debian, and here
are a few comments, and some points that I'd like you to address, so
that I can upload it into the archive.

 1. http://bugs.debian.org/453101


The main concern currently is the license, since "Python (MIT-like)" is
quite vague. One has no clue which Python version is concerned, since as
far as I can tell, there are at least 2.4.2 and 2.5.2 [2,3] out with
(slightly but still) different licenses. So, pointing to the precise
version would really help people. At least the URL to the license would
be needed, but it would be even better to include it into the source
package, so that there's no possible doubt, and so that one isn't
dependent from being online to actually read it.

 2. http://www.python.org/download/releases/2.4.2/license/
 3. http://www.python.org/download/releases/2.5.2/license/

I'd suggest including it in a LICENSE file, and then point to it using
something like "LICENSE: Python x.y.z (MIT-like), see LICENSE file".

It's then up to you to choose whether to state clearly in each file
"This file is licensed under the terms of the Python x.y.z license, see
LICENSE file." (which I encourage you to do), or to state at the very
beginning of this LICENSE file that "the whole (python-)ssl package is
licensed under the following terms (Python x.y.z license):" and then
quote your favourite license.


Also, you're listing the contributors in various places, PKG-INFO and
setup.py. That's nice, but it might be a better idea to point to a
single AUTHORS file, where you would keep a single list of the
contributors. It's not a problem per se, but you may want to consider
this.

Related to authorship is copyright assignment, and that one is a blocker
for the inclusion into Debian. Every file should include copyright
information so that one can know who is holding the copyrights on this
or that file. Having a very quick look, the following files would need
it: *.py, *.h, *.c. PKG-INFO could eventually list all copyright lines,
but I'm not sure it's a widely-used practice in the Python world, just
tell me ;-); the Makefile might deserve (c) info as well; MANIFEST and
*.pem files don't need it.

Just for the records, one specifies copyrights in the following manner:
 Copyright 2008 Some Author
 Copyright 2004, 2007 Another One
 Copyright 2004-2008 Yet Another One

"Copr." or "(c)" can be used instead of "Copyright". "(C)" can be added
(it's harmless) but has no legal meaning, so can't be used alone. No
need to list everyone having ever contributed a single patch, it's
sufficient to list people having done the real work and worthy
modifications to it. Adding people to copyright holders is usally a
matter of project policy.

If you don't feel like listing the copyright holders in PKG-INFO, you
could decide for using something like:
,---[ AUTHORS ]---
|
| Main developers:
|   Copyright 2004 John Doe
|   Copyright 2004-2008 Alice Wonderland
|
| Contributors:
|   Peter Pan
|   Foo Bar
|
`---

This way, you just have to do the following to keep your software
uptodate WRT legalese things:
 - Add/update a Copyright line at the top of .c/.h/… file when a
  significant modification is included.
 - Add/update the Copyright line in the AUTHORS file accordingly.
 - Or add/update the Contributors list if that doesn't warrant a
  Copyright line.

So that there's no need to update every file (like PKG-INFO and
setup.py), you only have to make them point to AUTHORS for authorship
information.


Once that is done, I should be able to upload it to Debian, where the
first upload will be double-check by ftpmasters, whose role is to make
sure that no obvious packaging error is made, but mainly to make sure
that the archive is kept OK from a legal point of view. That's why I'm
starting with this quite boring mail, and I'm sorry for that. :)


Mraw,
KiBi.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh7quoACgkQeGfVPHR5Nd1LQwCaAＤ艊�볁ᜆ뻈働�
2Y0AnitpaRf3zybMhNxstnDrKaJc8K3/
=eriZ
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20081103/9533fe1f/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: signature.asc
URL: <http://mail.python.org/pipermail/python-dev/attachments/20081103/9533fe1f/attachment.asc>