For Approval: Public Security Interrest "PSI" License

[Wolfram Kleff]

> 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