visualpython-users

[Visualpython-users] Re: [Edu-sig] UPDATE: High School Network Security

[Arthur <ajs...@op...>]

Chuck Allison wrote:

>Hello Frank,
>
>Some of the reasons cited below from your tech coordinator certainly
>make sense, but not for the classroom. Businesses rightly are
>concerned about vendor support, adequate testing, standards
>conformance, etc. - it can make a big difference in costly projects.
>  
>
Part of the problem is structural, in a duely perverse way.  In many
institutional settings the approval process in linked to the procurement
process.  If there is no need to undertake a procurement process (it's
free) there is nothing to which to attach an approval process. Approval
is therefore an impossiblity.

But - again - simply pointing this out and expecting someone to put palm
to forehead, and exclaim "of course -  our system does not make sense in
this regard, thanks for pointing that out. we will endeavor to change 
it" - is not what we are going to get.  Promise.

>But in small, informal classroom use, a teacher who knows Python can
>give all the "support" that's needed. Fortunately at my college, I can
>just tell the students to download whatever software and use it (they
>all have their own computers - and I have it placed on our lab
>computers as well - we have no bureaucracy to stop it - the IT people
>are there to support the faculty, not impede them). Over-cautious
>IT policies should not stand in the way of educating. Educating
>bureaucrats in such separation of concerns is certainly in order.
>  
>
We have what we called in my day the AV (for audio-visual) department
setting policy for physics teachers.

Absurd as that it, it is a new reality of our new age.

With the additional development that Headquarters has taken a new 
interest in the policies of the AV department.

Art

[Visualpython-users] UPDATE: High School Network Security

[Frank N. <fra...@sb...>]

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 installing
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 (the
technical team) decided that it would not be in keeping with the "best
practices" of the district to install open source software on the districts
computers and network. Four key reasons are as follows:

1) Lack of technical support from the 'vendor'. Since most open source software
is provided 'free' and is not maintained by a central vendor, technical support
is limited if not non existent. With this lack of technical support of the
software products in question, we have no way of getting help when the software
has a problem or is the cause of problems with the network.

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

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 be 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 benefits
the licensor/contributors. Seeing in that there is no way for us to verify 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 more
detail...

4) Security of the "system." Since in most cases, anyone can obtain a copy 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 security
issue. Another security concern is the ability of virus introduction. Since 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 other
malicious code to the system can have the effect of bringing the system "down"
and possible data loss or corruption."
===========

Also included in the email was information from the American Bar Association
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.  How is this created?

Many thanks again,
Frank Noschese
John Jay High School
Cross River, NY

Re: [Visualpython-users] UPDATE: High School Network Security

[Bruce S. <Bru...@nc...>]

Frank Noschese wrote:
> 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 installing
> 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 (the
> technical team) decided that it would not be in keeping with the "best
> practices" of the district to install open source software on the districts
> computers and network. Four key reasons are as follows:
> 
> 1) Lack of technical support from the 'vendor'. Since most open source software
> is provided 'free' and is not maintained by a central vendor, technical support
> is limited if not non existent. With this lack of technical support of the
> software products in question, we have no way of getting help when the software
> has a problem or is the cause of problems with the network.

Technical support of commercial products is often rather poor. Given the 
large community of collaborators on large open source projects such as 
Python, it is possible that effective technical support may be better, 
not poorer. Minor case in point: Yesterday I asked for volunteers to 
step forward and help with getting VPython to run on the new Mac OSX 
10.4. Almost immediately Aaron Titus stepped forward with advice, which 
is now on vpython.org, and it looks like others are actively pursuing 
ways to simplify installation.

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

There's no generally valid rule here, but in many cases there is more, 
and more open, testing of open source software, due to the open nature 
of the user community. What do you really know about the problems with 
Microsoft Word, beyond the random inputs from your colleagues about the 
many problems with it? Can you inspect the bug reporting and tracking 
presumably maintained by Microsoft?

> 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 be 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 benefits
> the licensor/contributors. Seeing in that there is no way for us to verify 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 more
> detail...

I guess I can see that this could be a problem. The scenario is that I 
steal some graphics code from some proprietary or patented environment, 
submit it to enhance some open source project, the gatekeeper accepts 
it, and now that software is contaminated. But is it the end users who 
would be subject to prosecution, or me?

However, having read the ABA document, it expresses concerns about a 
company building software on an open-source base, only to find that they 
have inadvertently infringed a copyright or patent. This is a very 
different set of issues than those for a school system USING open-source 
software.

> 4) Security of the "system." Since in most cases, anyone can obtain a copy 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 security
> issue. Another security concern is the ability of virus introduction. Since 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 other
> malicious code to the system can have the effect of bringing the system "down"
> and possible data loss or corruption."

This is just plain confused. In secure Windows environments Python and 
VPython live in a protected space that users can't modify. So after 
administrative installation of Python/VPython, no one without 
administrative permissions can change the software. Users write programs 
and store them in "My documents".

It is true that I could submit a virus or security threat to be included 
in an open source project, and the gatekeeper could fail to realize the 
danger and include it. But the community would fairly quickly identify 
the problem.

Bruce Sherwood

> ===========
> 
> Also included in the email was information from the American Bar Association
> 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.  How is this created?
> 
> Many thanks again,
> Frank Noschese
> John Jay High School
> Cross River, NY

Re: [Visualpython-users] UPDATE: High School Network Security

[Gary <pa...@in...>]

Bruce Sherwood wrote:

> Frank Noschese wrote:
>
>> 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 
>> installing
>> 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 (the
>> technical team) decided that it would not be in keeping with the "best
>> practices" of the district to install open source software on the 
>> districts
>> computers and network. Four key reasons are as follows:
>>
>> 1) Lack of technical support from the 'vendor'. Since most open 
>> source software
>> is provided 'free' and is not maintained by a central vendor, 
>> technical support
>> is limited if not non existent. With this lack of technical support 
>> of the
>> software products in question, we have no way of getting help when 
>> the software
>> has a problem or is the cause of problems with the network.
>
>
> Technical support of commercial products is often rather poor. Given 
> the large community of collaborators on large open source projects 
> such as Python, it is possible that effective technical support may be 
> better, not poorer. 

Oh yes.  Case in point:  I used to use Mathcad (ten years ago ... things 
are probably different there now).  Most of my calls to tech support 
were answered with "You can't" or "That's just the way it works".  If I 
"call tech support"  for vpython or scipy or matplotlib, chances are 
that 1.) I'll get an answer  2.) If it's a bug it will get fixed within 
days if not minutes 3.) If it's a new feature it might show up in days 
if not minutes.

But everyone reading this already knows all that ...

Re: [Visualpython-users] UPDATE: High School Network Security

[Gary <pa...@in...>]

>
>Any thoughts from you folks? Do they have any truly valid points? Perhaps a
>"Live CD" is my best (only?) option.  How is this created?
>  
>
Not trivial, but not impossible.  I'm assuming that there is no current 
live CD that includes vpython.  I'm not aware of any, but that's about 
to change (see below).

The issue is that you can't install new software in the same way that 
you do on a hard drive installation.  You can't write to the live CD 
file system.  So new software has to  be installed somewhere else ... a 
flash drive, or an external USB hard drive or something.  In any case it 
means installing in a non-standard location.  That means a certain 
amount of education, work, and tweaking.  In the case of vpython (and 
any other python package) it might be straightforward since it is fairly 
easy to maintain a local site-packages directory.   (Assumes all the 
other requirements are met).

Better:  vpython is scheduled to be included in the next version of 
Quantian  ( http://www.quantian.org ) 

Quantian includes just about every piece of scientific software that you 
could ever want or even imagine.

-gary

[Visualpython-users] UPDATE: High School Network Security

[Frank N. <fra...@sb...>]

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 installing
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 (the
technical team) decided that it would not be in keeping with the "best
practices" of the district to install open source software on the districts
computers and network. Four key reasons are as follows:

1) Lack of technical support from the 'vendor'. Since most open source software
is provided 'free' and is not maintained by a central vendor, technical support
is limited if not non existent. With this lack of technical support of the
software products in question, we have no way of getting help when the software
has a problem or is the cause of problems with the network.

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

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 be 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 benefits
the licensor/contributors. Seeing in that there is no way for us to verify 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 more
detail...

4) Security of the "system." Since in most cases, anyone can obtain a copy 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 security
issue. Another security concern is the ability of virus introduction. Since 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 other
malicious code to the system can have the effect of bringing the system "down"
and possible data loss or corruption."
===========

Also included in the email was information from the American Bar Association
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.

Many thanks again,
Frank Noschese
John Jay High School
Cross River, NY

[Visualpython-users] Re: [Edu-sig] UPDATE: High School Network Security

[Laura C. <la...@st...>]

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
>Ed...@py...
>http://mail.python.org/mailman/listinfo/edu-sig

[Visualpython-users] Re: [Edu-sig] UPDATE: High School Network Security

[bill p. <pa...@ex...>]

The other day I came across a discussion of the Brazil government efforts to
mandate open source.

Here is one news brief
http://msnbc.msn.com/id/7220913/
covering MIT's recommendation to the Brazil government endorsing open source.
This is probably something to follow in the educational field as there will
certainly be a lot of concrete experience with open source from this process.
You can Google for more examples.

regards,

bill p



Laura Creighton wrote:

> 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
> >Ed...@py...
> >http://mail.python.org/mailman/listinfo/edu-sig
> _______________________________________________
> Edu-sig mailing list
> Ed...@py...
> http://mail.python.org/mailman/listinfo/edu-sig

Re: [Visualpython-users] Re: [Edu-sig] UPDATE: High School Network Security

[Bruce S. <Bru...@nc...>]

My posting crossed Laura Creighton's in the mail, and I'm struck by how 
very similar our responses were to all the issues. Doesn't guarantee 
that either of us is right, but we might be.

Bruce Sherwood

[Visualpython-users] Re: [Edu-sig] UPDATE: High School Network Security

[Jordan J. <jor...@cs...>]

On Monday, May 16, 2005, at 11:00  AM, Frank Noschese wrote:
> 4) Security of the "system." Since in most cases, anyone can obtain a 
> copy 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.
         ^^^^^

Aha, so that's what this is really about--a threat to the manor!

jmj

--
"In this era of big brains, anything that can be done will be done - so 
hunker down." -- Kurt Vonnegut

[Visualpython-users] RE: [Edu-sig] UPDATE: High School Network Security

[Kirby U. <ur...@qw...>]

> Any thoughts from you folks? Do they have any truly valid points? 
> Perhaps a "Live CD" is my best (only?) option.
> 
> Many thanks again,
> Frank Noschese
> John Jay High School
> Cross River, NY

Maybe the policy should stay as is.  

We in Oregon like the competitive advantage this sets up.  Having New York
shoot itself in the foot, and be righteous about it (even citing Bar
Association stuff -- sheesh), is a happy development.  

If, as an individual teacher, you get tired of these working conditions,
consider moving.  We're less of a slave ship out here.  And by the looks of
it, we treat our kids better too.

Kirby

Re: [Visualpython-users] UPDATE: High School Network Security

[Andrew D. <dou...@la...>]

On Mon, 16 May 2005, Frank Noschese wrote:

> 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 agree.  Although you'll need facts in hand, you'll probably also need a 
higher-up ally -- someone who has the authority to have the IT folks 
re-examine the issue.

Bear in mind that computer and network security are quite important, 
especially if student records are kept on the same network.  (Ideally, 
academic and administrative networks should be cleanly separated, but in 
practice I'll bet they often aren't.)  If a compromise of the computer 
network could result in the leaking of private student data, then network 
administrators indeed should be paranoid.

Nevertheless, the computer system is there to serve the educational 
mission of the school, not the other way around, so if there are strong 
educational reasons to install a particular software package, then that 
package deserves an honest test and evaluation based on it's individual 
importance, track record and performance under testing.  Of course, the 
tech department probably doesn't have enough staff to adequately do that, 
so it may prove difficult to get anything done in a timely fashion.

For the most part, the tech coordinator's reasons apply to both open 
source and non-open source software (I give details below).  I'd expect 
him or her to want to carefully test *any* software before installing it 
on the network, but if it passes that testing, I fail to see why it 
couldn't be used.

Hmm.  Would the tech coordinator be happier if you bought a version of 
Python from Activestate  ( http://www.activestate.com ) ? 

Here are some detailed thoughts, drawn in part from my long-time 
involvement in Open Source software:

>  I asked the tech coordinator to outline the reasons why installing
> 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 (the
> technical team) decided that it would not be in keeping with the "best
> practices" of the district to install open source software on the districts
> computers and network. Four key reasons are as follows:

> 1) Lack of technical support from the 'vendor'.

True, there's no guaranteed technical support.  But that's not unique to 
Open Source software.  I have plenty of commercial software that has no 
technical support (for example, the company has gone bankrupt, or our 
support license expired, etc.)  Other software supposedly has commerical 
support, but it's worse than useless.  (By that, I mean you waste a lot of 
time only to run into a brick wall at the end anyway.)

There ought to be a way to get software installed "unsupported".  That is, 
the tech department would not be responsible for handling calls related to 
the use of the software.

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

That's true for much commercial software as well, particularly the more 
specialized software used by particular academic disciplines.  I could 
cite numerous examples if needed.  All software installed on your school's 
network should be tested to make sure it works there.

> 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 be 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 benefits
> the licensor/contributors. Seeing in that there is no way for us to verify 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 more
> detail...

If this applies at all, it applies equally to both Open Source and 
proprietary software.  Most software comes with similarly broad 
disclaimers.  For example, both commercial and open source "vendors" had 
to deal with the issues surrounding the Unisys LZW compression patent.
End users such as school districts were not held responsible.

> 4) Security of the "system." Since in most cases, anyone can obtain a copy 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.

This is just wrong.  The copy on the network can't be modified unless it 
is installed improperly or the network is configured incorrectly.  
Whether or not a copy on the network can be modified is independent of 
whether or not the original product was open source.  If users are able to 
modify installed software, then all software installed on the network is 
at risk.  This has nothing to do with whether or not it is open source.

Security of a system is indeed an appropriate concern.  It is quite 
appropriate for the tech coordinator to evaluate the security risks of any 
software being installed on a network.  However, that evaluation should be 
based on the track record of the particular software as well as the 
relative importance of that particular software to the overall mission of 
the institution.  For example, many places still allow the use of 
Microsoft Outlook and Internet Explorer, judging that their usefulness 
outweighs the security issues.

>  Another security concern is the ability of virus introduction. Since 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 other
> malicious code to the system can have the effect of bringing the system "down"
> and possible data loss or corruption."

The phrase "without much difficulty" is not justified, and not probably 
applicable to Python.  Though this is a valid theoretical concern, it 
needs to be backed up by an actual examination of the particular software 
in mind. Judging from the incidences of actual viruses, it's probably much 
easier to infect Outlook Express or Internet Explorer than it is to infect 
Python.

In short, I think that the blanket rejection of open source software is 
based on false assumptions and is bad policy.  But it's also policy that 
it may be difficult (politically) for you to do anything about -- after 
all, you may have to work with these folks for years to come.

> Any thoughts from you folks? Do they have any truly valid points? Perhaps a
> "Live CD" is my best (only?) option.

I can't imagine that suddenly booting up a lab full of Linux workstations 
would go over much better with the tech coordinator :-).  I don't 
understand Windows installation issues enough to know if one could build 
an entire Python + Vpython tree on a CD and just run that, but that's 
probably the direction I would head first.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042

[Visualpython-users] Re: [Edu-sig] UPDATE: High School Network Security

[Jordan J. <jor...@cs...>]

Possible responses follow.

On Monday, May 16, 2005, at 11:00  AM, Frank Noschese wrote:
> 1) Lack of technical support from the 'vendor'. Since most open source 
> software
> is provided 'free' and is not maintained by a central vendor, 
> technical support
> is limited if not non existent. With this lack of technical support of 
> the
> software products in question, we have no way of getting help when the 
> software
> has a problem or is the cause of problems with the network.

"I am willing to accept the responsibility of being the local support 
provider for this software.  Among other sources of support, be aware 
of [list mailing lists and websites here]."

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

"The functionality of many open source software, and Python in 
particular, is documented openly, and as such, errors are usually easy 
to find and then avoid.  It is worth noting that recent versions of 
Internet Explorer and Mac OS X have had serious security problems of 
their own; this problem is far from unique to open source."

> Seeing in that there is no way for us to verify 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.

"Usage of the software is, or should be, governed by our own Acceptable 
Use Policy.  Also, given that we are not redistributing the software or 
marketing a derivative work, we will be extremely unlikely to draw 
legal attention even if this software is found to contain infringing 
code.  Many major academic institutions (such as the University of 
North Carolina, Indiana University, and UC Berkeley) participate in the 
redistribution of Python and other open source software, which strongly 
suggests that their legal counsel does not find the practice risky or 
objectionable."

> 4) Security of the "system." Since in most cases, anyone can obtain a 
> copy 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 
> security
> issue. Another security concern is the ability of virus introduction. 
> Since 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 
> other
> malicious code to the system can have the effect of bringing the 
> system "down"
> and possible data loss or corruption."

Left as an exercise for the reader.  (A probably-unhelpful answer would 
involve something like, "If you're worried about a threat from this 
software, you have bigger problems." :>)

Cheers,
jmj (who did rather well fighting the IT bureaucracy at his own high 
school)

: Jordan Johnson - jorjohns @ cs . indiana . edu
: If I were a bug, I would want to be a true Renaissance bug.