Yes, GPLv2 code can be used in the manner you describe. That in fact is one of the motivations for the AGPL and GPLv3. The modified code must, of course, never be given to anyone outside the organization or the obligation to make the source code available will be incurred.

There will probably be a negative reaction from the open-source community, as this use is considered technically legal but just not cricket (it's viewed at best as profiting from someone else's work without compensating them for it in any form such as by contributing new work back for others to benefit from). Possibilities for avoiding this include contributing the changes back (if they aren't a core part of the business) or contacting the project to see if the copyright holders would license the project's code for internal use in return for financial or other support (even if this project isn't under active development, hardware and other resources may be needed for other projects the copyright holders are working on).

The client side needs to be examined also. If there are any modifications made to the client code, the source code for them will need to be made available since the client will be distributed to customers. If there isn't a client (eg. a web application) or if an unmodified client is used, there won't be a legal issue.

The GPL is a copyleft open source license: it allows you to use and modify the GPL-covered software for any purpose. But when you create a modified version (such as by including GPL-covered code into a larger program), then you can only distribute that modified version under GPL terms, and all recipients/customers get the same freedom to use and modify that software for any purpose.

So the answer to question 1 is yes, you can sell software based on GPL-covered components. However, you must not only give your customers the corresponding source code, but also the right per the GPL license to use and modify that software for any purpose. So, the customers would legally be able to re-sell the GPL-covered software (potentially including some or all of your code).

This makes it difficult to "sell" GPL-covered software. The cost for the software itself tends towards zero. Instead, business models around GPL-covered software tend to involve:

• selling support contracts – the RedHat model
• consulting work to implement specific features
• selling convenience, e.g. packaging binaries for easy installation
• dual licensing – that's the model used by the library you'd like to use
• open core (but for copyleft licenses that requires a kind of dual licensing)

Another possible solution lies in your question 3.

The GPL itself does not clearly explain the scope of its copyleft effect. Instead, this depends entirely on what copyright law in your applicable jurisdictions consider to be a derivative work. However, the general understanding in the open source community is that the GPL applies roughly on a per-process level. If a program is designed to link to a GPL-covered library (statically or dynamically), then the entire program would be GPL-covered – not just those specific components that interact directly with GPL-covered components. In particular, this means that you can't insulate a proprietary component from a GPL-covered component with a permissively licensed component in between.

But if the proprietary component and the GPL-covered components are in entirely separate programs, that would be fine. The GPL allows GPL-covered code to be distributed alongside proprietary software ("mere aggregation"). Thus, it might be possible to wrap the GPL-covered component with a generic command line interface or REST API, to publish that GPL-covered program, and to then interact with that separate program from your proprietary code. For example, you can write proprietary code that interacts with a copyleft-licensed database engine, as long as the database runs in a separate process and you only interact via the database's wire protocol.