> Additionally, he has failed to define "security". The definition is dependend of the software. So there can't be a perfect definition for all matters in the license. Perhaps in not obvious (means: very special) cases, there should be a separate definition of security included in the package. But I think there is a good common sense about security. And even if not, I would recommend a good book of computer security if you really have any doubts about the meaning of computer security.
> The traditional > definitions include any number of properties that must be enforced > togeather in order to insure some level of trustability as absolute > trustability is not acheivable with current methods and technology. I usually think on other definitions. Simple speaking e.g. the protection against risks. Your "definition" for security is very special which covers only an aspect of security and is therefor definitively not "traditional". BTW: Where does your "definition" come from? But as stated above: This depends on the needs of the software. > Think > about it, if a system is misconfigured, do you loose your license even if > the core software is "secure"? If it is an intended "misconfiguration" then yes, you lose - strictly speaking - your license. Normally critical software should assist you in this matters, so there should be no obvious misconfiguration. S1 depends on the intention of the user. Perhaps it should better read "You may not INTENTIONLY violate the security..." but thats somewhat redundant and to strict because that would change the argumentation for the proof of intention to the side of the author. Just to quote an expert on computer security: "Security is a process, not a product." (Bruce Schneier) Thats what intended. You should USE it secure. The license just tries to prevent misuse. > Also, given the language in S4, does it > imply that when you better learn to secure an environment that you are > compelled to do so for the system in which this code is running or you'll > loose your license? Is your best course of action then to remain ignorant? Yes, good point. I had this concern when I was including this passus. I'll try to explain it below. > Failing to outline what "security" means and what to breach it means should > be enough to clobber this license as proposed. You're free to post a better solution. To my knowledge this is the first attempt anyone is including real security matters into a license. So it's very likely it's not perfect at the first attempt. > It is overly vague and puts > onerous and un-meetable restrictions on the user as the definition of what > is secure is necessarialy dependant on security target, installation > environment, and configuration. What do you mean by "onerous and un-meetable restrictions on the user"? Please be more specific on this point. > Even more onerous than this, to my mind, is the requirement of a "secure > processing environment" this is verifiable. S4 seems to imply that all > designs from the UART design on up of the system must be public. What is an "UART design"? All abbreviation I know for "UART" is "universal asynchronous receiver-transmitter". But how should the "universal asynchronous receiver-transmitter" interfere with e.g. GnuPG? A "secure processing environment" is everything which could interfere with the correct and secure processing of the software which is released under the PSI license. And overall it is relaxed to "your best knowledge". So I really don't see a big problem here. E.g. for GnuPG under Linux: The "secure processing environment" is usually the CPU, RAM, Operating System and maybe drivers. > This is > not practicable in most non-governmental environments. Thats why it is relaxed to "your best knowledge": You only _need_ to know that there are no obvious flaws. Like an kernel exploit flooding the security mailinglists. ;-) You don't need to toast your own CPUs or design your own mainboard... The second point about "must be public" is quite similar: S4 says "However the processing environment must be verifiable by you or by the public. So source code or construction principles of the processing environment must be known." Look at "by you or by the public": This doesn't mean e.g. that _all_ construction principles of the CPU must be known to public. Instead it is like PGP's web of trust: If its a mass product it's very unlikely you can be cheated with a "special" CPU. But if many people have the same CPU and many experts test various aspects of the CPU, many flaws go to public. (e.g. the "famous" Pentium FP bug). So it gets more likely you aren't cheated. Thats what is meant by "by you or by the public". And all normal and really relevant data is usually published by the manufacturer. E.g. Intel and AMD have large and helpful (technical) information online and usually give good responses to questions. Therefor I don't see a real problem with your achievements. If you have any other concern, please let me know. Wolfram -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
