> I took the initial view that closed source and trustable > crypto are mutually incompatible
Of course this isn't true. When is the last time you built your own ATM or credit-card POS terminal? > Claims such > as "Download this app and you will be secure" should definitely need to > be proven, and if the app is built with TLS++ that would mean > distributing the source code. That's not enough. Are you validating the toolchain? (See Ken Thompson's Turing Aware lecture on trusting trust). Are you going to prevent users from storing private keys in world-readable files? Think very carefully before you make *any* claims about what features your software will provide, and what is necessary to truly ensure those features. Are you planning on taking real liability here? That would be a first in the software world. > I don't want to restrict the distribution of TLS++, but I > also don't want crippled versions of it being used to fool the public. Do you really think that someone who wants to fool the public will be deterred by a LICENSE.txt file in an open source distribution? > If anyone could help me to outline a reasonable possibility....? I think that rather than spending time on deciding what to call this library that is to-be-written, and how to license this library that is to-be-written, that time should be spent on, well, writing it. :) /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]