Date: Sat, 07 Aug 2004 18:21:10 +0100 From: Mark Murray <markm@FreeBSD.ORG> To: Paul Richards <paul@originative.co.uk> Cc: Mark Murray <markm@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 ... Message-ID: <200408071721.i77HLAtp075156@grimreaper.grondar.org> In-Reply-To: Your message of "Sat, 07 Aug 2004 15:04:25 BST." <1091887464.826.45.camel@myrddin>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408071721.i77HLAtp075156>