[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SHA, MD, and openssl

From: Stephen J. Turnbull
Subject: Re: SHA, MD, and openssl
Date: Tue, 10 Dec 2013 10:51:39 +0900

Richard Stallman writes:

 > Do users ever install these libraries separately from the major
 > system components?

I have to ask, does this question make sense any more?  Users install
*everything* "separately" these days.  Nobody unpacks a tarball into /
and reboots -- you install a tiny system (which in the days of
floppy-based installs included a crippled libc, and even today many
installers seem to use busybox instead of a suite of separate
utilities), which then starts acquiring packages (kernel, libc, Emacs,
NCSA httpd, Mosaic, oops-i'm-showing-my-age.deb, ...) and installing
them one-by-one.  What's the distinction between OpenSSL and Emacs
when installed by a list-of-packages-driven package manager?

Again, if a security bug is discovered in OpenSSL, *everybody in the
world* downloads and installs *just* that upgrade.  And *almost*
everything is distributed "with" the "major components".  Even Debian
provides installers for non-free software such as Adobe Flash I
believe.  Although Debian does provide a clear distinction on license
grounds by using "free", "nonfree", and "contrib" subdistros, most
other distros don't bother AFAIK.  Nor does "library" help much when
you're talking about Emacs, which provides almost all of the services
(ie, excepting raw memory allocation) to libraries that the programs
traditionally called "operating systems" do.  In some sense, anything
Emacs links to becomes part of the E-OS!

Perhaps you can draw a fine distinction, but I suspect that's going to
cause more confusion than it's worth.  GNU/Linux (as in the Debian
"free" distribution) is a functionally complete operating system,
including advanced GUI display.  Unless you make a clear definition,
developers are going to assume that anything "in" a distro that is a
"library" is a "system library" per GPL, and therefore linkable with
GPL programs.  But that won't fly (per your decision on X/Open Motif
as distributed by Red Hat, TurboLinux, and SuSE (IIRC) a decade ago).

With respect to OpenSSL itself, I have trouble seeing it as a system
library in the sense intended by the GPL.[1]  Secure communication is
an application everybody wants these days, but it is not a necessary
part of a host's operating system, not even as much so as Motif was.
It's very painful if you can't get it GPL-compatibly.  But that's
never been an excuse before.  You wouldn't even allow a *separate
binary* to be required for secure communication functionality in Emacs
(original TRAMP + SSHv1, granted that SSHv1 was non-free, it *was* a
separate binary, so by the usual "exec boundary" didn't infringe).

[1]  AIUI, the intention was to allow Emacs (for example) to link to
a proprietary system libc.  Otherwise Emacs couldn't be distributed
*at all* with proprietary systems, which is clearly a Bad Thing from
the point of view of encouraging such distributors to free themselves.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]