I spent a bunch of time doing the backend technical work for the Turing Archive (a collection of works by or concerning Alan Turing, sketches, photographs, draft letters, notes towards articles, all that stuff) when I was much younger. The Archive's main actual activity was basically making sure they "tried real hard" before shrugging and marking things as cleared by reason of failure to communicate with any legitimate owner.

That means you record what you tried, and you listen to reasonable suggestions for other things to try, but you aren't obliged to just give up and throw away works that you can't clear. Archives around the world would be emptied by such an approach, so it would be unconscionable to insist upon it.

Now, for code, because it's functional, it might also be replaceable, and also it's much newer so you're not going to dead end as much, but if you really weren't able to find anybody who objects, a court might very well frown on the theory that you're wilfully infringing when, eventually, you give up and just use what you have. Wilful infringers don't waste their money asking for permission. Of course if a copyright holder turns up later, says they own it and they want you to stop using it, that's still a problem, but it isn't a retrospective problem, just an ongoing one.

Actual damages and attributable profits are construed quite narrowly by case law. In the context of an open source project it's not irrational to bet that most contributors would be unable to win a sizable monetary award, if anything at all; likely nothing that would cover the costs of attorney's fees.

Let's assume OpenSSL has done some due diligence and searched the Copyright Office's database for OpenSSL code. Presumably, then, OpenSSL is making the legal gambit that, except for the most significant contributions, the only thing they really have to fear is an injunction. If they've identified and achieved new license terms for the big contributors, then this isn't a horrible strategy. You can take a wait & see approach, lazily replacing code at your convenience unless and until you see a registration, at which point you immediately replace the code--helpfully identified by the registrant--that might expose people to substantial monetary liability, such as statutory damages.[1]

As noted else thread, all open source code comes with some risk of unintentional infringement and liability. Indeed, all proprietary code does as well. It's common wisdom outside the open source community that the risk is greater with open source code. That seems more like wishful and motivated thinking on the part of corporations and lawyers, IMO, but in any event if vendors are okay with the existing legal risk than they may be okay with any additional risk from the wait & see strategy made possible by the procedural technicalities of U.S. copyright law.

All of this ignores the law of other jurisdictions, though.

Caveat lector: IANAL.

[1] I'm unsure if, how, and when continued infringement of newly registered code might subject you to statutory damages. It might not, at all, as a practical matter. Or maybe the next Github commit that is deemed to create a derivative work does. That's a big gap in my conjecture.

So, yes, it's compatible, in a "you may be forced to upgrade to v3" kind of way.

(Disclaimer. I work on MySQL.)