[PAM-NTDOM] using pam_ntdom for ftp authentication

Peter Samuelson peter at cadcamlab.org
Thu Jun 15 02:36:47 GMT 2000


[Tim Potter <tpot at linuxcare.com.au>]
> I agree, but no matter how you look at it pam_whatever.so is
> dynamically linked in to a running executable by the C library.
> Hence, it falls under the GPL.

I still see gray area.

* pam_xxx was not specified at link time.  The creators of XYZ
  Whizz-Bang App did not know ahead of time that Whizz-Bang would be
  linked with pam_xxx.  Whizz-Bang runs just fine with or without
  pam_xxx, though with reduced functionality (and interoperability with 
  the rest of your PAM setup) without it.

  By contrast, "traditional" shared objects *do* need to be specified
  at link time.  If they aren't there at runtime, or if they don't have 
  the right symbols, ld.so has a fit.

* A shared library can be defined (to an extent) by its API.  RMS (if I
  remember correctly) has stated in the past that the existance of a
  GPL-compliant library with the appropriate API is sufficient to allow
  distribution of a program dependent on that library's API.  In other
  words, if the Harmony Project ever succeeds in bringing us a
  GPL-compliant implementation of Qt, it will actually be legal to
  distribute KDE.  (Yes, I know, Qt2 is open-source-compliant, but it
  still isn't GPL-compliant.)  This would seem to indicate that in this
  regard, the API is more important than the implementation.

  PAM has a well-defined module API.  Every PAM module implements a
  subset of it.  Thus if you have a non-free module, it could be argued
  that it's OK to link with it because you could link just as well with
  a free alternative.  Once again, the non-GPL module is an *optional*
  component of the running system, as opposed to a traditional shared
  library which is a *required* component.

There's other ways to argue this.  I remember a long thread on the
debian-devel list maybe a year ago, where Branden Robinson wrote
eloquently in favor of changing Debian policy w/r/t free versus
non-free software.  Current policy is that Debian does not accept free
software that has runtime dependencies on non-free software.  Meaning
GPL'd programs linked to Motif, etc.  Any such packages must go in the
`contrib' area and are not considered part of Debian proper.  Branden
wanted to extend this policy to other types of runtime dependencies,
such as network protocols.  For example, if there is no free
implementation of an ICQ server, Debian shouldn't ship clone ICQ
clients.  (While it may seem convoluted to some, his reasoning is that
there's a growing trend toward giving away client software dependent on
servers and content editors which remain highly proprietary.  Think
ICQ, QuickTime, Acrobat, RealAudio.  This trend is seen as a subversive
influence on free software, not to be encouraged.)

> This is one of several methods to get around the GPL (Tom
> Christiansen refers to it as comdomisation (-:).

Oooh!  Another person in the world who uses lparen-smileys!  I thought
I was the only one. (:

> In winbind, which uses pam and nsswitch, the pam_winbind.so and
> libnss_winbind.so modules are LGPL.  They talk over a UNIX domain
> socket to the (GPL) winbind daemon.

Nice how that works out -- you would probably want a client-server
approach even without the licensing issue.

Peter


More information about the samba-technical mailing list