Nicolas Williams wrote:
> On Tue, Oct 30, 2007 at 08:41:28AM -0700, Garrett D'Amore wrote:
>
>> Hmm... PAM modules are dynamically linked. Our PAM implementation is
>> not GLDv2. It sounds to me like this might present a licensing conflict?
>>
>
> You have too much GLD on the brain!
>
> :)
>
> We've had the GPLed PAM modules discussion before. We need advice from
> Sun Legal. There is precious little treatment of license issues in the
> case of non-GPLed pluggable frameworks using dlopen() to load what might
> or might not be GPLed plug-ins. At worst we cannot ship GPLed PAM
> modules along with a non-GPLed libpam, but customers can still use them.
> I am very skeptical that the GPL can reach that far, but I am not a
> lawyer.
>
My biggest fear here is that this is an area where there is little, if
any, legal precedent set by the courts. I do know that some GPL
advocates take a very broad view of what constitutes creation of a
derivative product... As a specific case, Donald Becker has offered to
sue anyone who redistributed ported versions of his GPLv2 NIC drivers
for Solaris, because Solaris itself is not GLDv2. (Apparently he
considers "modload" creation of a derivative product.)
Customers/end users can do what they want. We can even point them to
the location to obtain a the PAM module, I think. (GPL only restricts
distribution, not use.)
But I really do not think it is a good idea for Sun or OpenSolaris to
expose themselves to a potential suit where the case is not
cut-and-dried. I think dlopen() falls into the grey areas; to the point
that I think it likely the author's intent was to prevent use on
non-GPL'd PAM systems (else why not release as LGPL?)
How difficult would it be to write a replacement? IIRC, Radius is a
relatively simple protocol, so I'd think it would be a fairly
straight-forward task to write up a replacement from scratch. (I
suspect figuring out PAM will be the hardest part of such a task.)
Now the Radius *server* should be fine.
-- Garrett
