For Approval: Public Security Interrest "PSI" License
xenonfs at users.sourceforge.net
Wed Sep 17 13:10:50 UTC 2003
> 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
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.
> 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
> 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
> 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
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
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
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.
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss