I am currently looking at ways to circumvent the limitations imposed by LGPL licences. The software I am planning to use is LGPL and is mostly used in the UI side. The idea which I am thinking is to create a client server architecture where the client can be distributed as LGPL but the server will be closed source. Since both the component is only communicated via ports; my understanding is that there is no need to release the server part of the software under LGPL or any OpenSource License. The software is a desktop application which in my view could run on the same machine communicating via ports. Is there any problem seen with this model?
It is true that copyleft requirements can only apply to material that is within the same copyrighted work as the copyleft-licensed material. If you employ a client-server model, it is quite likely that the client and server will be separate works. It may be possible to bungle this separation such that the two pieces remain one work but it's unlikely to happen as long as you have sensible separation of duties and a meaningful protocol employed between the two components. (In other words: don't simply have them use and modify the same memory, and ensure each component has a sensible design independent of the other piece.) The GPL FAQ has more to say about this:
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
However, note that this may not be necessary at all for your case. The LGPL does not place significant requirements on your work as a whole, so you may spend quite a bit of work rearchitecting your program for something that was never a problem in the first place. Unlike the GPL, which requires that your whole work be licensed under the GPL whenever it is distributed, the LGPL only requires that the library itself -- not the whole work that uses the library -- remain under the LGPL. The only requirements the LGPL places on the broader application is that the LGPL library must be easily replaceable by a modified version of the library. In practice, this usually means dynamically linking the LGPL library so that a modified version can be dynamically linked later by someone else. Your own application code may be under virtually any license whatsoever without causing issues with the LGPL.
LGPL dose not affect the rest of the program.
Doing something that is obviously a circumvention will not work. If the two pieces of software are intimately connected, then they are one. No matter the communication mechanism. Procedure call, pipe, socket, syscall, it makes no difference. What makes a difference is dependency: if they both depend on each other, then they are one.