Linux in Government: Federal Contracts, a New Era of Competition
Earlier this year, a major open-source event came and went without much community notice and with little media attention. A Cabinet-level federal agency released a software product under the GPL, making it the first tool of its kind to be licensed by the US government free of charge to public and private sector organizations.
Although the Open Source and Industry Alliance praised the effort in a letter to Secretary Elaine Chao, some of us wonder if this kind of event will happen ever again. This story received little to no attention by the media, yet it created quite a stir within the government software vendor community. The backlash might have government officials thinking twice the next time the subject comes up.
Opportunities seem rare in the case of the government releasing GPL software. First, the government wants industry to bring solutions to government problems rather than have government agencies develop their own software. That makes it difficult for procurement officials to find their "best value proposition". Secondly, open-source vendors do not have the funds, organization and alliances to educate procurement officials the way proprietary firms do. So, government agencies buy licensed software products almost universally.
So, when a government agency does put GPL software on a Web site and let people download it for free, that's an important milestone. It's not one we should take lightly.
Peter Gallagher, of DevIS worked diligently for several months to have the first federally funded GPL project released. When he finally saw light at the end of the tunnel, he realized he achieved his goal but not without a high degree of difficulty. It took nine months of negotiations, extensive legal fees and many sleepless nights--a high cost for a small business. He still wonders if he created a model agencies can follow in the future. Peter explains:
Our experience working with the Dept. of Labor to have our work released under an OSS license was telling. Here we are talking about software development that was funded by the government as opposed to buying a license in an existing product. The Federal Acquisition Regulations (FAR) have something called "Rights in Data" that are part of any Federal contract. The basic clause says authors generally have the right to their copyright--this applies to a research paper as well as software although it does get complicated.
To release under the OSS license you need to have a copyrighted work, and the government generally does not create copyrighted works. So in the case of the DoL, DevIS transferred our copyright to the DoL who released the work. I think it would have been easier to just have us release the code directly as a small business. Developing the copyright transfer document cost us over $20,000 in legal fees but in this case our customer, the DoL, wanted the responsibility. The important thing for us was that a product we developed, primarily with federal funds, was now released on a .GOV site as OSS.
Companies should be able to release such code without difficulty. When DevIS requested its copyright, the customer hesitated and decided not to release the copyright. That began rounds of negotiations, which ended with DevIS giving the copyright to the DoL, which in turn placed the product under the GPL, albeit awkwardly. You can download the software after you agree to the license and register with the agency--not exactly a FLOSS approach.
Many of us seem confused about the federal government's ability to fund, copyright and release code under the GPL. I discussed this topic with a number of people who pointed me to the United States Code, Title 17, Chapter 1, Section 105. It states:
Subject matter of copyright: United States Government works: Copyright protection under this title is not available for any work of the United States Government, but the United States Government is not precluded from receiving and holding copyrights transferred to it by assignment, bequest, or otherwise.
Peter explains:
In many cases, assuming the software is not proprietary, the work is available to the whole government for unlimited use and it falls under the public domain. Public domain materials can be requested by anyone, but in practice the people who know about an internal government project are limited. Thus, being available to the public does not mean anyone would know to ask [for it]. So is it really public?
Open-source advocates may find the situation perplexing, at best. If the government uses our tax dollars to develop software to solve government problems, why can't we know about it? Why can't a vendor have the copyright and release it as open source? Where's the level playing field we so often see quoted? How can I compete against industry giants as a small company?
Again, Peter explains:
The advantage of an Open Source Software license is that the code must be published--I assume that to mean that it must be made available via the Web. An Open Source Software license creates clear commercial rights, making it more likely that government funded code will result in something beneficial for citizens, including eGovernment re-use that cuts costs--and hopefully taxes someday.
In last week's article, we discussed the Library of Texas.org project. In that case the vendor, Index Data of Denmark, made the software available under the GNU General Public License (GPL). From my point of view, that seems like the appropriate way a government-funded project should proceed. Public money funded the project, so the vendor should have some obligation to make it available to the public through a normal commercial channel, without us having to pay for it again and again, a la Microsoft.
If you question the logic, consider this scenario: the government (on the citizens' behalf) asks a commercial vendor to build a car, the vendor builds the car and the government says, "we invented the car". Although the government funded the project, you have to ask who did the inventing. Who had the brain power to make it happen? Also, who paid for it? In some distorted belief systems, some agency officials somehow feel that the money belongs to them and not to the people of the United States.
I asked Peter about the status of the project once it became a GPL project. Here is what he said:
We continued our support for the project through a derivative work we call EZRO (EZ Reusable Objects). It has a clear lineage. Since the original software was finished, the DoL has modified it through other contracts, and DevIS has enhanced EZRO. The public benefits because software now is available that in the past would have been locked away. The government benefits too; the DoL/OSHA, for instance, has saved hundreds of thousands of dollars by developing and delivering e-learning using EZRO. And open-source projects benefit when the government uses their products, because professional developers can contribute to communities with which they otherwise might not have been able to work.
I think, as a default license, any federal contractor should be allowed and encouraged to request copyright so that work can be published easily under an OSS license. There is no reason that specific contracting language could not require OSS releases as well, although the federal government is unlikely to state such a preference, relying instead on the market to propose solutions to their requirements.
Except where the government has security issues, I think publicly funded code should be available to the public. And as we move more to components, Web services and portals, it is pretty clear to me that OSS can save a lot of money and make systems better by sharing investments in public infostructure.
In my experience, getting the Department of Labor to GPL a software product has made a difference. For one thing, the rest of the government knows the product exists. Although government-developed software should be available to any other agency, rarely does one agency know what another has. Secondly, a milestone by any other name is still a milestone. Regardless of the awkwardness of the process, a precedent exists and we now can show proof of concept.
Finally, I have dug around and looked for any possible opening to see if open-source software can have a place in government procurement. One exists in an obscure Request for Proposal (RFP) hardly anyone would know about. Among the familiar wording,I found something about which to smile. From a RFP:
Describe in detail a standards based system solution: Include the software and hardware products and components of your proposed solution. State the hardware platforms and operating systems on which your system will operate. Define COTS (Commercial Off-the-Shelf) products, including Open Source software you propose and the standards (ANSI, IEEE, ISO, etc.) of your proposed solution.
Noticed that the authors of the RFP asked the vendors to "Define COTS...including Open Source software". Of the thousands of RFPs posted on government sites in the United States, someone got the message.
In an election year, I doubt this will become much of an issue, especially in light of the media's focus. But, wouldn't it be something if the people somehow demanded that such a clause exist in every RFP issued in the future?
Tom Adelstein works as a Linux consultant and specializes in identifying opportunities for open-source software in organizations. He's the coauthor of the upcoming book, Exploring Linux with the Java Desktop System, published by O'Reilly and Associates. He also works with the Open Source Software Institute. He recently published two articles in Forbes about open-source software and JBOSS. He also has written numerous articles as a guest editor for a variety of publications.
