Re: eCAP: expose Squid or link with eCAP lib?

On Sat, 2008-02-23 at 15:03 +0100, Henrik Nordström wrote:
> fre 2008-02-15 klockan 09:07 +1100 skrev Robert Collins:
> > Its more work both at code and at runtime. The only thing it really
> > allows that 1) doesn't is non-GPL eCAP modules.
>
> I don't see how 2) can allow non-GPL eCAP modules. We can't add a
> linking excemption to the license even if there is a well defined API.
>
> The only way to "link" non-GPL code to Squid is by not linking it into
> the runtime binary, statically or dynamically. non-GPL code needs to run
> in it's own process image, and for that we have ICAP already.

Split out runtime linking and compiling.

Runtime linking is done on the users machine, no distribution is taking
place and thus the GPL is not relevant.

Compiling uses header information (and on some platforms information
about the library (e.g. dll symbol name mappings) to cause the generated
binary to be one that will link at runtime correctly. This can (but
doesn't always) cause a copy of information to be placed into the binary
that was compiled. Distributing that binary requires a copying licence
for the copied information - which is where the GPL kicks in.

Now, when you have a well defined interface (e.g. readline), its
entirely possible to have *two* implementations that are binary
compatible.

Implementation one: GPL. Feature complete.
Implementation two: BSD. Feature complete from an interface perspective
(you can compile anything you can compile with the GPL implementation),
but its runtime support is shockingly bad.

And the loophole should now be obvious:
 - vendor A writes against the GPL version in private, to test.
 - they then create a binary module for platform X by compiling against
the BSD library.
 - the binary module runs against the GPL version.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>