So it appears that there is now a significant difference in the
treatment of source code and object code, even object code compiled
from open source already on the net. Am I correct?
If so, this could complicate the wholesale incorporation of crypto
libraries and applications as packages (e.g., .rpm and .deb files) in
binary Linux distributions. These binary distributions are very popular,
as they make it really easy for the neophyte to bring up Linux.
It would be nice to get a BXA ruling that treats object code compiled
from open source the same as the source itself. Barring that, I think
an expedient approach would be to distribute crypto applications and
libraries as packages containing, instead of the usual object code,
source code that is automatically compiled and installed on the target
machine by the package's installation script. This would slow down the
installation and introduce package dependencies on compilers and
header files, but it wouldn't have to change what the user sees and
does very much.
What about the "open cryptographic interface" provision? Would this
mean that any application that calls a crypto function would also have
to be distributed in source code that gets compiled during
installation? We'd have to be careful, or else the entire "binary"
Linux distribution would consist of source code plus compilation
scripts, and installation could take quite a bit longer than it does
now.
Phil
