So to me it seems natural to included in the header along with the whole class declaration.
Consider a library that provides foo.h, which defines class foo, and a program that #includes "foo.h" because it needs to use class foo, but it doesn't need to serialize it. To me, it isn't natural for such a program to require boost serialization headers. I suppose you could separate serialize/load/save overloads in a different header file, but because typically they need to be friends, foo.h would have to declare them in order to make them friends, which is a hassle. Instead, you could simply define serialize/load/save directly in foo.h without including any serialization stuff -- except that a program that does serialize foo objects would have to register class foo "manually".
That way when that header gets used by other programs, they all share the same external name - as they should since they're sharing the same header.
If I want to make a particular class to have the same external name across multiple programs, this is easy to achieve by sharing the code that registers that class with boost serialization. I just don't think that the class' header file is the best place for this registration. Emil Dotchevski