Hi! On Fri, Jul 13, 2007 at 11:25:26PM +0000, 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]
