[Edu-sig] UPDATE: High School Network Security

[Laura Creighton]

They just hate Open Source.  And they are unwilling to examine projects
on a case-by-case basis.

In a message of Mon, 16 May 2005 11:00:27 PDT, Frank Noschese writes:
>Hello again,
>
>Thanks to everyone that gave input to my Vpython installation roadblock. 
>Like
>Arthur said, this is not a situation which will be fixed by a little
>"education." I asked the tech coordinator to outline the reasons why inst
>alling
>open source is not in the school's best interest. Here is the reply:
>
>=======
>"In Reference to our ticket #313, there are a number of reasons why we (t
>he
>technical team) decided that it would not be in keeping with the "best
>practices" of the district to install open source software on the distric
>ts
>computers and network. Four key reasons are as follows:
>
>1) Lack of technical support from the 'vendor'. Since most open source so
>ftware
>is provided 'free' and is not maintained by a central vendor, technical s
>upport
>is limited if not non existent. With this lack of technical support of th
>e
>software products in question, we have no way of getting help when the so
>ftware
>has a problem or is the cause of problems with the network.

This is, of course, not true for Python.  If you want a support license,
you can talk to, among others, ActiveState.  Actually, my experience with
open and closed source products is that the Open Source developers are
more responsive to bug reports.  Closed source places have to justify 
the time spent on a bug fix with the revenue it generates. Unless you are
an _important_ customer, you can wait a long time.

>
>2) Product testing was another reason. Since there are so many contributo
>rs to
>open source software, in many cases, the software is not tested for
>compatibility and stability. As such, there is no level of expectation th
>at the
>product will function as stated. Further more, with the limited testing o
>f the
>software, we have no idea of what problems or ill effects the software ma
>y have
>on the computers and network.

Python is well tested.

>
>3) Legal issues. According to the American Bar Association, Contributors 
>do not
>vouch for the cleanliness of the code they contribute to the project; in 
>fact,
>the opposite is true -- the standard open source license is designed to b
>e very
>protective of the contributor. The typical license form does not include 
>any
>intellectual property representations, warranties or indemnities in favor
> of
>the licensee; it contains a broad disclaimer of all warranties that benef
>its
>the licensor/contributors. Seeing in that there is no way for us to verif
>y that
>the code that contributors are adding is there own, we may be opening up 
>the
>district to legal actions should the software or portions there of are
>copyrighted and being used illegally or improperly. See attachment for mo
>re
>detail...

This is misleading. Python contributers state that they have the right
to contribute this code (ie it is their's or their company's and they
have the right to represent their company). According to our lawyers,
no amount of ABA sanctioned yapping about indemnification will do
anybody a piece of good if some third party wakes up one day and says
that the python langauge is in violation of their patent.  In this
case, the contributor, the Python Software Foundation, and all the
Python users will all be sitting on one side of the fence, as some
jerk -- usually a corporation -- tries to extort money out of us.
This could happen.  However, this is merely a reflection of why patents
are bad for software, and this could happen should you use a piece of
closed source software that somebody claims violates their patent as well.

>
>4) Security of the "system." Since in most cases, anyone can obtain a cop
>y of
>the source code of the software (OPEN SOURCE), we are running the risk of
> a
>user being able to modify the software on the network and manipulated it 
>in
>such a manor to produce undesired effects. Since we have to look out for 
>the
>stability and security of the network, this was viewed as a possible secu
>rity
>issue. Another security concern is the ability of virus introduction. Sin
>ce the
>source code is open, anyone so inclined, could create a virus to exploit 
>the
>software without much difficulty. This ability to introduce a virus or ot
>her
>malicious code to the system can have the effect of bringing the system "
>down"
>and possible data loss or corruption."
>===========

Here they are confusing 'the software is open source' with 'we have
to install it on our system in a way that anybody can modify it'.  This
is simply not true.  So, if some cracker find a way to replace parts
of your python with his or her own files -- yes, that is a problem.
But it is a worse problem for Microsoft, because most of the people
who do this are brainless fools who download a 'cracking kit' and 
do whatever it says, and most cracking kits are for Windows.  Once
you have an operating system that will install whatever the cracker wants
wherever he or she likes, you have a severe problem.  But this is not
a Python problem, either.

The university here, where this is a severe problem, just reinstalls
all the system software every week, or 3 days on systems that have
proven to be regularly cracked.


>Also included in the email was information from the American Bar Associat
>ion
>at: <http://www.abanet.org/intelprop/opensource.html>
>
>Any thoughts from you folks? Do they have any truly valid points? Perhaps
> a
>"Live CD" is my best (only?) option.

This is the standard 'why open source is evil' misinformed rant.  Most
people who say this do not actually believe it.  It is just a club to
beat people like you with so they can continue to have things the way
they like it.  You are supposed to believe them and go away.

Good luck,
Laura Creighton

>
>Many thanks again,
>Frank Noschese
>John Jay High School
>Cross River, NY
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig