Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 57023 invoked by uid 500); 19 Oct 2002 09:56:37 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 57010 invoked from network); 19 Oct 2002 09:56:36 -0000 Date: Sat, 19 Oct 2002 02:56:40 -0700 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: distributing encryption software From: "Roy T. Fielding" To: dev@httpd.apache.org Content-Transfer-Encoding: 7bit Message-Id: <1095AEC3-E349-11D6-A18C-000393753936@apache.org> X-Mailer: Apple Mail (2.482) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ryan asked for a clarification about whether or not we have the ability to redistribute SSL binaries for win32. Last year, the board hired a lawyer to give us an opinion on whether we can distribute encryption software, or hooks to such software. The exact opinion we got back is, unfortunately, not online, but it is essentially the same (with less detail) as the one given to Debian and visible at . Basically, we have the right to distribute encryption software in source or executable form if we also distribute that same software as open source for free to the public, provided we first notify the U.S. authorities once per new encryption-enabled product. This is sufficient for Debian because they distribute the source code to everything in Debian within a single repository. Note, however, that we do not do the same for OpenSSL. Not only is OpenSSL not in our CVS, but it isn't normally distributed by us at all, and the authors of OpenSSL aren't likely to want us to distribute it because doing so pollutes the recipients rights with U.S. crypto controls whereas they could simply grab the same distribution from the origin and not be polluted. I think that Bill Rowe at one point requested that we seek out a lawyer's opinion on this specific matter, but that was not followed through by the board because we already know the legal aspects. The issue isn't legal -- it is social. We can download a released version of OpenSSL, compile it, and make both available from our website provided we first notify the BXA as described in the Debian opinion above. However, it is still preferable for our users to get the DLL themselves, from a distribution outside the U.S., and avoid having to maintain our distribution of OpenSSL up-to-date. I think a reasonable and defensible compromise would be to make it part of the win32 installation script -- to select no SSL or, if SSL is selected, to guide/automate the user in downloading an appropriate DLL from some other site. Besides, that would allow the user to pick some other SSL library, such as one of the optimized ones available commercially that may already be installed on their system. There is such a thing as being too concerned about "ease of installation." Finally, it should also be noted that the exception for Apache ONLY applies to non-commercial distributions. Any commercial distribution, even if it is simply Apache slapped onto a CD and sold for a buck, remains subject to the old US export controls that everyone hates, and must be approved via a separate process. ....Roy