On Sat, 2004-09-25 at 10:16 -0400, Tres Seaver wrote: > Henrik Nordstrom wrote: > > > Note: Squid is GPL and as a result you are only allowed to use GPL > > modules with Squid. If your filter implementation is not GPL then > > dynamic linking is not an option. > > IANAL, bu wouldn't it be truer to say that the GPL does not allow > *distribution* of Squid linked with software under non-GPL-compatible > licenses? > > See: > http://www.gnu.org/licenses/gpl-faq.html#TOCGPLRequireSourcePostedPublic > > and: > http://www.gnu.org/licenses/gpl-faq.html#InternalDistribution > > And I am not sure that dynamic linking triggers the "derivative work" > provisions, particularly if Squid continues to function without the > presence of the library.
This is incredibly tricky to get right: If you take the position that dynamic plugins are derived works (of the thing they link into - which here would be the squid routines), you end up with interface copyrighting (that is, something that has no code, may only be a couple of lines, and is trivially the same for similar requirements - bleuch). if you take the position that dynamic plugins are not derived works, then someone can write a proprietary gzip compression module for squid, ship it at whatever cost, leveraging /all the squid internals/. Which is also quite unattractive. AFAICT there is no standard that one can apply neutrally and externally to instances of dynamic linking to decide whether it would count as a derived work. Currently it is a very messy situation :( Rob > Note particulary: > > http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins > > and the use of the word "believe" in that language. The GPL itself does > not mention dynamic linking at all. > > Tres. -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
