Wednesday, November 29, 2006

Core suggestions for HB5769

Sorry, folks, not too much time to blog. Just finished a mini-conference with civil society to present our positions on the CICT roadmap. Some juicy stuff, but none that I think I should blog about.

Anyway, here's what I've been working on, my suggestions for the FOSS Bill. Didn't find time to write more detailed explanations of the wherefores and whys, but I do hope there's enough here to provide a framework.

1) The Bill should lead to the definition of a reference operating system, built on FOSS, to be used as a benchmark for open standards interoperability in all government ICT projects. This is not FOSS for FOSS' sake. It is simply the means by which government can test whether an application -- FOSS or proprietary -- empirically complies with the standard computing environment that government has set.

No application should provide a feature that will not work with this reference operating system. Too often, vendors claim to comply with standards and yet provide "extras" that will work only with certain products; too often, these "extras" become specifications.

An application that does not completely interoperate with the reference operating system, even though provided for free by a vendor, should not be accepted.

All PC-based hardware acquisition, whether for CPU or peripherals, must be demonstrably compatible with the reference operating system.

The reference operating system must necessarily be FOSS because only a FOSS license will allow for examination, modification, use, and redistribution of the software. Government and interested vendors must be able to examine its code to make sure that it complies with open standards specifications. Government and interested vendors must be able to make modifications to the reference operating system as new standards are defined. Any vendor must be able to acquire the reference operating system for testing and benchmarking with their products.

In cases where a government agency or organization -- or any citizen for that matter -- cannot afford to license a proprietary operating system, the reference operating system can then be provided in its stead.

The Bill must appoint a government agency as custodian of this reference operating system. It must allocate funds by which the said government agency can maintain and support the reference operating system.

2) The Bill should provide stricter audit measures with regard to software license compliance and software acquisition. Government must lead by example.

Proprietary software insinuates itself into government systems by way of piracy. Finally faced with the prospect of proper licensing, pirated software becomes too deeply rooted in operations such that no other alternative can be sought.

Software license compliance within government should be transparent to the public. The Bill should provide for this. Only then can we be certain that there are no hidden accumulating costs within government information systems.

Software acquisition and maintenance costs must also be made public. No software cost should be bundled into hardware purchases. Only within a transparent environment can government properly gauge whether it is FOSS or proprietary solutions that is cost-effective.

3) The Bill should recognize and respect the licenses of shrink-wrapped or packaged software that it procures.

That said, The Bill must encourage government agencies to carefully evaluate the licenses for any hidden future costs. Software license costs must be predictable and transparent. They must be properly gauged throughout the projected lifetime of the system. This applies equally to both FOSS and proprietary products.

FOSS licenses must be respected, and The Bill should take pains to enforce this. FOSS products that government implements, whether implemented internally or by a vendor, must follow its intended license.

However, all software in which government agencies participate in the design and development should fall under a FOSS license, whether by heritage or origin. Vendors who participate in its development would be considered to be subcontractors, and government considered to be the primary owner. Corollary to this, no tool or library may be used that would prevent the complete working end product and its source code from falling under a FOSS license.

4) The success of FOSS depends greatly on the availability of support. The Bill should empower a government agency with the resources and the capabilities by which it can support FOSS initiatives. The said government agency should work with government research agencies and state universities and colleges in developing a FOSS support network that extends throughout the country.

SUCs and HEIs need not be compelled to offer FOSS-related courses. FOSS should simply be a logical extension of the government initiatives in which they participate.

The agency and its network must initially support the reference operating system. As its capabilities grow, it can add to its roster the library of replicable FOSS solutions previously implemented in other projects. The agency can certify these products to be compliant with open standards and with government procedures. Implementing these solutions will result in significant cost savings, reduce development time, and promote standardization of government systems.

Government need not be the agency to deploy these solutions; interested outside vendors can step forward to implement them.


1 comment:

  1. hiya ... sorry, can't really comment on foss related stuff coz I don't have a clue. ;-). wanna hear about the juicy stuff though .. har har .. :-)

    just dropping by ...