This depends on what your jurisdiction considers a "derivative work" and "linking". Consider talking to a lawyer.
Personally, I understand the two schools of thought as follows:
The one school believes that what the (version of the) GPL says is literally so, so any kind of linking infects the other side of linking with the GPL as well.
The other school believes that "linking" has no meaning in the license and that only the "derivative work" as governed by the copyright law has relevancy, maybe even tempered by laws about providing compatibility. If you subscribe to the latter school of thinking, then you need to convince at least yourself that your code is not derivative of the (header) files of the other library.
Workarounds could be to implement a stub library which happens to use a similar interface to your library, or to provide a (GPL-licensed) shim of the library to another interface, and to have multiple backend implementations for the other interface. Then, one could argue, the other interface is not derivative and thus blocks the GPL restrictions.
See also Term::ReadLine and Term::ReadLine::Gnu + Term::ReadLine::Perl.
I've always chosen the easy way
In reply to Re: When linking to a C library, do I need to use its license?
by Corion
in thread When linking to a C library, do I need to use its license?
by stevieb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |