Exporting Issues related with US laws
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello there!
I would like to ask you for help again, now with something it has been
around in Debian a few years ago: US exporting laws.
The developer of a software I'm about to package, faced the problem of
exporting cryptography libraries outside the US, he finally turned out
his view and he will make his main repository available outside the
US, punctually in the U.K.
But now, the problem goes back to us, when having mirrors in the US,
mirroring outside the whole world.
I paste here the full paper in which the developer faces this
concern. (Link http://dpfp.berlios.de/wikka.php?wakka=ExportIssuesLegal)
Now, here are the questions, How does it affect us? What could we do?
- ----
Export control issues
/This is a copy of the document I am sending onto legal types in hope
of getting reliable advice on the situation here. For more general
info, see ExportIssuesFAQ
<http://dpfp.berlios.de/wikka.php?wakka=ExportIssuesFAQ>/
INTRO
libdpfp is a software project which aims to develop support for
fingerprint scanning and matching using hardware manufactured by
DigitalPersona
<http://dpfp.berlios.de/wikka.php?wakka=DigitalPersona/edit>. The end
result would mean (amongst other possibilities) that users are able to
optionally login with a fingerprint instead of, or perhaps in addition
to, their password.
The current libdpfp homepage is: http://dpfp.berlios.de∞;
These fingerprint scanners are only simple imaging devices. Any
analysis of the fingerprint images (e.g. to decide whether two prints
are from the same finger or not) must be performed on the host computer.
Therefore, to become a useful piece of software, libdpfp must
implement functionality for both downloading of images from the device
*and* performing comparison/matching operations on such images.
libdpfp is being developed as an open-source software project. In this
style, all source code for the software is released to the public with
no royalties. The licensing model for this software encourages users
to redistribute and modify the software and generally only implies
restrictions to preserve the "open" nature of the software. This
development model encourages transparency, high software quality, and
collaborative community-based development.
The license chosen for this software is the GNU Lesser General Public
License, version 2.1 (Feburary 1999). The exact license text can be
found at:
http://www.gnu.org/licenses/lgpl.html∞;
Under this model, the software is published in both source and binary
(compiled object code) forms on the internet. Downloads of this
software are unrestricted and the license does not place any
restrictions on the usage of the software. License acceptance is only
required for distribution (under copyright law you do not have any
distribution rights without the license).
libdpfp can be viewed as a prototype for a future software project of
increased scope. libdpfp is written specifically for one type of
fingerprinting hardware from one manufacturer, however there are many
other devices on the market which are currently not well supported on
open-source operating systems such as Linux and FreeBSD
<http://dpfp.berlios.de/wikka.php?wakka=FreeBSD/edit>. Once libdpfp is
usable for both image capture and fingerprint matching, I plan to
start a new project which will support a whole variety of fingerprint
readers on these operating systems.
As a sidenote, I am now in a position to start this new project,
however these legal concerns are barring both the publication of a
feature-complete version of libdpfp and any distribution of any new
project based on it.
I do not believe that I am currently in any trouble, as there have
been no fully-functional releases of libdpfp. Existing releases can
only download fingerprint images from the hardware and perform basic
enhancement, no fingerprint matching is offered at this time. I do
have fingerprint matching implemented locally but I do not plan to
distribute this new version until the legal issues are understood.
Although there have been a few other small code contributions, libdpfp
has been primarily developed by myself. All development has been
carried out in my spare time, and I don't expect to make any money
from this software. The only sponsorship received so far has been from
community members who have donated fingerprint readers to aid development.
POTENTIAL ISSUES WITH EXPORT CONTROL
The legal issues which I am concerned about are concerning US export
control regulations.
The most challenging part of libdpfp development has been developing
code to compare one fingerprint image with another. This is a larger
problem than it may sound, as the fingerprint images must be
considerably enhanced before any analysis can take place. After
analysis has been completed on both prints, the next problem is
deciding how the analysis results can be used to produce a comparison
between the images (i.e. a decision whether the images are of the same
finger or not).
While seeking solutions to these problems, I was directed towards
NBIS. NBIS is a collection of software utilities which analyze and
compare fingerprint images. NBIS is developed by the National
Institute of Standards and Technology (NIST). As it was developed by
employees of the Federal Government in the course of their official
duties, the software is uncopyrighted and in the public domain
(pursuant to title 17, section 105 of the United States Code). The
NBIS website is:
http://fingerprint.nist.gov/NBIS/∞;
Despite this software being public domain, NIST have identified that
there are restrictions on distribution of part of the NBIS suite due
to U.S. export control laws. You cannot download the entirity of NBIS
over the internet, you must request a CDROM to obtain a copy of the
fingerprint matching algorithms. Such algorithms are required for my
projects.
My understanding is that NBIS is not a special case: it is not subject
to these extra regulations because it is government-sponsored, and it
is not subject to these extra regulations because someone at NIST
decided it should be this way. U.S. export control laws apply to *all*
exports of any kind. If NBIS is subject to regulations which prevent
open distribution of the software over the internet, then it must be
due to the nature of the software and the functionality it provides.
My plan is to include parts of NBIS into libdpfp and the future
project. I believe that any regulations that apply to NBIS would
possibly apply to my project even if I did not include NBIS:
regardless of implementation, the project requires algorithms which
perform tasks similar or identical to those performed by NBIS.
EXPORT CONTROL INFORMATION FROM NIST
The NBIS website says:
The Export Control NBIS source code (NFSEG and BOZORTH3) is only
available on CD-ROM upon on request. It is our understanding that
NFSEG and BOZORTH3 fall within ECCN 3D980, which covers software
associated with the development, production or use of certain
equipment controlled in accordance with U.S concerns about crime
control practices in specific countries.
Please note that the above is only their 'understanding'. I get the
impression that they haven't obtained solid legal advice on this
issue, rather they are playing it safe by controlling distribution of
the sensitive parts.
RELATED ISSUES: OPEN SOURCE CRYPTOGRAPHIC CODE VS EXPORT CONTROL
I am not the first open-source software developer to face potential
issues with export control. The Debian project have historically been
aware of issues with exporting software which includes crytographic
functionality, and previously had a separate distribution system for
such software, which was hosted only outside of the US.
In 2001, the Debian project obtained legal advice on how they would be
able to merge their non-US distribution system with their 'core'
distribution system, hosted in the US but mirrored in various
countries worldwide. A detailed writeup of the issues and the legal
advice which was obtained in response can be found at:
http://www.debian.org/legal/cryptoinmain∞;
The freedesktop.org X.org project addressed the same issues in 2004. A
short writeup by Jim Gettys on the processes used there can be found at:
http://lists.freedesktop.org/pipermail/xdg/2004-August/004492.html∞;
While there are certainly some similarities here, I am not sure how
much the techniques used by those projects can be applied to my own.
These projects are able to export their software with relative ease
due to license exception TSU and the fact that this exception has a
section which specifically grants fairly flexible exportation of
cryptographic source code (section 740.13(e)).
I am also under the impression that section 740.13(e) is a fairly
recent addition to the EAR, it is encouraging to see that the Bureau
of Industry and Security were able to realise that the EAR was
hindering innovation and were able to do something about it.
There does not seem to be such an exception made for fingerprint
software, although a system based on 740.13(e) for fingerprinting
would be acceptable to me. It would also be feasible to implement
IP-based location checking as suggested in Debian's legal advice document.
GEOGRAPHICAL CONSIDERATIONS
I am currently living in the US under a non-immigrant visa. In
September 2007, I return to my home in the UK to complete my education.
One obvious solution to this problem may be to export NFIS2 to the UK
(perhaps even with an export license) and then continue development
there. This is assuming that the UK does not have comparable export
control regulations, a topic I have not researched.
There are disadvantages to this approach. Firstly, it means I cannot
develop a functional version of my software for several months,
whereas there is a lot of interest in this topic at this point in time
and I am really looking forward to getting it released. Secondly, it
simply passes the problem onto operating system distributions (such as
Debian GNU/Linux) who, if they decide to ship my software, would face
problems as it would involve them hosting the software as an open
download on their U.S. software mirror servers.
However, if export control issues do exist and are not immediately
avoidable, then some kind of hosting solely abroad would be acceptable
for the time being while we solve the larger problem. For example,
developing code from the US and upload it to a UK webhost would be an
acceptable start.
To conclude, I will repeat that I'm not completely sure if export
control regulations apply to my project (i.e. it's a volunteer
project, I'm not a business, the software isn't being sold - are there
exceptions?), but after carrying out the above research I have reason
for concern. There may be mistakes in the interpretations of export
control presented above. I am seeking legal advice to clarify what the
issues are, if any, and how I can avoid them in this scenario.
If we discover that the U.S. export control regulations will end up
hindering development and/or distribution of the software, then I am
certainly keen on doing what I can to see them fixed. I am confident
that I am in a good position to argue a case, as a I am volunteer
developer simply trying to make an open contribution to the
Linux/open-source community, a community widely regarded as a Good
Thing. I am also encouraged by the fact that section 740.13(e) solves
a very similar problem, and that the EAR has been changing/modernising
quite frequently over the last few years.
I would greatly appreciate any advice on this topic. In open source
style, I would like to publish any legal advice I do receive on the
internet, I'm sure it would help others in the future. If you would
prefer to keep correspondence private, then please state so.
Additionally, please state whether it is OK for me to name you and/or
your company as the provider of this advice.
/Daniel Drake
dsd@gentoo.org
22 Feburary 2007
- ----
Thanks in advance,
Dererk
- --
vlady@Melee: ~$ grep -ir 'power in your hands' /proc/
/proc/version: Debian GNUine Perception
BOFH excuse #295: The Token fell out of the ring. Call us when you
find it..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGydkUzqYvwbbBjiQRAo59AJ0ZCtiHOvZ+r6Mn5JQe8HTON5t+NACghlXB
N1/dZDYVybDpFLTvDmMPDTs=
=zrOK
-----END PGP SIGNATURE-----
Reply to: