From: Bruce S. <Bru...@nc...> - 2005-05-17 01:27:31
|
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 |