The question for this and any other external library is _maintenance_. What is the lifespan of your application and what is the apparent lifespan of this library? Yours should hopefully be the shortest. Who will do bug fixes for this library? As it looks from here, your company should explicitly allocate resources in the future for maintaining this software, as you cannot rely on any other fixing bugs for you. You cannot share the maintenance burden with anybody else since you cannot share the source. Want to hunt down an elusive race condition bug in code you don't know? This thought alone might make the library too expensive to use. This might be irrelevant if the library is very solid and robust and easy to work with on the source level, but my experience is that the peer pressure of true open source projects simply make the code better because you tend to do your best then. Personally I would think very careful about if I would adopt this or any other external code, since the whole reason for using other peoples code is that _you don't have to deal with it yourself_. Also think of future maintainers - you should do fire drills changing code in the library to see if it can be done at all. There might be some VERY nasty surprises here. Are you at liberty to discuss the library in question?