(entry last updated: 2003-07-03 20:34:07)
(Hoo boy; on rereading, it’s clear I was getting pretty tired here. I have done a little editing, but more probably ought to be done)
This presentation is going to be awkward, in that the schedule change means that you already got to hear the debate, and you only heard from Yochai on open source; and you didn’t have this part. Sorry
Because of the depth of the earlier discussion, I can probably go faster than I expected. Here we go
Four regimes that can be used to protect software: trade secret law, copyright, patent and contracts
Roughly speaking trade secret and copyright are becoming less important, and the other two are becoming more important. I think I will be laying the foundation for the proposition that, between these various systems, my view is not a clear cut as Larry’s that patent protection is necessarily bad. In particular, if construed properly, patents might be better. And, in fact, the real danger is the in the domain of contracts
Trade secret law is potentially a basis for protection because of the difference between source code and object code. In order to shield, one only reveals the object code; and the legal system steps into protect the secret of the source code via trade secrets. Note that trade secret law is state law; in some states it’s common law, in some states it’s statutory. Specifics differ by jurisdiction, but only in small ways.
Trade secrets are (a) Information pertainting to manufacture; (b) processes for treating or preserving materials; (c) information relating to business operations; (d) consumer lists; computer programs; (e) single or ephemeral events and (f) negative information (note a socially pernicious effect - the waste of monies chasing something that is already known by others to be a failure).
So this is an opportunity. How to achieve this protection. First, the information must have been secret initially (and possibly novel). A reasonable effort must have made to keep the secret (efforts to signal the intent to protect, rather than something stringent, like retinal scans). And the information must be commercially valuable
How to show liability - two circumstances (1) the defendant got the information via a breach of confidence (usually migration of employees previously or still under contract); (2) or “improper means” - mostly actions that are independently illegal (B&E, etc). It does include actions otherwise legal; the duPont decision - a competitor hires a plane before the roof on a plant is finished to take pictures and is found to have infringed.
The key doctrine that weakens this protection is that which makes reverse engineering permissible. So, buying a copy of a piece of software, and debug/decompiling, you are perfectly in the clear.
Software is added to copyright as a consequence of Congressional action following the 1977 CONTU (1978 Act). So, software is like a novel, musical composition, etc. The author enjoys the standard entitlements. Exceptions are fair use, merger (part of the idea/expression distinction - when there are only a few possible ways to express an idea, the principle that ideas are not protected dominates, so copyright does not obtain if there are only a few ways to implement the idea in software), and “essential” or “archival” copying.
Apple v. Franklin (CA3 1983) - Franklin copied the Apple OS so that user applications could run on its hardware. Franklin is sued; stipulates copying, but asserts that the only way to run Apple applications requires the Apple OS - a claim that the merger doctrine applies. Court says - NO; Franklin goes out of business.
Under TRIPS (146 countries), the principle is extended to the rest of the world. Article 10 says that source and object codes are protected by copyright. Articles 11, 12 and 13 limit the ability of countries to modify the standard copyright provisions for computer programs.
Yet, there is a diminishing of copyright protection as an exploited strategy. Certain judicial interpretations have been unfavorable to the copyright owner. Nonliteral copying of programs (how close a similar function is too close?) - after offering relatively broad protection, the Altai case leads to a sharper look at the nature of the similarity, requiring a consideration of an analysis of the program at the abstract functional level - leading to less protection to the copyright holder.
Reverse engineering to achieve interoperability is also not an infringement. Development of code to work around lockout is a fair use.
Menu hierarchies are not copyrightable (the Lotus look and feel cases) - on the grounds that a menu hierarchy is a method of operation and thus un-copyrightable
(Jonathan described working on MS Excel 3. There, he was workinf on finding menu text that would be (a) synonymous with the Lotus structure and (b) containing the same key letter so that the same keystroke sequence would generate the same program action in 123 and Excel. After a dispiriting run through the thesaurus, Z’s team hit upon a different approach - the 123 user help system/tutor. Initiated by the forward slash, the same function initiator as 123, the tutor would process the subsequent keystrokes and inform the user that the Excel keystrokes to achieve the same task were as follows, and then would execute as a demonstration. The consequence was that the parser would use the 123 menu hierarchy, even though the formal Excel hierarchy was something else, and Lotus was perfectly happy to accept this approash as non-infringing.)
Ineffective enforcement: the Business Software Alliance’s statistics assuming that loss = copies in use. The world piracy rate is rising overall, especially in Asia. As the piracy rate rises, the presumption that you should be protected falls (you aren’t trying hard enough to protect) - so trouble here too
The US is the pioneer in this treatment - in Gottschalk v Benson, the patent is disallowed because software is just an algorithm; Diamond v. Diehr (US 1981) software in hardware patentable. And finally, the Federal Circuit relaxes the impediments. For a while, it has to be combined with a machine; then running on a microprocessor, etc.
Approximately 300,000 applications per year; about half granted - and the trend is up.
How do the doctrines of patent law get applied in this setting; utility, novelty, obviousness and disclosure - in software, the obviousness hurdle is made more difficult to surmount, while the enablement hurdle is lowered - so source code does not have to be disclosed.
Q: How big a deal would it be to remove patent protection for software? Terry: not sure; Another practitioner: I don’t know how to answer. Software will continue to get written, but new activities are likely to be undertaken at a lower rate. More than likely a turn to contract.
We’ll come back to patents, and let’s turn to contract. No given the questioning, we better go with it now. Patent protection has the merit of being harder to get, so the number of programs shielded is substantially lower. Another way in which patent protection is narrower: copyright requires substantial similarity, while the patent law requires that the plaintiff’s patent infringement claim requires a showing that ALL the patent’s claims are infringed (that seems wrong to me - I’m not sure I got it).
We could change the rules so that disclosure is required, and we allow reverse engineering for interoperability as we do is copyright. With this and other adjustments, it’s possible to argue that patent law might be a less onerous property domain.
Politically, however, we have the situation that patents are easier to take away from software writers as a mechanism for protection than copyright ever will be.
Contract law is much more protective. Shrinkwrap licenses and click-on licenses include a host of restraints, removing many of the protections in fair use, first sale, etc. substantially more generous than copyright.
It’s not clear if these things are enforceable. The UCITA effort tried to accomplish this - and luckily a host of law professors managed to head this off. A mixed bag on whether copyright preempts state contract law. Some have been found to be preempted and some not. Bowers most recently says no preemption, in this case on reverse engineering.
So, contract law is the most noxious-looking one of these domains.
Q: Are there any new UCITA efforts out there? Terry: So far, no, but there’s still the case that individual judges could elect follow it anyway
Q: Jim Flower - UCITA was too onerous to try to rearrange the Georgia Code; states viewed it with suspicion, particularly given that they at least understood the law. Inertia as a social benefit in this case.
Q: Does not the difficulty of getting patents lead to distribution effects - low income participation in patenting is unavailable. Terry: You are right that there is a clear disproportionate effect in the favor of those with the resources to pursue patents.
Q: Where does Lexmark fit into this reverse engineering for interop? Terry: The DMCA provisions are distinguishable and able to override the reverse engineering doctrine. The viability of the escape hatch might have been decided in the presence of the DMCA
Q: the SCO case does not include a copyright claim - why not?
Z: The family tree through with the ownership of the unix code to SCO is so convoluted that it’s not clear that SCO know what copyrights they own. So SCO is working to keep it in state courts, and possibly leaving them the option to bring up copyright later.
IMHO, this probably was poor performance on my part here - be sure to check out the other weblogs that Donna cites here