Please use reply-to-all

shervin soltani wrote:
> The EULA prohibits doing so: "4. Except as otherwise expressly
> provided under this EULA, You shall not, and shall not allow any
> third party to: (c) copy (except to make a single back-up copy to
> replace an unusable copy of the Software Product), modify, prepare
> derivative works based upon, decompile, decrypt, reverse engineer or
> attempt to reconstruct or discover any source code or underlying
> ideas or algorithms of the Software Product by any means whatsoever
> (except to the extent applicable laws specifically prohibit such
> restriction), disassemble or otherwise reduce the Software Product to
> human-readable form to gain access to trade secrets or confidential
> information in the Software Product;"
> 
> Which I would guess includes whatever keys they are using to lock the
> fingerprint reader. As I understand the license, I would be allowed
> to use it in a "product" to incorporate support for the fingerprint
> reader (so the EULA would seem to allow its usage in something like
> libfprint). However, if I understand the LGPL 2.1 correctly, which is
> extremely difficult given its verbosity, one could use the LGPL'd
> work in a non-(L)GPL program/library, but not the other way around.
> 
> So the point is moot. To add support for this particular breed of
> fingerprint scanner, one needs to reverse-engineer then rewrite the
> method they use to unlock it in the first place. That's prohibited by
> the EULA, and using a proprietary library with LGPL ain't possible.

Reverse engineering is more-or-less permitted by law depending how it is 
done and the intention it is done under, but in this case I am 
suggesting that you start by bus traffic analysis. This doesn't involve 
looking at anything owned by UPEK and is only called "reverse 
engineering" at a stretch, instead you are just watching the traffic 
that goes over the wire.

Bus traffic analysis may lead to complications (for example, your 
analysis may indicate that key-based encryption is being used) in which 
case further steps need to be taken before we have a working driver... 
but the clearly-legal bus traffic analysis needs to happen first.

And even then, including "secret vendor keys" with fprint is not a 
problem provided that they have been reverse engineered in an acceptable 
manner. See dpfp.c and 
http://www.reactivated.net/weblog/archives/2007/12/libfprint-v005-supports-new-ms-hardware/

I have previously obtained legal advice on this topic and am happy to do 
so again, should the need arise.

Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint

Reply via email to