If you have not copied GPL code into your files (and copying includes translating, adapting, or otherwise transforming the code before you use it), then your work standing alone is not a derivative work of the GPL work.

When the client combines your work with the GPL work, the resulting work on the client machine is a derivative work of both the GPL work and your work. The client must obey both licenses, if the client's combining and copying isn't excused by some exception to copyright law, such as fair use or the exception that allows copying to RAM to run a program.

If the client's production of this derivative work violates GPL, then it is possible that you could be liable for this infringement, as a contributory infringer.

However, the client's production of the derivative work by combining GPL and non-GPL code does NOT violate GPL. The GPL allows the client to take GPL code and non-GPL code and freely mix and use them for his own use. It is only if he wants to distribute the result that GPL requires that the whole work be distributed under GPL.

This lets you off the hook for contributory infringement--it is simply not possible to be liable for contributory infringement when there is no direct infringement for you to have contributed to.

What if the client DOES try to distribute the combined work? Then the client is a direct infringer. Could you now be on the hook for contributor infringement? I'd say you are still safe, because the bar to contributory infringement is pretty high. There must be no substantial non-infringing use possible with your work. Essentially it must only be useful as part of client infringements. That would not be the case, because your work would be useful in the way you intend--for clients to combine with the GPL work to run on their own systems. That's a non-infringing use, and its substantial.

To be safe, when writing add-on A to work with someone else's program P, I'd recommend the following.

1. If P is under an open source license and you wish to license A under a compatible open source license, there is not much to worry about. Write A using whatever means are most efficient, including copying code from P. Skip the rest of the items in this list.

2. If you plan to use a license that is not compatible with P's license, examine P's license to see if there is anything in it that would prohibit P's users from using unapproved add-ons. If there is, you may have to worry about contributory infringement. If that is the case, I'd say give up, unless A will have some use outside of being an add-on for P. Most open source licenses do allow users to do anything they want on their own systems, so if P is under an open source license continue on to item 3.

3. If you plan to use a license that is not compatible with P's license, do not copy any code from P. Ideally do not even look at any code from P. If you need to call functions in P that are not part of a publicly documented API, get the call information from someone else, and don't get code from them--get them to provide a formal specification of the interface but no sample implementation.

The idea here is that you want to be able to say and prove that you wrote A without looking at P's code or any copyrightable elements of P. If you can maintain that, you can't have produced a derivative work. If you haven't produced a derivative work, you don't need permission from P's copyright owner. If you don't need permission from P's copyright holder, you don't care what P's license says.

Note that this is very similar to the procedure you would use when developing an unauthorized add-on to a commercial program whose developer is hostile to unauthorized add-ons. The only real difference is that the open source program defines unauthorized as "not using the license we like" whereas the commercial developer probably defines it as "didn't pay me big bucks to join my developer program".