On Mon, Jan 28, 2008 at 03:34:38PM -0000, Mark Stosberg wrote:
> Since we don't ship OpenSSL with the code base, perhaps having a
> configure option is not a problem for us either--- that's a decision the
> user or packager is making.
> 
> Perhaps this is "Not our bug" then, but something for packagers to work
> out?

Right, at least in a sense.  We might consider it our bug, if this means
that packagers can't legally package convenient and useful darcs packages.
The only platform where this might seem likely would be windows.  Of
course, it also means that statically-linked linux binaries can't use
openssl, and there are people who provide statically-linked linux binaries,
it's just that they're much less needed on linux than under windows, and
it's not the end of the world for the statically-linked linux binaries to
not allow access over https.

> I had the sense that this issue might be preventing us from being
> legitimately included in some Linux distributions, but it seems I am
> wrong about that.

It depends on the distribution and how they package darcs.  Debian, for
instance, has two libcurl packages, one linked with openssl, and one
without.  Thus darcs can be built and used without openssl, and it's
unambiguously not a derived product of openssl.  But through the magic of
dynamic linking, the openssl-based libcurl can be swapped in by the user
all very legally (I believe... IANAL).

I believe most linux distributions are in the same (safe) boat.  Gentoo,
and other source-based distributions, have no problem at all.

> I'm not excited about the administrative effort for a licensing
> exception, either.

Indeed.
-- 
David Roundy
Department of Physics
Oregon State University