Library naming

<delurk />

First of all, Hi everyone!

I've been reading this mailing list for a while but not posted to it 
(mainly because I haven't felt I've had anything to add above and 
beyond what others have already said). But on the issue of the 
'libspf-vs-libspf2 controversy' I have some points I'd like to mention 
because noone else so far seems to have done so.
In this discussion, the point has been made several times that having 
one library named 'libspf' and another named 'libspf2' is likely to 
cause confusion, as to some it might appear to imply that 'libspf2' is 
a second version of 'libspf', or that some other type of relationship 
exists between them. One suggested solution has been for 'libspf2' to 
be renamed to something less likely to be confused with libspf.
But I think that argumentation misses a very important point: The 
problem isn't with the choice of name of 'libspf2' - the problem is the 
choice of the name 'libspf'. 'libspf' is about the most generic name 
one could possibly choose for a project that wants to implement a 
library for SPF processing.
'libspf' isn't only the most generic name possible - it's also a name 
that suggests a certain level of 'officialness' - i.e., the name 
'libspf' doesn't just imply '_a_ library for spf' but also '_the_ 
library for spf'.
'libspf' being the most generic and most official=looking name, it also 
sets a precedent that others who are interested in implementing 
spf-handling libraries will feel inclined to follow - which led to 
'libspf-alt', which was renamed 'libspf2' because from the viewpoint of 
its authors it really wasn't a situation of one official library 
'libspf' versus an alternative but non-official 'libspf-alt', but two 
separate and  equally official-or-not-but-who-really-cares libraries, 
'libspf' and 'libspf2' where the '2' does _not_ imply a version number.
James Couzens, the author of 'libspf', has repeatedly made claims that 
the name 'libspf' is 'his' - essentially by virtue that he grabbed it 
first, and that anyone else who uses a similar name is 'stealing' from 
him. However, that viewpoint disregards that the very name he chose, 
'libspf', by virtue of it being so very general is likely to be 
involved in many more name conflicts than a more distinct and less 
generic name would be; and also that by choosing an 'official-looking' 
name he has himself set a precedent that others will be inclined to 
follow with just as much right as he has.
To my mind, there is an obvious solution.

*Both* the 'libspf' and 'libspf2' projects should be renamed, in such a 
way that they use names that cannot be confused, and also such that 
neither name will be inherently more official-looking or more generic 
than the other.
This would solve the whole thing: Neither implementation would look 
more or less 'official' than the other (and since neither of them _is_ 
more official than the other that is exactly the right way things 
should be), the names would be distinct and unlikely to cause any 
confusion. Thus, all the pointless bickering could stop.
Also, it wouldn't place the burden on just one of the parties in this 
controversy, but would spread it out more or less evenly.
And as an added bonus, the 'libspf' name would be available to the 
community to be _awarded_ should there ever be a situation where one 
library does stand out as a reference implementation of SPF handling. 
In a way, it could be seen as incentive: the different implementations 
could compete to gain that name, if so desired.

Comments? Thoughts? Derision? Personal Attacks?

Best wishes,

// Christian Brunschen