From owner-cvs-src@FreeBSD.ORG Fri Aug 6 22:05:11 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63CC416A4CE; Fri, 6 Aug 2004 22:05:11 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6E5E43D4C; Fri, 6 Aug 2004 22:05:10 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i76M5Ajd013104; Fri, 6 Aug 2004 23:05:10 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i76M59SC013103; Fri, 6 Aug 2004 23:05:09 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i76M0tvk068161; Fri, 6 Aug 2004 23:00:55 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200408062200.i76M0tvk068161@grimreaper.grondar.org> To: Paul Richards From: Mark Murray In-Reply-To: Your message of "Fri, 06 Aug 2004 21:49:08 BST." <1091825348.17455.19.camel@myrddin> Date: Fri, 06 Aug 2004 23:00:55 +0100 Sender: mark@grondar.org cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: Colin Percival cc: Colin Percival cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/bin/ed Makefile src/gnu/usr.bin/cvs/cvs Makefile src/kerberos5 Makefile.inc src/lib/libfetch Makefile src/lib/libpam/libpam Makefile src/lib/libpam/modules/pam_krb5 Makefile src/lib/libpam/modules/pam_ksu Makefile ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2004 22:05:11 -0000 Paul Richards writes: > It doesn't however follow that FreeBSD is always exempt from export > controls because it might not be if your exporting it as a product, even > if that product is just FreeBSD on a CD. This is just plain incorrect. If it is Open Source, it is exportable. > We'll always need to support > the ability to build non-crypto releases so that it can be safely > embedded in products that don't need crypto without encumbering the end > product with a requirement for an export license. We have the ability to build a NOCRYPT _world_. For people building appliances, that is sufficient. But people building appliances have control over the whole manufacturing process, and the crypto-nature of the product is therefore up to them. Open-source the OS on their product; no problem. Make it closed source and deal with export conditions. The ability to build NOCRYPT _releases_ is irrelevant. M -- Mark Murray iumop ap!sdn w,I idlaH