[6985] in cryptography@c2.net mail archive
Re: Java Crypto Library Licenses
daemon@ATHENA.MIT.EDU (Greg Broiles)
Tue May 2 16:09:39 2000
Message-Id: <4.3.2.20000502075619.00b066f0@speakeasy.org>
Date: Tue, 02 May 2000 08:29:38 -0700
To: hershey@eyeshake.com, cryptography@c2.net
From: Greg Broiles <gbroiles@netbox.com>
In-Reply-To: <390DFEF3.602AA5EF@eyeshake.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 03:02 PM 5/1/00, Mark A. Herschberg wrote:
>The only thing I find harder than crypto is trying to understand
>software licenses and export laws.
>
>I am building a commercial product. Sun's JCE (as well as JAAS and JSSE)
>all have non-commercial licenses, which I understand to mean as: I can't
>use them in a commercial product.
>
>http://java.sun.com/products/jce/jce12_providers.html lists companies
>providing crypto services and clean room implementations.
>
>1. Am I correct that a clean room implementation, such as one at
>http://www.openjce.org/ can be used in place of Sun's JCE? Such that I
>could interchange the two modules and my code written to the JCE API
>will work in either case (modulo bugs).
>
>2. Just as important, am I understanding their public license
>(http://www.openjce.org/licence/PUBLIC_LICENCE) correctly to mean that I
>can freely use their software in our product?
I haven't read their license; but they're probably giving you a license to
use their copyrighted code, but not a patent license for other people's
(e.g., RSA or Certicom) patents. You should consider patents and copyrights
separately when trying to figure out licensing. The RSA patent is still in
force until Sep 20 of this year.
>3. Being that we are a US company (we write code in the US), and this
>(the clean room JCE) was done in Australia, and we're marking in Asia,
>how can we figure out what export laws are applicable? (We have
>lawyers, but its always cheaper to do some initial leg work.)
US software export control law governs the transfer of software or
information about software from US persons to non-US persons, and the
subsequent transfer and use of that software/information. If your
development or production environment depends on that activity - e.g., a US
person transfers code or knowledge about code to a non-US person; and that
code provides information-hiding functionality, then you probably need to
think about export control. The export control regime became less onerous
recently, but hasn't withered away entirely.
Also, Australia has historically had some funny rules about crypto export,
depending on whether or not the information leaves Australia over a wire
(not regulated) or on disk (regulated). You may need to consider the import
and export restrictions of every country you're touching, not just the U.S.
I've redirected this to cryptography@c2.net, as it's not about writing code.
