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>. >
signature.asc
Description: This is a digitally signed message part
