Is there a reason why the source code of software mentioned in research papers is not released? I understand that research papers are more about the general idea of accomplishing something than implementation details, but I don't get why they don't release the code.
For example, this paper ends with:

Results
The human line drawing system is implemented through the Qt framework in C++ using OpenGL, and runs on a 2.00 GHz Intel dual core processor workstation without any additional hardware assistance. We can interactively draw lines while the system synthesizes the new path and texture.

Do they keep the source code closed intentionally because of a monetization they intend to make with it, or because of copyright ?

Several reasons come to mind.  


Code is too big for article.  For a short period of time, interesting projects were short enough to be published with the paper that described them.  This can still happen, but many projects of sufficiently large size to be interesting have grown too big to be published with the papers that describe them.
Public hosts not free or durable.  Until recently, cheap, durable, easy to access public hosts were not available.
Publishing a paper is easier than publishing a project.  Some people have time to publish a paper or a project, but not both.  
Incentives tied to role.  Many years ago I asked a colleague about product development and patents and got the word that most people there pretty much did one or the other.  As with paper writers (think academia) and open source developers, rewards are geared toward one work product or the other.  
Self motivation.  The desire to describe ideas or to implement code is not always present in equal parts in the same person.  Many of my professors openly admitted that they either never coded very much, or were many years away from having coded fluently.  Similarly, many developers barely want to write comments in their code or when they commit to source control.
Durability of project hosting and work product is also an issue.  Who wants to link somewhere that might be gone a few years from now and as a result, diminish the value of the paper.
Tradition.  Publishers are oriented toward reviewing and publishing papers, but might not be ready to take on the same evaluation for projects.
Also the traditional views on what is a sensible level of reproducibility varies among fields. A chemist publishing a paper about a new synthesis method is expected to write down enough detail for another chemist to perform the synthesis. She'd not be expected to ship the educts and product to the journal. Readers who want to use/reproduce the paper are expected to buy their own educts and do the synthesis themselves in their lab (though they may ask to come and visit the lab to see how it is done in practice). Neither would a biologist be expected to attach his new transgenic mice to the paper. This view on reproducibility corresponds to e.g. giving a (pseudo-code) description of the algorithm as opposed to shipping the actual implementation. 
Naked code can be shocking.  It takes a lot less polishing to proof-read a paper length document than to code inspect, code review, and quality assure a project.  I have a lot of code I would be more comfortable telling you about than showing you.  Hopefully things are moving forward to a point where we will all write beautiful code, but if your code was rushed, barely or doesn't completely work, you might be more comfortable not sharing the executables or the source.
Closed source.  Not everyone has embraced open source.  Many papers are written about work for DoD, commercial projects, or privately funded projects where there are benefits from exposure of the project to the public, but there are still trade secrets or first to market advantages that could be eroded by open sourcing the code or other work products.
Publish further work based on this code. If the code is not published it may give the author an advantage in publishing followup work. Other competing researchers may need to reimplement the work which may take precious time.

