http://docs.google.com/Doc?docid=0AV6h7KQIZVQFZGduOWY0cjRfMTZndHFoY3Zndw&hl=en
Group editing, aka, croudsourcing. Stan On Tue, Mar 9, 2010 at 12:00 PM, Brett Johnson <[email protected]>wrote: > I took Stanley's text below and formatted it... > > Pages match the original - hence the whitespace. > > > -- > Brett Johnson > [email protected] > > Stanley Brinkerhoff wrote: > >> Easier to read? >> >> State of Vermont >> Open Source Software and Open Standards >> Policy and Guidelines >> SOV - Open Source Software and Open Standards Policy >> Contents >> 1.0 Introduction >> >> ............................................................................................................................................ >> 3 >> 1.1 Authority >> >> ......................................................................................................................................... >> 3 >> 1.2 Purpose >> >> ............................................................................................................................................ >> 3 . >> 1.3 Scope >> >> .............................................................................................................................................. >> 3 >> This policy is applicable to all agencies and departments >> ................................................................... 3 >> 2.0 Policy >> >> ...................................................................................................................................................... >> 3 >> 2.1 Guidelines >> >> ....................................................................................................................................... >> 4 >> Appendix A: Definition of Open Source Software and Open Standards >> ....................................................... 6 >> Page 2 ofa >> . >> SOV - Open Source Software and Open Standards Policy >> 1.0 Introduction >> 1.1 Authority >> VSA 22 § 901 (1), authorizes the Department of Information and Innovation >> "to provide >> direction and oversight for all activities directly related to information >> technology and >> security in state government." >> 1.2 Purpose >> The purpose of this policy is to encourage departments and agencies to >> consider the >> use of open source software and proprietary software that incorporates or >> utilizes open >> standards when making decisions about procurement of software solutions. >> Open source software presents opportunities for agencies and departments >> to >> implement solutions without incurring the cost of acquisition and >> maintenance of . >> licenses that are generally required for proprietary software solutions. >> Therefore, >> agencies and departments should consider the use of open source software >> solutions >> and open standards as part of the procurement process. This generally >> means >> that an >> investigation of potential open source software solutions should be >> conducted prior to >> issuing a bid for proprietary software solutions, and that the use of open >> standards >> should be included as part of a bid for proprietary software solutions. >> Agencies and departments should also consider the use of open source >> languages, >> libraries, open development platforms and open protocols for the >> development >> of >> custom solutions. >> 1.3 Scope >> This policy is applicable to all agencies and departments. >> 2.0 Policy >> Open source software often has a lower initial cost as compared with >> proprietary >> software solutions, primarily because there is usually no direct charge >> for >> licenses. >> However, there may be additional costs related to the selection of an open >> source >> software solution. Therefore: >> a. Decisions on whether to utilize open source software should be made >> within the >> context of total cost of ownership. The total cost of ownership includes >> both fixed >> costs (direct purchases and licensing) and operational costs for support, >> testing, >> upgrades, maintenance and training. >> Page 3 ofS >> SOy - Open Source Software and Open Standards Policy >> b. Each agency and department should carefully review their business >> requirements for technology solutions as they consider new projects. >> c. The selection of any software solution, whether open source or >> proprietary, >> should be based on whether the proposed solution meets the business >> objectives of the department or agency. Agencies and Departments may be >> asked to document that they have vetted opportunities to consider open >> source >> software as part of the contracting process. >> 2.1 Guidelines >> • Because participation in the ongoing development and improvement of OSS >> is >> the underlying basis for the promotion of OSS solutions, departments and >> agencies should consider the extent to which they may wish to actively >> participate in development of OSS solutions that fall short of the project >> requirements for which the solution is used. >> • Requests for Proposals should require that software vendors clearly >> identify >> whether their solutions are fully functional using open standards and, if >> not, to >> specifically identify any proprietary or closed specification standards >> for >> which >> they do not support a fully functional open alternative. Departments may >> give >> preference to proprietary software solutions that implement open standards >> over >> proprietary solutions that do not and may include the degree to which a >> proprietary software solution utilizes open standards as part of the >> Request >> for >> Proposal evaluation criteria. >> • When scheduling the implementation of any new software solution, >> agencies >> and >> departments need to be careful not to interfere with or diminish the >> effective use >> of software solutions that have already been adopted. >> • While the adoption of most open source solutions usually does not >> involve >> payments for licenses, there are a number of different types of open >> source >> licenses that control how open source solutions may be used. Departments >> are >> advised to be aware of both the type of open source license and any >> requirements or restrictions that may be incorporated as part of the >> license. >> Since the licensing requirements can directly impact agency operations, >> consultation with the Attorney General's office prior to executing a >> license >> agreement for open source solutions is advisable. >> Page 40f8 >> SOV - Open Source Software and Open Standards Policy >> • The acquisition of open source solutions, as with any proprietary >> software, is >> subject to the contracting requirements of Bulletin 3.5. >> See Appendix A at the end of this document for a description of the >> distribution terms >> related to Open Source Software and Open Standards. >> Page 5 of8 >> SOV - Open Source Software and Open Standards Policy >> Appendix A: Definition of Open Source Software and Open >> Standards >> The distribution terms of open-source software must comply with the >> following criteria: >> 1. Free Redistribution >> The license shall not restrict any party from selling or giving away the >> software as a component >> of an aggregate software distribution containing programs from several >> different sources. The >> license shall not require a royalty or other fee for such sale. >> 2. Source Code >> The program must include source code, and must allow distribution in >> source >> code as well as >> compiled form. Where some form of a product is not distributed with source >> code, there must >> be a well-publicized means of obtaining the source code for no more than a >> reasonable >> reproduction cost preferably, downloading via the Internet without charge. >> The source code >> must be the preferred form in which a programmer would modify the program. >> Deliberately >> obfuscated source code is not allowed. Intermediate forms such as the >> output >> of a >> preprocessor or translator are not allowed. >> 3. Derived Works >> The license must allow modifications and derived works, and must allow >> them >> to be distributed >> under the same terms as the license of the original software. >> 4. Integrity of the Author's Source Code >> The license may restrict source-code from being distributed in modified >> form >> only ifthe license >> allows the distribution of "patch files" with the source code for the >> purpose of modifying the >> program at build time. The license must explicitly permit distribution of >> software built from >> modified source code. The license may require derived works to carry a >> different name or >> version number from the original software. >> 5. No Discrimination Against Persons or Groups >> The license must not discriminate against any person or group of persons. >> 6. No Discrimination Against Fields of Endeavor >> Page 60f8 >> SOV - Open Source Software and Open Standards Policy >> The license must not restrict anyone from making use of the program in a >> specific field of >> endeavor. For example, it may not restrict the program from being used in >> a >> business, or from >> being used for genetic research. >> 7. Distribution of License >> The rights attached to the program must apply to all to whom the program >> is >> redistributed >> without the need for execution of an additional license by those parties. >> 8. License Must Not Be Specific to a Product >> The rights attached to the program must not depend on the program's being >> part of a particular >> software distribution. If the program is extracted from that distribution >> and used or distributed >> within the terms of the program's license, all parties to whom the program >> is redistributed >> should have the same rights as those that are granted in conjunction with >> the original software >> distribution. . >> 9. License Must Not Restrict Other Software >> The license must not place restrictions on other software that is >> distributed along with the >> licensed software. For example, the license must not insist that all other >> programs distributed >> on the same medium must be open-source software. >> 10. License Must Be Technology-Neutral >> No provision ofthe license may be predicated on any individual technology >> or >> style of interface. >> Open Standardsl >> 1. Availability: Open Standards are available for all to read and >> implement. >> 2. Maximize End-User Choice: Open Standards create a fair, competitive >> market for >> implementations of the standard. They do not lock the customer in to a >> particular >> vendor or group. >> 3. No Royalty: Open Standards are free for all to implement, with no >> royalty >> or fee. >> Certification of compliance by the standards organization may involve a >> fee. >> 4. No Discrimination: Open Standards and the organizations that administer >> them do not >> favor one implementer over another for any reason other than the technical >> standards >> compliance of a vendor's implementation. Certification organizations must >> provide a >> path for low and zero-cost implementations to be validated, but may also >> provide >> enhanced certification services. >> 5. Extension or Subset: Implementations of Open Standards may be extended, >> or offered >> in subset form. However, certification organizations may decline to >> certify >> subset >> implementations, and may place requirements upon extensions (see Predatory >> Practices). >> Page 7 of8 >> SOV - Open Source Software and Open Standards Policy >> 6. Predatory Practices: Open Standards may employ license terms that >> protect >> against >> subversion of the standard by "embrace and extend tactics". The licenses >> attached to >> the standard may require the publication of reference information for >> extensions, and a >> license for all others to create, distribute, and sell software that is >> compatible with the >> extensions. An Open Standard may not otherwise prohibit extensions. >> Bruce Perens, httP:U8ere~s.comfOpenStandardsfDefinition.html >> Issuing Entity: Office of the Secretary, Agency of Administration· >> Approved: __r."' ,J....;{ L=-=UL=----t*'.L....' ---- Date: >> -..o::kf-I=if'-/-O-,-I' _ >> Secretary of Administration >> Page 8 of8 >> >> >> On Tue, Mar 9, 2010 at 11:29 AM, joe golden <[email protected]> wrote: >> >> >> >>> Has the State finally come to its senses? Please peruse this doc closely. >>> Does it have teeth? Will people read it? >>> >>> It certainly seems to be the real deal. Section 1.2, page 3 says "... an >>> investigation of potential open source software solutions should be >>> conducted prior to issuing a bid for proprietary software solutions, ..." >>> This could be huge for Open Sourcerers. >>> >>> Can someone convert the damn PDF image of the doc to a text format. That >>> should make for easier dissemination and discussion. (This is not a >>> droll/troll ;-) ) >>> >>> Note that the Euros are aware of this: >>> >>> http://www.openforumeurope.org/press-room/latest-news/vermont-adopts-open-source-software-policy >>> >>> Happy Techno Spring. >>> -- >>> Joe Golden /_\ www.triangul.us /_\ People, Ideas, Connections >>> >>> >>> >> >> >> >
