[Edit]
My original-question was "Why to decide between static and non-static? Both do the same..."
Unfortunately it was edited to a C#-specific question what I really wanted to avoid.
So, let me do some additions:
When I say interface, I don't mean the C#-keyword-interface but what I understand something like a C++-interface: A set of well defined functions to operate with my object. When saying weaken my interface, I mean I have different functions (static/non-static) that do the same thing. My interface is not well defined anymore when there are different functions to do the same thing.
So, as Bob the Janitor posted, I can implement a Validate()-function
Document.Validate(myDocumentObject);
but also
myConcreteDocumentObject.Validate();
To get back to my Copy()-example one could implement Copy() like
myConcreteDocument.Copy(toPath);
but also
Document.Copy(myConcreteDocumentObject, toPath)
or
Document.Copy(fromPath, toPath)
when I think of a folder that contains all the files belonging to my Document (in this case I'm not dependent of a concrete instance - but I'm dependent from other things :)).
In general I'm talking about static methods not static classes (sorry, if I forgot to mension).
But as Anton Gogolev said I think my Document class is not a good example and not well designed so I think I will have to have a look at the Single Responsibility Principle.
I could also implement some kind of ManagerClass that operates with my DocumentClass:
For example:
myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);
or
myDocumentManagerObject.Copy(myConcreteDocumentObject, toPath);
but if I refer to approach 1) I would tend to create objects that per