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.<br>
<br>Bill<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Cyril Brulebois</b> <span dir="ltr"><<a href="mailto:kibi@debian.org">kibi@debian.org</a>></span><br>
Date: Mon, Jul 14, 2008 at 11:37 AM<br>Subject: Packaging (python-)ssl for Debian<br>To: <a href="mailto:python.ssl.maintainer@gmail.com">python.ssl.maintainer@gmail.com</a><br><br><br>Hi,<br>
<br>
I've noticed the following Request For Packaging [1], and it turned out<br>
that it was exactly what I was looking for (a real ssl module, not just<br>
read/write on a socket). So I started packaging it for Debian, and here<br>
are a few comments, and some points that I'd like you to address, so<br>
that I can upload it into the archive.<br>
<br>
1. <a href="http://bugs.debian.org/453101" target="_blank">http://bugs.debian.org/453101</a><br>
<br>
<br>
The main concern currently is the license, since "Python (MIT-like)" is<br>
quite vague. One has no clue which Python version is concerned, since as<br>
far as I can tell, there are at least 2.4.2 and 2.5.2 [2,3] out with<br>
(slightly but still) different licenses. So, pointing to the precise<br>
version would really help people. At least the URL to the license would<br>
be needed, but it would be even better to include it into the source<br>
package, so that there's no possible doubt, and so that one isn't<br>
dependent from being online to actually read it.<br>
<br>
2. <a href="http://www.python.org/download/releases/2.4.2/license/" target="_blank">http://www.python.org/download/releases/2.4.2/license/</a><br>
3. <a href="http://www.python.org/download/releases/2.5.2/license/" target="_blank">http://www.python.org/download/releases/2.5.2/license/</a><br>
<br>
I'd suggest including it in a LICENSE file, and then point to it using<br>
something like "LICENSE: Python x.y.z (MIT-like), see LICENSE file".<br>
<br>
It's then up to you to choose whether to state clearly in each file<br>
"This file is licensed under the terms of the Python x.y.z license, see<br>
LICENSE file." (which I encourage you to do), or to state at the very<br>
beginning of this LICENSE file that "the whole (python-)ssl package is<br>
licensed under the following terms (Python x.y.z license):" and then<br>
quote your favourite license.<br>
<br>
<br>
Also, you're listing the contributors in various places, PKG-INFO and<br>
setup.py. That's nice, but it might be a better idea to point to a<br>
single AUTHORS file, where you would keep a single list of the<br>
contributors. It's not a problem per se, but you may want to consider<br>
this.<br>
<br>
Related to authorship is copyright assignment, and that one is a blocker<br>
for the inclusion into Debian. Every file should include copyright<br>
information so that one can know who is holding the copyrights on this<br>
or that file. Having a very quick look, the following files would need<br>
it: *.py, *.h, *.c. PKG-INFO could eventually list all copyright lines,<br>
but I'm not sure it's a widely-used practice in the Python world, just<br>
tell me ;-); the Makefile might deserve © info as well; MANIFEST and<br>
*.pem files don't need it.<br>
<br>
Just for the records, one specifies copyrights in the following manner:<br>
Copyright 2008 Some Author<br>
Copyright 2004, 2007 Another One<br>
Copyright 2004-2008 Yet Another One<br>
<br>
"Copr." or "©" can be used instead of "Copyright". "(C)" can be added<br>
(it's harmless) but has no legal meaning, so can't be used alone. No<br>
need to list everyone having ever contributed a single patch, it's<br>
sufficient to list people having done the real work and worthy<br>
modifications to it. Adding people to copyright holders is usally a<br>
matter of project policy.<br>
<br>
If you don't feel like listing the copyright holders in PKG-INFO, you<br>
could decide for using something like:<br>
,---[ AUTHORS ]---<br>
|<br>
| Main developers:<br>
| Copyright 2004 John Doe<br>
| Copyright 2004-2008 Alice Wonderland<br>
|<br>
| Contributors:<br>
| Peter Pan<br>
| Foo Bar<br>
|<br>
`---<br>
<br>
This way, you just have to do the following to keep your software<br>
uptodate WRT legalese things:<br>
- Add/update a Copyright line at the top of .c/.h/… file when a<br>
significant modification is included.<br>
- Add/update the Copyright line in the AUTHORS file accordingly.<br>
- Or add/update the Contributors list if that doesn't warrant a<br>
Copyright line.<br>
<br>
So that there's no need to update every file (like PKG-INFO and<br>
setup.py), you only have to make them point to AUTHORS for authorship<br>
information.<br>
<br>
<br>
Once that is done, I should be able to upload it to Debian, where the<br>
first upload will be double-check by ftpmasters, whose role is to make<br>
sure that no obvious packaging error is made, but mainly to make sure<br>
that the archive is kept OK from a legal point of view. That's why I'm<br>
starting with this quite boring mail, and I'm sorry for that. :)<br>
<br>
<br>
Mraw,<br>
KiBi.<br>
<br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
iEYEARECAAYFAkh7quoACgkQeGfVPHR5Nd1LQwCaAＤ艊�볁ᜆ뻈働�<br>
2Y0AnitpaRf3zybMhNxstnDrKaJc8K3/<br>
=eriZ<br>
-----END PGP SIGNATURE-----<br>
<br></div><br>