-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Kitterman wrote: > On Friday 13 July 2007 16:20, Magnus Holmgren wrote: > > Any comments or objections to these patches? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=1;bug=431239 > > RFC conformance issues #431239 is a little more complex: > > The patch carries an LGPL copyright notification. Libspf2 is currently > dual licensed under BSD and GPL version 2.
This seems to be a mistake in debian/copyright. libspf2's LICENSES file says: | The code in the libspf2 distribution is Copyright 2005 by Shevek | and Wayne Schlitt, all rights reserved. Copyright retained for the | purpose of protecting free software redistribution. | | This program is free software; you can redistribute it and/or modify | it under the terms of either: | | a) the GNU Lesser General Public License as published by the Free | Software Foundation; either version 2.1, or (at your option) any | later version, or | | OR | | b) The two-clause BSD license. I just reported this as a separate bug (bdo #433047[1]). > I don't recall the exact rules on combining LGPL and GPL code (it hasn't > come up in any packages I've done), but that needs to be considered. > > More important is that is LGPL code is incorporated, the package is no > longer distributable under the BSD license. This is true even considering that libspf2's actual license is LGPL/BSD rather than GPL/BSD. Robert's patch needs to be dual-licensed under LGPL and BSD just like libspf2 in order to allow the patched libspf2 to be distributed under the BSD license in the future. Robert, would you consider resubmitting your patch with the license note amended to that effect? > From a technical perspective: > > Adding the Null Mail From HELO check is useful. The approach used here > is consistent with the approach that many long standing SPF libraries > (Mail::SPF::Query and pyspf for two) take. So this is good. Agreed. (Do not construe this as a retreat from the newer Mail::SPF Perl module's more formal approach, whose author I am. Whereas I prefer the more formal approach, the less formal one used by Mail::SPF::Query, pyspf, and now libspf2, is certainly legitimate.) > The second part of the change, changing the SPF None response string > from > > "%s is neither permitted nor denied by %s", > > to > > "%s doesn't provide an SPF record" > > is a wording improvement, but given that it's been this way for several > years, I don't know if there are programs that are dependent on that > string. If there was any code depending on the explanatory result text, then that would be a design bug in such code. > So, I'd suggest this is an improvement, but not entirely without risk. > I'd tend not to want to make it, but I could understand either way. I say go ahead with the change. I wouldn't... er... would not use a contraction, though. Say "%s does not provide an SPF record" instead. References: 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGmAnmwL7PKlBZWjsRAt/mAKDCQGnf80lNqAnUyxxFpWAxNrrtTwCghnUc PIPXpUOYbXPIKLlSQaef9Tg= =oZf7 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
