-----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 [EMAIL PROTECTED] 22 Feburary 2007 - ---- Thanks in advance, Dererk - -- [EMAIL PROTECTED]: ~$ 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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]