Software patents have received a great deal of attention in the academic literature. Unfortunately, most of that attention has been devoted to the problem of whether software is or should be patentable subject matter. With roughly 40,000 software patents already issued, and the Federal Circuit endorsing patentability without qualification, those questions are for the history books. The more pressing questions now concern the scope to be accorded software patents. In this paper, we examine the implications of some traditional patent law doctrines for innovation in the software industry. We argue that patent law needs some refinement if it is to promote rather than impede the growth of this new market, which is characterized by rapid sequential innovation, reuse and re-combination of components, and strong network effects that privilege interoperable components and products. In particular, we argue for two sorts of new rules in software patent cases. First, we advocate a limited right to reverse engineer patented computer programs in order to gain access to and study those programs and to duplicate their unprotected elements. Such a right is firmly established in copyright law, and seems unexceptional as a policy matter even in patent law. But because patent law contains no fair use or reverse engineering exemption, patentees could use the grant of rights on a single component of a complex program to prevent any "making" or "using" of the program as a whole, including those temporary uses needed in reverse engineering. While patent law does contain doctrines of "experimental use" and "exhaustion," it is not at all clear that those doctrines will protect legitimate reverse engineering efforts. We suggest that if these doctrines cannot be read broadly enough to establish such a right, Congress should create a limited right to reverse engineer software containing patented components for research purposes. Second, we argue that in light of the special nature of innovation within the software industry, courts should apply the doctrine of equivalents narrowly in infringement cases. The doctrine of equivalents allows a finding of infringement even when the accused product does not literally satisfy each element of the patent, if there is substantial equivalence as to each element. The test of equivalence is the known interchangeability of claimed and accused elements at the time of (alleged) infringement. A number of factors unique to software and the software industry - a culture of reuse and incremental improvement, a lack of reliance on systems of formal documentation used in other technical fields, the short effective life of software innovations, and the inherent plasticity of code - severely complicate post hoc assessments of the "known interchangeability" of software elements. A standard for equivalence of code elements that ignores these factors risks stifling legitimate, successful efforts to design around existing software patents. To avoid this danger, courts should construe software claims narrowly, and should refuse a finding of equivalence if the accused element is "interchangeable" with prior art that should have narrowed the original patent, or if the accused improvement is too many generations removed from the original invention