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.
Related posts:
At “large international software company” it’s not the Boost license which rules out Boost. Boost is used for example in another product which has a very similar name to the product I work on (very very similar name). But we already have invented-here string, date and shared pointer classes. Little things like to_lower_copy would be very handy, but aren’t enough to justify adding yet another library to work with.
This is a somewhat valid reason for not using boost, and one of the reasons that boost uptake was slow at my current place of work. There are already a lot of libraries that do part of what boost does (MFC, ATL, etc) not too mention homemade ones. There is no point in ripping out ugly but functional code just to use a cool, new library.
For new code, or even just new parts of existing projects I always push for boost. I would argue that it is so modular that even if you are not using the shared_ptrs or strings, the thread library or iostreams (or asio, or hash, or whatever) make it worthwhile to include in the codebase. Half the time you don’t even have to link to anything.
But I realise that not every project needs these features.
My boss has banned boost and STL because of “code bloat”. Instead we use such awesome constructs as sprintf, fixed size strings (char szText[STR]), strcat, strlen, etc. My boss also wonders why we get a lot of bugs. Go figure.
He introduces his own “code bloat” anyway through use of templates (For “long” strings only) so we aren’t doing anything differently to STL anyway, except for using less tested, less thought out and less useful code. Constantly my colleagues and I are saying, “So why doesn’t our list class provide a reverse iterator?”, “Because it is singly linked”, “Oh. Why? STL has doubly linked lists”, “I know, our boss doesn’t like doubly linked because ‘it is just code bloat’”.
the explanation that i currently have to live with is that using boost (or, by extension, other non-commercial software) does not give our company indemnity against intellectual property claims. in other words, there’s no third-party there to defend us if we are found to have infringed on copyright or patents, or whatever, by using their software.
some commercial licences do offer indemnity against such claims, even when open source software is used within the software itself. a great example is the qnx operating system. see the LIMITED WARRANTY OF PROVENANCE, INDEMNITY, AND EXCLUSIONS FROM INDEMNITY section of their license.
so the answer is clear. go and hire the lawyers that work at qnx software systems.
Matt, that offer from QSS is great – I wonder if they have ever had to defend anyone. And I wonder if they use boost internally. Last time I checked, Microsoft offers nothing of the sort except to maybe up to the limit of the money you paid them to license the product.
I am not a lawyer, but I can tell you that your software already infringes on any number of patents and is theoretically liable for millions of dollars in damages. All software is, regardless of whether they use boost or not. The trade off is gaining a tiny amount of risk for losing a vast amount of development cost.
But not every company sees it my way…