I don't think you understand. How can you switch from the one to the other if they're separate technologies? Going on foot is not a substitute for driving a car when we're talking about transporting 100 refrigerators from a port to a warehouse 300 km inland, it's only a substitute when we're talking about transporting a person less than a few kilometers and when time is of little importance.
That's not to say that there are no alternatives to relational databases or SQL, but the leap to 'oh then NoSQL will take over' doesn't make much sense.
Raise the price of the current solution sufficiently, and the migration then makes a whole lot of sense.
This even if the target product is less capable, less desirable or otherwise inferior, given a sufficiently large price delta (or hassle delta or product support delta, etc) then management and operations and finance will most definitely encourage the migration.
Both are in the business of storing data that can later be retrieved again, so I don't think your analogy really holds in this case. Maybe you are thinking of one particular nosql solution but I think almost all projects could find an alternative to a database that uses SQL. That is not to say that it shouldn't be a relational database or that there's a one shoe fits all solution out there.
Mongodb has ad-hoc queries (not as simple as SQL, but still). Many engines can run huge aggregated queries (hadoop?)
But I think the problem is placed in the wrong place. If SQL the language/API is copyrighted, then isn't it easier produce a new API with the same functionality?)
That's not to say that there are no alternatives to relational databases or SQL, but the leap to 'oh then NoSQL will take over' doesn't make much sense.