On Mon, Aug 20, 2001 at 12:27:36AM -0500, Albert Chin wrote:
>
> However, UCD-SNMP is under a BSD-like license so I believe it can
> cleanly link against OpenSSL. So, if Ethereal links against UCD-SNMP
> which links against OpenSSL, what happens?
>
> It seems though that because Ethereal doesn't *use* OpenSSL for
> anything, there's not a problem. I should have dug further. Sorry.
Since I've followed a couple of similar threads on openssl-dev in the
past year, I thought I'd summarize the gist of the issue as I understand
it (and IANAL, of course; nor do I speak on anyone's behalf other than
myself and I even get that wrong sometimes ;-)...
- The position of the OpenSSL team is that OpenSSL is free for anyone
to use [1]; their FAQ on the question is at [2]
- The position of the FSF seems to be that the license under which
OpenSSL is distributed (specifically one or more clauses of the old
ssleay license -- OpenSSL has two licenses), is GPL-incompatible and
that even dynamically linking against OpenSSL makes redistribution
of your GPL'd application a violation of the GPL [3]
- This cannot, though, be an issue for redistribution on operating
systems on which the OpenSSL libraries are distributed as part of
the operating system since the GPL contains a specific exclusion for
such cases [4] (e.g., recent versions of {Free,Net,Open}BSD many
Linux distros, etc.)
- So it seems that the issue, if there even is one, would only relate
to redistribution of Ethereal executables[5] linked against OpenSSL
libraries on operating systems that don't include OpenSSL (e.g.,
Solaris, maybe? But not win32 since ucd-snmp and therefore OpenSSL
isn't used by ethereal on win32)
- (IMHO, the notion that dynamically linking to a library is creating
a derived work of the library is odd; in my non-lawyer mind, a
derived work of a library would be a modified form of the library,
not use of the library in its intended form; in a sense, linking
against a library should be viewed no differently from a user using
an application via its user interface)
- Since the OpenSSL license cannot change, their only proposed remedy
for those that are hounded by the FSF or agree with the FSF's
analysis on this issue is a license modification to the application
to specifically allow the use of OpenSSL [2]; again, they're not
arguing that people to make such a modification and don't believe it
is (or at least should be) required
- It seems we can do one of three things:
- Conclude that there is not an issue with the limited and indirect
fashion in which we use OpenSSL, or conclude that there is a
conflict, but it is very limited and not particularly troubling;
either way, make no change to our license
- Conclude that a change is required to allow redistribution of
binaries that are linked against OpenSSL for platforms which do
not include OpenSSL in their distribution and that the change is
conflict is constraining; then track down permission from all
contributers to modify the license
- Table the issue for later discussion
- The push on other projects has appeared to come either internally
(e.g. Debian) or from the FSF, not the OpenSSL team; this is
somewhat odd given that it's the GPL'd software and its users that
are benefiting from OpenSSL, and the OpenSSL team is not only not
concerned but actually supports the use of OpenSSL by GPL'd (and all
other) software.
cheers,
--Scott
[1] http://marc.theaimsgroup.com/?l=openssl-users&m=97417764222228&w=2
[2] http://www.openssl.org/support/faq.html#LEGAL2
[3] http://marc.theaimsgroup.com/?l=openssl-users&m=97416854609383&w=2
[4] starting about line 159 of COPYING
[5] since only in executable form would you be distributing any software
whose source code was under the OpenSSL license, and that only
because of the way the GPL defines 'complete source code' to include
interface definition files (around line 156 of COPYING)
--
Scott Renfro <scott@xxxxxxxxxx> +1 650 862 4206