Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Russ Allbery <rra@stanford.edu>]

Simon Josefsson <jas@extundo.com> writes:

> However, when I re-licensed GNU SASL from GPL to LGPL, after similar
> requests, it didn't bring me any benefits.  People who said they would
> use and contribute to the project if it was LGPL never showed up after
> the license changed.  Further, all application that use GNU SASL today
> appear to be licensed under GPL anyway.  The license change meant a lot
> of work, separating the core package from the library, and it didn't pay
> off.  I have considered reverting back to GPL, so that GNU SASL can use
> some libraries that are licensed under GPL (such as libksba, a X.509
> library).  So forgive me if I'm skeptic when people who aren't using my
> software come to me and claim that it would be better for me if I
> changed my license.  So far, those claims doesn't appear to have been
> valid for me.

Well, see, you're running into a couple of issues here, and yes, it's
quite possible that a license change still wouldn't change anything.

The software area in which you're writing code is fairly mature and even
standardized.  Pretty much everything that does SASL uses Cyrus SASL.
Pretty much everything that uses Kerberos uses either Heimdal or MIT
Kerberos (and generally can build against both).  Now, sometimes there is
still a clear space for a new implementation, such as gnutls which has
both a better license and a nicer API than OpenSSL.  But in this case,
while there are certainly a few issues with all those existing packages,
there just aren't the issues that would push someone towards a new
implementation, and the issues are known and there are known ways of
dealing with them.

I expect that a lot of people writing Kerberos software would be willing
to make it build against either the existing libraries or yours,
particularly if asked by a Shishi user.  But the situation from a
distribution standpoint is much different.  It's a huge amount of work
(and work that's generally not worth the effort) for Debian to build all
Kerberos-using packages against multiple libraries, and it's confusing for
our users to have to choose between different packages.  It's also proven
in practice to not be horribly maintainable.  So realistically it's more a
discussion of a switch rather than supporting both, and unless Shishi just
has amazing new features that can't be added to the existing libraries,
there really aren't many motivations for anyone to switch.

On top of that, since this is authentication software, it often goes
through a much tighter change management process and is handled far more
conservatively.  For instance, there's no way that I'd deploy Shishi as
the KDC for stanford.edu for at least another five years, just because
Shishi isn't mature in the way that MIT Kerberos is.  This is nothing
against the quality of the code, which I've not even looked at, but comes
from a very conservative attitude towards changes to the core
authentication infrastructure.  Large sites aren't going to want to be the
sites that encounter the interesting problems.

So to be clear, what I'm saying is that without a license change, using
Shishi as the library for software in Debian on a widespread basis
probably isn't even an option.  With a license change, it becomes an
option, but that's far from a guarantee that it would actually happen.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>