Bug#431239: Patches from Robert Millan

2007-07-16 Thread Magnus Holmgren 
On Saturday 14 July 2007 18:10, Robert Millan wrote:
 As for the patch size, I believe it is copyright significant.  

I'm not arguing against that. The level of originality needed to enjoy 
copyright protection is low.

 Besides, 
 size is not always representative of the work invested in it (writing new
 code is quick, but finding and hunting down bugs isn't).

I appreciate your debugging work. Nonetheless, I think most contributors of 
patches usually let their code be included under the pertinent project 
license, and are satisfied with an acknowledgement in the changelog, or, 
after accumulating a substantial amount of contributed work, in the regular 
AUTHORS file or similar. I would greatly appreciate it if you could do the 
same, because when code is submitted under different licenses it can, at 
least eventually, become rather messy to keep track of what parts of the 
package can be used under what license.

-- 
Magnus Holmgren[EMAIL PROTECTED]


pgpjOLygcbIcP.pgp
Description: PGP signature

Bug#431239: Patches from Robert Millan

2007-07-16 Thread Robert Millan 
On Mon, Jul 16, 2007 at 04:05:46PM +0200, Magnus Holmgren wrote:
 
 I appreciate your debugging work. Nonetheless, I think most contributors of 
 patches usually let their code be included under the pertinent project 
 license, and are satisfied with an acknowledgement in the changelog, or, 
 after accumulating a substantial amount of contributed work, in the regular 
 AUTHORS file or similar. I would greatly appreciate it if you could do the 
 same, because when code is submitted under different licenses it can, at 
 least eventually, become rather messy to keep track of what parts of the 
 package can be used under what license.

Ok.  I said I would do it if the upstream maintainer requests it.  You're
upstream maintainer in a way now, so that would be fair enough I think.

Patch attached.  You don't need to acknowledge my name, though.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
diff -ur libspf2-1.2.5.dfsg.old/src/libspf2/spf_interpret.c libspf2-1.2.5.dfsg/src/libspf2/spf_interpret.c
--- libspf2-1.2.5.dfsg.old/src/libspf2/spf_interpret.c	2005-02-22 04:41:27.0 +0100
+++ libspf2-1.2.5.dfsg/src/libspf2/spf_interpret.c	2007-07-01 01:03:17.0 +0200
@@ -135,7 +145,9 @@
 
 	/* Is this cur_dom? */
 	sender_dom = spf_request-env_from_dp;
-	if (sender_dom == NULL)
+
+	/* For MAILER-DAEMON messages, fallback to helo domain */
+	if ((sender_dom == NULL) || (sender_dom[0] == '\0'))
 		sender_dom = spf_request-helo_dom;
 
 	if ( spf_response-reason == SPF_REASON_LOCAL_POLICY ) {
@@ -214,11 +226,15 @@
 		break;
 
 	case SPF_RESULT_NEUTRAL:
-	case SPF_RESULT_NONE:
 		snprintf( p, p_end - p, %s is neither permitted nor denied by %s,
   ip, spf_source );
 		break;
 
+	case SPF_RESULT_NONE:
+		snprintf( p, p_end - p, %s doesn't provide an SPF record,
+  spf_source );
+		break;
+
 	case SPF_RESULT_TEMPERROR:
 		snprintf( p, p_end - p, encountered temporary error during SPF processing of %s,
   spf_source );
@@ -686,8 +702,12 @@
 
 #define SPF_GET_LOOKUP_DATA() \
 	do {\
-		if ( data == data_end )			\
+		if ( data == data_end ) {\
 			lookup = spf_request-cur_dom;\
+			/* For MAILER-DAEMON messages, fallback to helo domain */			\
+			if ((lookup == NULL) || (lookup[0] == '\0'))	\
+lookup = spf_request-helo_dom;		\
+		}			\
 		else {			\
 			err = SPF_record_expand_data( spf_server,	\
 			spf_request, spf_response,	\
@@ -1022,7 +1042,10 @@
 if (spf_record_subr)
 	SPF_record_free(spf_record_subr);
 SPF_FREE_LOOKUP_DATA();
-return DONE_TEMPERR( err );
+if (err == SPF_E_DNS_ERROR)
+	return DONE_TEMPERR( err );
+else
+	return DONE_PERMERR( err );
 			}
 
 			/*
diff -ur libspf2-1.2.5.dfsg.old/src/libspf2/spf_result.c libspf2-1.2.5.dfsg/src/libspf2/spf_result.c
--- libspf2-1.2.5.dfsg.old/src/libspf2/spf_result.c	2004-08-10 15:04:02.0 +0200
+++ libspf2-1.2.5.dfsg/src/libspf2/spf_result.c	2007-07-01 01:03:29.0 +0200
@@ -187,11 +197,15 @@
 	break;
 	
 case SPF_RESULT_NEUTRAL:
-case SPF_RESULT_NONE:
 	snprintf( p, p_end - p, %s is neither permitted nor denied by %s,
 		  ip, spf_source );
 	break;
 
+case SPF_RESULT_NONE:
+	snprintf( p, p_end - p, %s doesn't provide an SPF record,
+		  spf_source );
+	break;
+
 case SPF_RESULT_ERROR:
 	snprintf( p, p_end - p, encountered temporary error during SPF processing of %s,
 		  spf_source );
diff -ur libspf2-1.2.5.dfsg.old/src/libspf2/spf_server.c libspf2-1.2.5.dfsg/src/libspf2/spf_server.c
--- libspf2-1.2.5.dfsg.old/src/libspf2/spf_server.c	2005-02-19 04:52:58.0 +0100
+++ libspf2-1.2.5.dfsg/src/libspf2/spf_server.c	2007-07-01 01:04:34.0 +0200
@@ -262,6 +272,9 @@
 	SPF_ASSERT_NOTNULL(spf_recordp);
 
 	domain = spf_request-cur_dom;
+	/* For MAILER-DAEMON messages, fallback to helo domain */
+	if ((domain == NULL) || (domain[0] == '\0'))
+		domain = spf_request-helo_dom;
 	SPF_ASSERT_NOTNULL(domain);
 
 	*spf_recordp = NULL;
@@ -279,8 +292,7 @@
 			SPF_dns_rr_free(rr_txt);
 			spf_response-result = SPF_RESULT_NONE;
 			spf_response-reason = SPF_REASON_FAILURE;
-			return SPF_response_add_error(spf_response, 
-SPF_E_NOT_SPF,
+			return SPF_response_add_error(spf_response, SPF_E_NOT_SPF,
 	Host '%s' not found., domain);
 			break;

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Robert Millan 

Hi!

On Fri, Jul 13, 2007 at 11:25:26PM +, Julian Mehnle wrote:
  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?

To be honest, I have to say that I don't like the possibility of my code
becoming non-free.  That said, I always find it a reasonable compromise to
allow this for the sake of merging the code upstream when the upstream
maintainers require it.

However, the upstream maintainer didn't reply to my emails, and the last
release is more than 2 years old.  In this situation it's really up to Debian.
My code is DFSG-free and it can't bring incompatibility problems with
other packages using it.  It is really up to Magnus wether to include them.

If there's ever someone actively maintaining libspf2 again, and that person
wants to stick with an unprotected license, I'll gladly license it in these
terms.

  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.

For the record, this puzzled me when debugging, since I was delluded into
thinking I was getting an SPF_RESULT_NEUTRAL when it was actually
SPF_RESULT_NONE.  I think it's important to distinguish.

  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.

Fine with that.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Robert Millan 
On Fri, Jul 13, 2007 at 11:25:26PM +, Julian Mehnle wrote:
 
  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.)

What is the other approach?

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Magnus Holmgren 
On Saturday 14 July 2007 12:01, Robert Millan wrote:
 To be honest, I have to say that I don't like the possibility of my code
 becoming non-free.  That said, I always find it a reasonable compromise to
 allow this for the sake of merging the code upstream when the upstream
 maintainers require it.

Although I too love FSF-free software, I personally wouldn't mess with the 
licensing for a not so major patch like this is. On the other hand, it'd be 
distributed as a separate dpatch so it'd be easy for anyone to redistribute 
or rebuild the package without it.

-- 
Magnus Holmgren[EMAIL PROTECTED]   [EMAIL PROTECTED]
Debian libspf2 maintainer  (No Cc of list mail needed, thanks)


pgpuO2NXxr227.pgp
Description: PGP signature

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Julian Mehnle 
Robert Millan wrote:
 On Fri, Jul 13, 2007 at 11:25:26PM +, Julian Mehnle wrote:
  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?

 To be honest, I have to say that I don't like the possibility of my code
 becoming non-free.

I can see that.  However, how would dual-licensing your patch under LGPL 
and BSD make your patch non-free?  BSD just isn't copyleft (in FSF 
terms[1]), but it's free nonetheless.

 If there's ever someone actively maintaining libspf2 again, and that
 person wants to stick with an unprotected license, I'll gladly license
 it in these terms.

What's an unprotected license?  A copyleft one?

References:
 1. http://www.fsf.org/licensing/essays/copyleft.html


pgpGG8GaPMje3.pgp
Description: PGP signature

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Robert Millan 
On Sat, Jul 14, 2007 at 01:46:45PM +0200, Magnus Holmgren wrote:
 On Saturday 14 July 2007 12:01, Robert Millan wrote:
  To be honest, I have to say that I don't like the possibility of my code
  becoming non-free.  That said, I always find it a reasonable compromise to
  allow this for the sake of merging the code upstream when the upstream
  maintainers require it.
 
 Although I too love FSF-free software, I personally wouldn't mess with the 
 licensing for a not so major patch like this is. On the other hand, it'd be 
 distributed as a separate dpatch so it'd be easy for anyone to redistribute 
 or rebuild the package without it.

Hi Magnus,

Your take.

As I said, I'll be happy to discuss relicensing with the libspf2 upstream
maintainer (when there is one, that is..).

As for the patch size, I believe it is copyright significant.  Besides, size
is not always representative of the work invested in it (writing new code is
quick, but finding and hunting down bugs isn't).

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Robert Millan 
On Sat, Jul 14, 2007 at 01:23:56PM +, Julian Mehnle wrote:
 Robert Millan wrote:
  On Fri, Jul 13, 2007 at 11:25:26PM +, Julian Mehnle wrote:
   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?
 
  To be honest, I have to say that I don't like the possibility of my code
  becoming non-free.
 
 I can see that.  However, how would dual-licensing your patch under LGPL 
 and BSD make your patch non-free?  BSD just isn't copyleft (in FSF 
 terms[1]), but it's free nonetheless.

For example, BSD license gives permission for Microsoft to incorporate the code
in Exchange, improve it, and not give anything back.  I find this unfair [1].

OTOH, it goes both ways.  BSD license also gives permission for Debian to
combine the code with an LGPL patch and distribute the result.

What strikes me most as being contradictory, is when someone finds the first
behaviour acceptable but not the second.  Why is it ok for Microsoft to
relicense but not for Debian?  They're both distributors of a derivative work.

[1] Note that with LGPL, they still can use libspf2 in Exchange and not release
any Exchange code back, as long as libspf2 is distributed as a dynamicaly
linked DLL and the modifications to libspf2 itself are released.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Julian Mehnle 
Robert Millan wrote:
 On Sat, Jul 14, 2007 at 01:23:56PM +, Julian Mehnle wrote:
  I can see that.  However, how would dual-licensing your patch under
  LGPL and BSD make your patch non-free?  BSD just isn't copyleft (in
  FSF terms[1]), but it's free nonetheless.

 For example, BSD license gives permission for Microsoft to incorporate
 the code in Exchange, improve it, and not give anything back.  I find
 this unfair [1].

Sure, sure, but that doesn't mean the BSD license is non-free.  It's just 
not copyleft, or viral, as Microsoft would call it.

Is this a matter of principle for you, or would you actually feel exploited 
by a closed-source vendor who uses a libspf2 modified by your patch?
I mean, they can use the UNmodified libspf2 under the BSD license already.

I'm just curious, not trying to pressure you into anything.


pgp7yXmsqYnsC.pgp
Description: PGP signature

Bug#431239: Patches from Robert Millan

2007-07-14 Thread Robert Millan 
On Sat, Jul 14, 2007 at 05:38:01PM +, Julian Mehnle wrote:
 
 Is this a matter of principle for you, or would you actually feel exploited 
 by a closed-source vendor who uses a libspf2 modified by your patch?

Uhm not at all.  If they add other changes of their own to create an added
value and don't share that with the users, I would feel bad for them, but I
wouldn't feel exploited myself.  I mean, I know they can do this anyway, but
I don't like to help them do it better.

 I mean, they can use the UNmodified libspf2 under the BSD license already.

Unmodified versions are not really rellevant, unless we're talking about
GPL instead of LGPL.  But I think GPL is excessive for a library like libspf2
(I suppose you agree with me on that).

 I'm just curious, not trying to pressure you into anything.

Oh, feel free to :-).  I'm always open for friendly discussion.

But in that case, maybe we should keep the conversation private.  I don't
think we should bother everyone with it.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431239: Patches from Robert Millan

2007-07-13 Thread Julian Mehnle 
-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]