A former colleage of mine (Hi Nigel!) frequently wore the greatest geek tee-shirt I have ever seen to work . Ineptly reproduced here, it summarizes the realities of software development - when deciding what to implement technical considerations are often overruled by more prosaic influences 
.
Take this comment by another old colleage. It is a example of how a lot of companies fail to exploit the huge amount of well-tested code available for reuse. There are lots of reasons why a company might ban boost, in my opinion none of them are that compelling.
The main reason cited is the fear of legal retribution (before continuing, I should point out that I am not a lawyer and the following is not legal advice.)
More than one company has been stung by employees including code they do not own into a commercial product, even accidental violations can attract huge penalties with big companies being particularly at risk. This has resulted in a climate where a company will pass every decision on third-party libraries through their lawyers. Lawyers by nature are cautious, they live in a world of contracts, indemnities and assigned liabilities. The default answer is almost always going to be "no" unless there is a contract to sign and someone to blame if it goes pear-shaped.
This the boost license agreement; it is one of most permissive licenses imaginable. Briefly, you can use boost in your projects in any way imaginable so long as you only distribute the binaries. If for some reason you distribute boost in source form then you must license it under the same terms. Seems pretty cut and dried - the boost authors are not going to come after you for using their code.
However, liability and infringement are explicitly disclaimed in the scary-looking third paragraph. I suspect that this disclaimer is what really raises the legal hackles. It is almost certain the case that some part of boost is infringing on somebody's patents, but only because every program over three lines long infringes on a patent somewhere. A company can be sued for infringement at any time for any reason, in my opinion using boost does not increase the odds of this happening.
There is a possible solution. Although boost is often banned from shipping products, nothing usually prevents it being used in the myriad of test tools and one-off utilities that every long-term project accumulates. This approach allows the benefits of boost to be gradually felt without impacting the main code-base as the team becomes familiar with the what the libraries offer.
I am not advocating sneaking boost in without managerial oversight, the decision to use and third-party code in anything that will be seen by more than one developer should be taken as a team. But I imagine most developers would like to make their lives a little easier and most managers would like their teams to be a little more productive.
Are you currently labouring under a boost-ban? If you were in the past, what compelled a change of heart? I would love to hear your experiences, please leave a comment.