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]
<mailto:[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 <http://www.triangul.us> /_\ People,
Ideas, Connections
