Why git is called a distributed source control system?
Short Answer
It is not different with client/server model except a local copy, so why is it called a "distributed" one?
In the diagram below alice and david can interact because the system is distributed.
Distributed Version Control
Notice how, say, alice and david can interact because each can act as a server.
Central Version Control
Here the dev team only interacts with the main server.
Long Answer
Traditionally speaking source control systems were designed as server-client setups, loosely speaking. So the repository was centrally located.
With git and Mercurial, the system is designed to put all users at equal footing. Everyone has the full repository with them. The control and repository in that way is distributed amongst it users.
Tools such as CVS and SVN offer a centralised repository model. Everybody commits their changes to the same central repository. Each committer keeps a copy of the latest version of the central repository. When they commit changes they send that change back to the main repository.
The limitations here are that you always need to have the latest code on your local repository, and to see the history of changes you will need to ask the server for that information. You also always need to be able to access the remote repository to commit.
A distributed SCN can emulate this model, but it offers so much more. Instead of just having one central repository that you send changes to, every committer has their own repository that has the entire commit history of the project. You don't need to connect to a remote repository, the change is just recorded on your local repository. You can still push to a centralised repository but you don't need to.
(Source: Pragmatic Version Control using Git by Travis Swicegood)
One big benefit of this is that you can start a repository at any time on your local computer. Generally when ever I start a new project I'll git init and start committing updates straight away. Later on if I decide I want to share this project with another developer I can easily set up a centralised repository that we can both access. Or it might never leave my computer but I'll have local version control in place and can easily view my commit history.
Another big benefit (perhaps less so with cloud computing now) is redundancy. If one copy of the repository is lost for whatever reason, any of the other repositories will contain the complete history so you could only potentially lose any work since your last push.
There's some more information on Wikipedia: Distributed revision control
I'd also highly recommend the above mentioned Pragmatic Programmers book on Git.
Because your clone can be someone else's master, and you can push your clone towards any other repository. There is no need for a concept of one "true" master; you can run it as a distributed grid of repositories.