Re: Debian package for freeradius_postgresql module

As someone who licenses a lot of my code under the GPL, I feel inclined
to correct you.  Please note that IANAL.

Martijn van Oosterhout wrote:

>On Fri, Apr 07, 2006 at 04:16:18PM -0700, Chris Travers wrote:
>
>
>>By this interpretation, coding a connector against UNIX ODBC would be
>>OK, but the user would be forbidden to use ODBC drivers that link
>>against OpenSSL.  I cannot therefore imagine a circumstance where the
>>parent GPL application could be considered a dirivative work.
>>
>>Indeed indirect linking is a pretty common GPL dodge, given NVidia's
>>approach to drivers.
>>
>>
>
>Please keep in mind that this has nothing to do with what users can or
>cannot do. The GPL is a *distribution* licence.
>
No.  It is a copyright license.  It gives you the right to distribute
the original work, create and distribute derivative works, etc.  If it
didn't give you the right to modify the code, then any code
modifications would be subject to fair use law which doesn't exist in
some places in the world (like Australia, for example).

As for its scope, we may have to agree to disagree, or at least
acknowledge that it may have different scopes in different places.

Nowhere in the license does it say that you cannot link with other
software.  The FSF has been pretty clear that they consider linking to
be analogous to derivation (and in many cases, it might be).  Indeed the
GPL v2 is no more clear on the matter of derivation than simply to refer
to existing case law in whatever jurisdiction the coder happens to be in.

For example, the FSF convinced Apple that they needed to comply the GPL
when they were distributing binary objective C plugins to the GCC and
then providing information for people to link them themselves.  The
result was that the GCC got open source Objective C support thanks to
Apple.  Do we know whether these plugins were really derivative works or
not?  Not really.  But Apple chose not to fight it in court.

However, there are clearly cases where linking would not be derivation
in many jurisdictions.  For example, if I create a perfectly
standards-compliant ANSI C library, and I release it under the GPL,
anyone can code ANSI C and use any number of C libraries in their
compilation.  The fact that one happens to compile it against my GPL
work instead of any others would seem to be, while possibly an
invitation to litigation, a pretty clear case of standard interfaces
instead of derivation.

At least in the US (IANAL, again), not everything can be copyrighted.  I
personally doubt that header files would be copyrightable for the
purpose of making #include statements constitute derivation.  Especially
in the 9th Circuit, where you have the Gates Rubber test, I would think
that the filtration step would remove any code copied by the compiler as
a matter of making the program work with standard interfaces.  THus with
my ANSI C library, I don't think mere compilation against the GPL'd
version would constitute derivation, but IANAL.

> It says, in no
>uncertain terms, that GPL programs must come with complete source of
>themselves and all dependancies under terms compatible with the GPL.
>The advertising clause in OpenSSL is not acceptable.
>
>
No it doesn't.  Otherwise you couldn't release a GPL'd program for
Windows.  It actually says that the derivative work as a whole must be
released under the GPL.  Whatever this means is up to the courts,
unfortunately.  The FSF has their opinion on their web site, but
ultimately the only one who gets to interpret the license
authoritatively is the court.  Because nobody wants to fight there is no
clear guidance.

Best Wishes,
Chris Travers
Metatron Technology Consulting