I’ve run through this before in other threads, but I’ll outline it again.
The first, slower, and generally too-messy-to-bother solution is as outlined by PhysicsGuy. Namely the “out-of-process communication method”. You run a process that you can communicate through TCP/IP, UDP, etc and the GPL program connects to it and the two communicate over generic protocol. As ANY application can communicate with the TCP/IP program & there is no required linkage - it is not “derived from” GPL code and therfore need not be GPL licensed. The downside is that the applications are in two completely different processes and so embedded render windows and the like (ala Cycles) are incredibly difficult to the point of impracticality.
The second method is faster at runtime but requires alot more effort to develop upfront. To understand the legality, one needs to recognise and accept that the GPL only applies when distributing GPL licensed works. It does not, and legally cannot, apply in regards to USE of the work once installed as it is a copyright license not a contract. In other words, there are things the user can do once they’ve installed GPL software on their computer that seem counter to the restrictions on who they downloaded it from.
In a nutshell, the second method involves the creation & use of a generic plugin library that can be used by pretty much any host application or client add-on. The generic plugin library is licensed using an MIT/BSD style license (compatible with both proprietary & GPL applications) and is used by Blender for loading generic plugins and by generic plugins for use by any host applications that wish to utilise the plugin functionality. This library, for purposes of clean-room implementation, would most likely need to be developed by folks outside the Blender Foundation and would (by it’s very nature as a generic plugin library for 3D applications) sacrifice flexibility for the capability of being used by multiple host applications.
The reason this works is that whilst it is against the GPL for someone to distribute a proprietary library together with a host GPL application it is being used by, it is not against the GPL for the end-user to copy a proprietary library into his plugin directory and have the GPL host application load it by default along with any other ones there. Referring back to what I said earlier, the GPL only applies to distribution & copying, so as long as there is no GPL code in the plugin itself AND the plugin can reasonably be expected to run in another application - the end user is free to copy it wherever they like… including into a directory Blender might be looking for plugins with a given generic interface.
Thing is, it’s a lot of work & it would sacrifice flexibility, speed, and memory efficiency over a solution that can just plug straight into Blender API’s. Also, the plugin library used by native add-ons & Blender would need to be honestly generic, not just have the “generic” label applied. If it can be shown that the plugin library only really operates for/with Blender, there is a strong legal argument to be made that it is derived from Blender and therefore the GPL applies to any software using the library. If, however, a plugin can be hosted by Blender and (for instance) Modo - that argument loses traction outside the die hard “everything must be GPL” crowd.