This is a difficult problem to resolve, but Edgar does have a good suggestion about ways to try to quantify the issue, so that more of us can determine what are safe updates to do, whether we're better off with or without a hub, etc.
As someone who has developed software and firmware for almost thirty years and been in several standards committees and cross-industry partnerships, I have deep sympathy for the dilemma that VSL faces in allocating resources for licenser issues vs. internal development.
I got bitten, for the second time this year, on a proposed release date for software, by an unexpected update by Apple (this past summer, it was simultaneous updates by Apple and Sun), that broke certain aspects of long-working features. Do you think our clients care that it isn't "our fault" and that we have no direct visibility on the problem or any way to get customers to back out a Java update (not possible on the Mac, thanks to Apple's philosophy)? This ties up resources, which is hard with a small development team (or, in my case, individual). So it is always a balancing act.
Users do not expect vendors to "pass the buck". So it is not surprising that there is some extreme anger being expressed here. My own anger, however, is directed at Steinberg. Yet I do accept that VSL cannot and should not be cavalier -- nor do I think they are behaving that way, by any means. Rather, I think Edgar himself has pointed out that there are so many variables, that it would be difficult for any vendor to test every possible combination of what clients may have.
So this brings us back to the licensing choice itself. I personally feel that VSL should investigate abandoning eLicenser for something else -- especially as many of us now have large libraries and thus this approach to license verification is going to be a performance hit at some level, even in the best of circumstances. But as I have a very positive experience with another approach, I am more confident that eLicneser needn't necessarily be the only safe and viable choice for VSL to protect their property.
B.F.D. 2.0 introduced a new license protection scheme by fxpansion, that is easy, safe, and non-invasive at run-time. I have no idea what they did, or even if they licensed it from someone else, but it seems to work for them, and though they don't have as many libraries as VSL does, their libraries are as big and deep as VSL's, so the stakes are about as high regarding piracy protection.
Perhaps VSL could contact fxpansion (who are not competitive with VSL) and find out what the options might be?
But who am I to prioritize this for them? I am merely suggesting it. There seem to be workarounds for almost everyone's problems with eLicenser, even if it can be a PITA at times. I'd rather have the Choir Library ready, personally. Choices do have to be made. If we want VSL to prioritize responsibility for eLicneser problems, we suffer in other ways. Think about it.
Software engineers have a tendency to be too abstract and not grounded in the real world implications of their work (this is a big reason why I left the computer industry for the audio industry eleven years ago). I wish something could be done about that, but it is unlikely to change. I consider it inexcusable, when a license-oriented vendor such as PACE/iLok or eLicenser, doesn't calculate the harm to millions of end users of products for which they only themselves have an abstract connection. It's a disconnect, wherein the license vendor doesn't have sufficient incentive to make sure everything works.
License protection, for better or worse, has to be less punitive regarding a user's hardware/software upgrade cycle and budgeting choices for when to get a new computer, than other software and hardware. This is probably why PACE/iLok chose the web browser as their licensing interface, to better decouple themselves from system requirements (although I am unable to use their website on certain popular and robust browsers on the Mac, and let them know, to which they replied that I should use Safari instead, even though that is a sluggish and relatively unsafe browser overall).
