|
|
| Home - Industry Article - Aug 06 Issue |
Why Software Companies Must Consider the Government Market
continued... page 2 |
Winning Contracts
Unlike in the commercial context, the government is required by law to competitively bid most of its contracts. This means that the government must first issue a Request for Proposals or an Invitation to Bid, setting forth both the government’s requirements and the criteria by which the government will evaluate submissions. Submissions are judged by a Contracting Officer, who later will bear the responsibility for administrating the contract with the winning bidder. In all of these areas, the government’s behavior is noticeably different from that of commercial companies. It is in some ways easier to understand, as the government buyer is limited in its evaluation to the specific factors set forth in the invitation or request. But it also can be frustrating, in that virtually all contracts must be “competed” — regardless of the performance of the incumbent contractor.
That said, the decision-making process is not that different from a commercial bid: companies submit information (including, where necessary, confidential information protected by bidding laws or nondisclosure agreements) for evaluation, make presentations, and then wait for the buyer to decide. On sufficiently large contracts, unsuccessful bidders can challenge the award (a “bid protest”), claiming that the winning bidder failed to satisfy the pre-set criteria or engaged in misconduct. A bid protest goes first to the Contracting Officer, then through his administrative superiors and a Board of Contract Appeals before finally reaching the court system. But though the bid protest process seems convoluted to outsiders, it is in fact not substantially different from the litigation disgruntled bidders sometimes bring in commercial competition.
With competent legal counsel, navigating from beginning to end of the government contracts process can be a relatively straightforward and painless task.
Part III
Licensing Software to the Government
In Part II, “An Overview of the Process of Government Contracting,” we discussed in general terms the process of finding and bidding on a government contracting opportunity. In this final section, we highlight issues specific to software companies entering Federal contracts.
As discussed above, for the last 20 years or more the Federal government has taken the position that intellectual property can be exploited more effectively by private contractors than by government agencies. Accordingly, the default rule is that government agencies do not seek and will not acquire the intellectual property rights of contractors. Technically, this rule can be bent in the case of patents, where the government still is willing to assert ownership of contractor assets and where the latent threat of “march-in” rights has kept contractors in check. xiii But for a software company whose primary intellectual property asset is copyrights (source and object code), not patents (business methods and the like), the risk of the government seeking to repossess company resources is remote. Moreover, the government has never actually asserted these march-in rights, which only apply to patents developed under the contract as opposed to pre-existing intellectual property. The government generally understands and respects the need of the contractor to protect its intellectual property rights.
The government typically licenses software on a per-seat basis. Thus, rights are limited to the number of software copies sold; the Federal government operates in this respect just like any over-the-counter purchaser. There are exceptions, however, when it comes to technical data — particularly in defense-related contracts. In the case of software developed in part or in full with government funds, the government often will seek to acquire a broader “government-purposes” license, and also will seek databases and accompanying documentation. Thus, it is critically important for companies doing business with the U.S. government to document all sources of funds used to develop the software being sold. Government rights in software can fall into four categories:
Restricted Rights
The “Restricted Rights” designation is preferred by software companies. Restricted Rights software has been developed at private expense and may also include trade secrets. A Restricted Rights designation prevents the government from making copies of copyrighted programs, except to switch computers or perform software maintenance. Restricted Rights software code cannot be released under the Freedom Of Information Act (FOIA) or disclosed for competitive bidding purposes.
Government Purpose Rights
Government Purpose Rights limit the government’s ability to distribute software outside the government. Generally, Government Purpose Rights convert to Unlimited Rights after five years, unless the parties agree otherwise (as very often they do). Software subject to Government Purpose Rights usually has been developed in part with government funds under a particular contract. Software subject to Government Purpose Rights cannot be released pursuant to a FOIA request, but may be disclosed for competitive bidding purposes. Government Purpose Rights are most commonly sought in Department of Defense contracts.
Small Business Innovation Research (SBIR) Rights
For software developed under SBIR grants, the government is limited in its ability to distribute the software and in the number of copies it can use. The duration and nature of this limitation varies with the SBIR contract under which the software was created. During the limitation period, SBIR software cannot be released under FOIA or disclosed for competitive bidding purposes. After the limitation period expires, however, the government’s rights become unlimited.
Unlimited Rights
As the name implies, the government has no limitations on distribution or the number of copies it uses of “Unlimited Rights” software. Unlimited Rights software has been developed wholly at public expense and can be released both under FOIA and disclosed for competitive-bidding purposes.
The regulations governing the procurement process offer surprising flexibility in terms of software licenses. For commercial software, Part 12 of the FAR allows delivery using standard commercial terms — the same shrink-wrap license that applies to an over-the-counter buyer at Fry’s Electronics could well apply to the Federal government. FAR and various agency-level elaborations like the Defense Federal Acquisition Regulations allow delivery of non-commercial software under a Restricted Rights designation if (a) the protected status of the software was identified in the contractors proposal or bid, (b) the software and documentation is properly marked, and (c) the company maintains records supporting the Restricted Rights classification in the event of a challenge. The real problem is finding a Contracting Officer with the confidence to use this regulatory flexibility, or to insert the right alternate clause in the case of non-Defense contracts. xiv
And in the event of a breach of the government’s license, software companies are able to sue for redress in the Court of Federal Claims, or use a form of binding arbitration through Agency Boards of Contract Appeals set up under the Contract Disputes Act (CDA) and specializing in resolving contract disputes. As an alternative, software companies can sue for copyright and/or patent infringement. However, under 28 U.S.C. § 1498(a) & (b), the exclusive action for an owner of a patent or copyright that is infringed by the government is in the Court of Federal Claims, rather than in a company’s local Federal district court. Nevertheless, a successful plaintiff is entitled to actual damages and profits, and also can seek statutory damages under section 504(c) of the Copyright Act.
Software companies thus enjoy substantial legal protections — commensurate with what they enjoy in the private sector — and tangible advantages in contracting with the Federal government. As we said at the outset: It’s better than you think.
i See, e.g., Federal Government – The World’s Biggest Customer, http://government.onvia.com/?p=15 visited June 13, 2006.
ii See Larry C. Pueschel & Luis A. Rose, Estimating the Government Telecommunications Market, THE TELECOMMUNICATIONS REVIEW 2006 at 29-44 (2006).
iii The Federal Acquisition Regulations are codified at Chapter 1 of Title 48 of the Code of Federal Regulations, with agency-specific supplements being in the remaining Chapters.
iv See Federal Acquisition Regulations (FAR) Part 12 and 2.101.
v http://www.ncgov.com/asp/subpages/intention.asp?P=1&I=90 visited June 13, 2006.
vi http://www.state.sc.us/Requisition (visited June 13, 2006).
vii http://www.state.tx.us/category.jsp?language=eng&categoryId=2.9 visited June 13, 2006.
viii https://www.tenders.gov.au/federal/index.cfm visited June 13, 2006.
ix 10 U.S.C. § 2371 (DOD, DHS); 42 U.S.C. § 2451(c)(5) (NASA).
x One example of venture funding is funding available from the CIA through In-Q-Tel, a description of which can be found at http://www.in-q-tel.com/about/index.htm.
xi A software company with less than $18 to $21 million in annual revenues generally will qualify for small-business set-asides. See generally http://www.sba.gov/size/guide.html visited June 14, 2006. Computer hardware companies typically need to have fewer than 1000 employees.
xii For example, subcontractor patent rights may bypass the prime contractor and exist only between the government and the subcontractor. See FAR 52.227-11 or 52.227-12. Additionally, 10 U.S.C. § 2320 requires prime contractors to Defense contracts include clauses to flow down protections for technical data, and the Defense computer software clauses mirror this technical data requirement.
xiii March in rights generally refer to the Federal Government's right to take title to subject inventions under certain circumstances. Subject inventions are inventions first conceived or actually reduced to practice under a Federal Government contract. The conditions for march in are contained in 35 U.S.C. § 203, as well as in the patent rights clauses found at FAR 52.227-11 through 52.227-12.
xiv Unlike Defense contracts, which are governed by the Defense Federal Acquisition Regulations (often referred to as the DFARS), civilian agencies generally follow the FAR when purchasing software. In the context of software, only FAR 52.227-19 (Commercial Computer Software), FAR 52.227-20 (SBIR program software) and FAR 52.227-14 (Alt. III) allow delivery of software with restrictions. Otherwise, FAR 52.227-14 specifically prohibits delivery or software with restrictions.
David S. Bloch is a Partner with McDermott Will & Emery LLP (www.mwe.com), specializing in intellectual property litigation in the firm’s Silicon Valley office. He has substantial experience in providing business counseling and strategic advice concerning intellectual property issues. David has represented clients in the multimedia, computer software, computer hardware, life sciences and biotechnology, microchip and consumer product industries, amongst others. For article feedback, contact David at dbloch@mwe.com
James G. McEwen is a partner with Stein, McEwen & Bui LLP (www.smbiplaw.com), specializing in intellectual property prosecution and counseling in the firm’s Washington, D.C., office. James has prepared and prosecuted patent applications in computer hardware and software, control systems, mechanical and optical devices, data encoding and decoding methods and devices, and display device technologies. In addition, he has been involved in patent validity and infringement opinions, reissue and reexamination proceedings, intellectual property licensing and settlement negotiations, intellectual property licensing with elements of the federal government, trademark prosecution, domain name disputes, trade secret protection, and provided litigation support in patent infringement claims. For article feedback, contact James at jmcewen@smbiplaw.com
 
|
|
|
