I agree with Jonathan - as long as the function isn't supposed to return local data based on the calling database context, put the function in a utility database (this is also where I put things like numbers and calendar tables, splitting functions, etc):
CREATE FUNCTION dbo.whatever() RETURNS ...
Now, in every database that needs to access the function, just create a synonym:
CREATE SYNONYM dbo.whatever() FOR UtilityDB.dbo.whatever();
This way each database can still reference the function using a simple, 2-part name - and they don't have to know or care where it actually exists. And you only have to maintain a single copy of the function.
(And in fact, you can put the synonym in the
model database, so that it is created in new databases automatically.)
The reason I dislike putting user objects in
master - unless they really do need to be globally available and contextual to the calling database, like your own customized version of
sp_helpindex - is that people aren't looking for user objects in
master, and they're less discoverable there. They also make it harder to migrate your user databases elsewhere, because you need to remember the user stuff you put in
master, too. If you are absolutely dead-set against creating or using a utility database for this, I think
msdb is a more practical choice for a central location.