From owner-cvs-all@FreeBSD.ORG Sat Aug 7 17:25:14 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A672F16A4CE; Sat, 7 Aug 2004 17:25:14 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D6943D2D; Sat, 7 Aug 2004 17:25:13 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i77HPBGW016092; Sat, 7 Aug 2004 18:25:12 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i77HPB4f016091; Sat, 7 Aug 2004 18:25:11 +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])i77HLAtp075156; Sat, 7 Aug 2004 18:21:10 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200408071721.i77HLAtp075156@grimreaper.grondar.org> To: Paul Richards From: Mark Murray In-Reply-To: Your message of "Sat, 07 Aug 2004 15:04:25 BST." <1091887464.826.45.camel@myrddin> Date: Sat, 07 Aug 2004 18:21:10 +0100 Sender: mark@grondar.org cc: src-committers@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG cc: Colin Percival cc: cvs-all@FreeBSD.ORG cc: Colin Percival cc: Mark Murray 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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2004 17:25:14 -0000 Paul Richards writes: > > Not offhand, but our company lawyers OKed it. > > I'm only reporting what I was told by a UK FreeBSD user who was > investigating whether they needed an export license for their FreeBSD > based product and they thought I'd be interesed in knowing that it was > still a grey area. Not grey; crystal clear. If the product's web site has a downloadable copy of the cryptographic stuff available for public download, you don't need to license. If the cryptographic code is in some way _NOT_ available to the general public, you need to seek permission. Of course is the point of the product is not cryptography (say a print server), and you can separate out your non-cryptographic proprietary bits, then you are also clear "Get FreeBSD ${THERE}, install my stuff from ${HERE}". > For their product the fact that FreeBSD was bundled into an embedded > product meant that it was not considered to be an open source product > and therefore possibly needed an export license. Right. Unless you do the above separation. > If your company lawyers OKd your product then obviously it was ok, this > other company may subsequently find out their product is ok as well. > However, I think it would be dangerous to assume that a product based on > FreeBSD is automatically except. That is not the FreeBSD project's problem. > My subsequent reading of the DTI documents confirmed that while open > source software is exempt, cryptography per se is not. Therefore, if > your product contains cryptography then it has to satisfy certain > criteria in order to be exempt. One of those criteria is that it is in > the public domain which is why FreeBSD is ok, but an aggregated product > might not be. Well, you can spend you whole life going through double negatives like like the above, but basically if you declare to DTI that the cryptographic bits that you are using were "obtained off the internet from a place where the such crypto is freely available" AND "your proprietary bits don't use or implement cryptography", then you'll be safe. Of couse there is a rich (and to FreeBSD, irrelevant) field for finding all the nasty little edge cases this represents. M -- Mark Murray iumop ap!sdn w,I idlaH