Free source control systems don't tend to give you this information because they work disconnected from the server - you can 'get' a file, but you don't have to tell the server that you've changed it until you come to check in. This is itself a deliberate feature, as it means that you can work on the road, at home, etc, without being tethered to the central repository.
Locks can be used in subversion to some effect to get similar reporting, but it's not a great solution. They're designed to prevent 2 people modifying a file at the same time, specifically where merges are a problem. That said, they don't actually prevent someone checking in a file without getting the lock, so they're a weak indication at best, not a guarantee.
Also, none of the more modern distributed systems, like git or mercurial can even begin to give you this information, the repositories are on your machine, not centralised, and links back to the original are tenuous as best. Consider - you've got 5 local branches, do you report all the files as being modified against the original, or just the active branch? You can clone repos from already cloned repos, how many levels of abstraction do you follow to get to the 'master' repo? Who decides, and how would you configure what that master is? Git et al can handle all this complexity with great grace, but the question 'who has checked out this file' is almost meaningless in this context.
The old stalwarts like TFS and Perforce do allow this. But I'd be curious why they need this feature, just because someone has a modified copy of a file doesn't really mean anything in management terms, branches can still be protected very effectively using repository security, any task tracking system like trac or redmine will tell you who's doing what and integrate with svn perfectly.
There may be 3rd part applications that look for working copies and upload status information to a central reporting server, but I've not seen one. It might even be worth making one.