Sequoia Voting Systems plans to publicly release the source code for its new optical scan voting system, the company announced Tuesday — a remarkable reversal for a voting machine maker long criticized for resisting public examination of its proprietary systems.
The company has long had a reputation for vigorously fighting any efforts by academics, voting activists and others to examine the source code in its proprietary systems, and even threatened to sue Princeton University computer scientists if they disclosed anything learned from a court-ordered review of its software.
Given that Sequoia is now acknowledging the value of code disclosure as something that can lead to better security rather than worse security, as it has claimed in the past, Felten said “it seems that it should follow that they would now be willing to release code for all of their other products as well.”
Appel, in a separate issue, also found a discrepancy between summary tapes printed from Sequoia touch-screen machines during New Jersey’s primary election and totals that were recorded on the machine’s memory cards. Summary tapes from machines in one district showed a phantom vote for then-presidential-candidate Barack Obama that didn’t appear in the memory card totals.
Earlier this year, in a separate case, Sequoia agreed, after a concerted battle, to hand over its source code to election officials in Washington, DC, to investigate why, during the city’s September 2008 primary election, Sequoia’s optical-scan machines added about 1,500 “phantom” votes to races on ballots cast in one precinct.
After the city demanded to look at the source code to determine the problem, Sequoia in turn demanded a $20 million bond from officials guaranteeing they wouldn’t disclose information about the system. Sequoia finally relented to provide the code without a bond, though only after the city agreed to keep the company’s trade secrets confidential.
If you find yourself having to (or wanting to) compile a piece of software, don't panic. The process is fairly simple. Every piece of software is different, but here is a summary of the most common scenario for Unix-based OS such as Linux or Mac OSX. These instructions are not so useful for Windows, as apps are usually built with special GUI development tools, not command line tools.
Linux You almost certainly already have a command line, and a compiler called gcc. Try typing gcc on the command line. If it tells you command not found, install gcc using your package manager.
Mac OS X Your command line is Terminal, which is located in Applications/Utilities. You'll need to download XCode, which contains Apple's compiler, from the Apple developer tools web site. XCode is often bundled on the operating system CD or DVD that comes with your computer.
Windows Microsoft provides a compiler with its free downloadable GUI development environment Visual Studio Express, but Cygwin is both more useful and more Unix-compatible. Download and install it, making sure to include all the packages from the "Devel" section when you choose packages.
Downloading Practically all source packages come in a zipped-up archive file. This will have the suffix .tgz or .tar.gz. (on Windows .zip) It will also have a name and a version number, something like example-3.2.8.tar.gz. You should make yourself a directory to work in, called "source" or "build" or something along those lines. Using a browser, download the source file into that directory.
Unpacking From your command line, go into your working directory (using the cd command): "cd source"
The quickest way to unzip the archive is tar: "tar -xzvf example-3.2.8.tar.gz"
This will unzip all the files of the source code into a new subdirectory with the same name as your application, including the version numner. Go into this directory by typing: "cd example-3.2.8"
Reading the Documentation Practically every source package contains some reading material, typically files with names in all caps, like README and INSTALL. Read these! They tell you how to proceed. There may also be documentation for your specific situation, like README.macosx. You can use the less command on the command line to read them:
or just open them in your favorite text editor. The documentation may point you to other software that you need to install before you can install this package ("dependencies"), or to quirks of the installation process that you need to be alert for. Much of this may be covered on the software's web page as well.
Building The process may differ (especially on Windows), but the most common procedure is as follows. Type: ./configure
For a full list of all the options you can give to the configure tool, "run:./configure --help"
The configuration process may take several minutes. When it's done, if it doesn't give you an error message, you're ready to compile. If it does give you an error message, refer to the Troubleshooting section below. To compile the software, just type: "make"
This performs the meat of the operation. If all goes well, it should take a while, and may monopolize your computer's processor while it's running. Don't worry, compiling software is intensive work. When it ends, if you don't see an error message, you're ready for the last step. Note that you probably won't see a congratulations message either.
The software has been compiled. All that remains to do is to put it where it belongs.
"make install" will place the various files that have been built in their proper locations in the filesystem. Now they're ready to be used. Often, you will need to run make install with root level permissions so files can copied to correct location.
"sudo make install" Most systems have the sudo command, which will allow you run commands as the super-user. Note that, When running commands with sudo you will be prompted for a password.
Troubleshooting If any of the steps above don't go smoothly, there are a few systematic steps to take that will help figure out what the problem is. Make sure you've followed all the instructions rigorously, and that you have any necessary dependencies installed.
Open source doesn't just mean access to the source code.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 if the 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:
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 of the license may be predicated on any individual technology or style of interface.
In the traditional model of development, which he called the cathedral model, development takes place in a centralized way. Roles are clearly defined. Roles include people dedicated to designing (the architects), people responsible for managing the project, and people responsible for implementation. Traditional software engineering follows the cathedral model. Fred P. Brooks in his book The Mythical Man-Month advocates this model. He goes further to say that in order to preserve the architectural integrity of a system, the system design should be done by as few architects as possible.
The bazaar model, however, is different. In this model, roles are not clearly defined. Gregorio Robles  suggests that software developed using the bazaar model should exhibit the following patterns:
Users should be treated as co-developers:
The users are treated like co-developers and so they should have access to the source code of the software. Furthermore users are encouraged to submit additions to the software, code fixes for the software, bug reports, documentation etc. Having more co-developers increases the rate at which the software evolves. Linus's law states that, "Given enough eyeballs all bugs are shallow." This means that if many users view the source code they will eventually find all bugs and suggest how to fix them. Note that some users have advanced programming skills, and furthermore, each user's machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug.
The first version of the software should be released as early as possible so as to increase one's chances of finding co-developers early.
Code changes should be integrated (merged into a shared code base) as often as possible so as to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds where integration is done automatically on a daily basis.
There should be at least two versions of the software. There should be a buggier version with more features and a more stable version with fewer features. The buggy version (also called the development version) is for users who want the immediate use of the latest features, and are willing to accept the risk of using code that is not yet thoroughly tested. The users can then act as co-developers, reporting bugs and providing bug fixes.
The general structure of the software should be modular allowing for parallel development on independent components.
Dynamic decision making structure:
There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors. Cf. Extreme programming.
Most well known open-source software products follow the bazaar model as suggested by Eric Raymond. These include projects such as the Linux kernel, Firefox, Apache, the GNU Compiler Collection, and Perl.
Miller said the foundation wasn’t looking to put voting system companies out of business but to assume the heavy burden and costs of research and development to create a trustworthy system that will meet the needs of election officials for reliability and the needs of the voting public for accessibility, transparency, security and integrity.
An open source license is a copyright license for computer software that makes the source code available under terms that allow for modification and redistribution without having to pay the original author. Such licenses may have additional restrictions such as a requirement to preserve the name of the authors and the copyright statement within the code. One popular (and sometimes considered normative) set of open source software licenses are those approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD).
A license defines the rights and obligations that a licensor grants to a licensee. Open Source licenses grant licensees the right to copy, modify and redistribute source code (or content). These licenses may also impose obligations (e.g., modifications to the code that are distributed must be made available in source code form, an author attribution must be placed in a program/ documentation using that Open Source, etc.).
Authors initially derive a right to grant a license to their work based on the legal theory that upon creation of a work the author owns the copyright in that work. What the author/licensor is granting when they grant a license to copy, modify and redistribute their work is the right to use the author’s copyrights. The author still retains ownership of those copyrights, the licensee simply is allowed to use those rights, as granted in the license, so long as they maintain the obligations of the license. The author does have the option to sell/assign, versus license, their exclusive right to the copyrights to their work; where upon the new owner/assignee controls the copyrights. The ownership of the copyright (the “rights”) is separate and distinct from the ownership of the work (the “thing”) - a person can own a copy of a piece of code (or a copy of a book) without the rights to copy, modify or redistribute copies of it.
When an author contributes code to an Open Source project (e.g., Apache.org) they do so under an explicit license (e.g., the Apache Contributor License Agreement) or an implicit license (e.g., the Open Source license under which the project is already licensing code). Some Open Source projects do not take contributed code under a license, but actually require (joint) assignment of the author’s copyright in order to accept code contributions into the project (e.g., OpenOffice.org and its Joint Copyright Assignment agreement).
Placing code (or content) in the public domain is a way of waiving an author’s (or owner’s) copyrights in that work. No license is granted, and none is needed, to copy, modify or redistribute a work in the public domain.