mark <@utrcgw.utc.com:mark@ardnt1> (04/03/91)
I thought that this might interest a few people. --Mark ------------------------------------------------------------------------------ | Mark Stucky | Email: | | United Technologies Research Center | mark%ardnt1@utrcgw.utc.com | | East Hartford, CT. |or mark%ardnt1@utrcgw.res.utc.com | | 06108 |or mast%utrc@utrcgw.utc.com | ------------------------------------------------------------------------------ ------- Start of forwarded message ------- From: rms <@utrcgw.utc.com:rms@gnu.ai.mit.EDU> Sender: gnulists <@utrcgw.utc.com:gnulists@ai.mit.EDU> To: info-gnu-emacs@prep.ai.mit.EDU, info-gcc@prep.ai.mit.EDU, info-g++@prep.ai.mit.EDU, info-gnu@prep.ai.mit.EDU Subject: Patent treaty update Date: Sat, 30 Mar 91 18:31:25 -0500 [Please repost this in any other lists, local or netwide, where it would be relevant and helpful. ] Here is the best scoop I have so far on the patent treaty. One of the problems I thought the treaty had seems to be gone in the authoratative draft: it does not require reducing the criterion of unobviousness. But it still seems to interfer with doing anything about software patents, so I've started talking with congressional staff and will try eventually to meet with the legislators themselves. Subject: UN Treaty Threatens to Mandate Software Patents WIPO (World Intellectual Properly Organization), a part of the United Nations, is working on a treaty to "harmonize US and European patent law". Proposed articles for the treaty would require software patents to continue to exist. (This conclusion is based on WIPO publication PLT/DC/3, December 21, 1990, which contains the full text proposed for the treaty, and on conversations with patent lawyers.) Article 10 (alternative B) of the proposed draft would require that there be patents in all fields of technology--which inevitably includes software. Alternative A for Article 10 would permit each country to specify fields of technology that are excluded from patents; this way, individual countries would retain the option of refusing to issue patents on techniques of programming or features of programs. Thus, we should urge support for alternative A. The Patent and Trademark Office suggests that there is a way to get around this limitation: it would still be possible to define the meaning of "invention" to exclude software. It is true that some countries can and do rule that computer programs are not inventions. However, patenting individual programs is not the issue; the software patents that cause today's problem cover software-related ideas, not individual programs. Redefining "invention" to exclude such ideas is likely to be rejected by legislators who (understandably) do not wish to so distort the meaning of the word. To make an analogy, right turn on red is a good policy, but redefining "green" to include red under certain circumstances is not a desirable way to institute it. We don't want to be reduced to advocating such a method as our only recourse. Many patents that restrict software development are not written so as to apply specifically to software. Rather, they cover particular techniques or features whether implemented by hardware or software. Therefore, rejecting software-specific patent applications would solve only part of the problem patents pose for software development. Solving the whole problem requires a different sort of change, such as a policy that software implementations using general-purpose hardware do not infringe patents. Article 19 of the treaty would rule out such a policy, if alternative B or C is chosen. We should urge support of alternative A for Article 19 (to delete the article). Since the US already has the problem of patents in software, these articles would not directly change the situation here. It does not follow that the treaty is unimportant for software developers in the US. We need to solve the problem of software patents, and this means we need to keep open our country's options to make the needed changes. In addition, Article 22 (alternative B) requires that patents last at least 20 years. For the US, this is an extension of the term of a patent. In an age when the rapid advance of technology makes most technology obsolete much more quickly than in the past, it would make more sense (in most fields) to shorten the term. (Many software developers advocate an extremely short span for software patents, such as three years.) For this reason, alternative B should be rejected. For all of these reasons, it is vital to prevent the adoption of the harmful alternatives when the treaty is finalized---or to prevent ratification in the US and in other countries. The treaty language is supposed to be finalized at a diplomatic conference in June. The principal ways Americans can influence the decision are via the US administration and via the US Senate. (If the Senate makes it clear they won't ratify the treaty with certain wording, that might convince the negotiators to change their plans.) To express your views to the administration, write to: Michael Kirk Box 4 US Patent and Trademark Office Washington, DC 20231 It is also useful to write letters to your senators; but letters are probably not enough. You probably need to get together with other programmers in your state, and then together arrange to meet with your senators' staff to discuss the problem. You need to communicate an understanding of a part of the world about which they know little. The background by which you can see the effects patents have in the software field is what they lack. If they don't learn this, they won't see the plausibility of the conclusions we draw. It is much easier to communicate this in a discussion than in a letter. When you communicate, please keep in mind the distinction between a patent on a computer program and a patent that affects software development. (If you don't, the Patent and Trademark Office will gleefully inform the Senator that this shows that you don't understand the existing system, and will suggest that your belief that any problem exists is entirely due to your misunderstanding.) In fact, an individual computer program is rarely or never patented; a patent so specific would not be worth the cost of obtaining it, since a program designed differently would certainly not be covered. The software patents that cause trouble today in the US cover software techniques or features, such as using exclusive-or to modify a display screen, or having multiple subwindows scroll together. Rules against patenting programs do not prevent patents like these. Excerpts from the treaty: Article 10, Alternative B: Patent protection shall be available for inventions, whether they concern products or processes, in all fields of technology. Article 10, Alternative A: (1) Patent protection shall be available for inventions in all fields of technology which are new, which involve and inventive step, and which are industrially applicable, except for: ... (2) Contracting States may, on grounds of public interest, national security, public health, nutrition, national development and social security, exclude from patent protection, either in respect of products or processes for the manufacture of those products, certain fields of technology, by national law. ... Article 19, Alternative A: Note: no article on the rights conferred by the patent. [rms: That is to say, the treaty would not address the issue.] Article 19, Alternative B: (1) [Products] Where the subject matter of the patent concerns a product, the owner of the patent shall have the right to prevent third parties from performing, without his authorization, at least the following acts: (i) the making of the product, (ii) the offering or putting on the market of the product, the using of the product, or the importing or stocking ... (2) [Processes] Where the subject matter of the patent concerns a process, the owner of the patent shall have the right to prevent third parties from performing, without his authorization, at least the following acts: (i) the use of the process, (ii) in respect of any product directly resulting from the use of the process, any of the acts referred to in paragraph (1)(ii), even when a patent cannot be obtained for the said product. (3) [Exceptions to Paragraphs (1) and (2)] (a) not withstanding paragraphs (1) and (2), any Contracting Party may provide that the owner of a patent has no right to prevent third parties from performing, without his authorization, the acts referred to in paragraphs (1) and (2) in the following circumstances: (i) where the act concerns a product which has been put on the market by the owner of the patent, or with his express consent, ... (ii) where the act is done privately and on a non-commercial scale or for a non-commercial purpose, provided that it does not significantly prejudice the economic interests of the owner of the patent; (iii) where the act consists of making or using exclusively for the purpose of experiments that relate to the subject matter of the patented invention [or for the purpose of seeking regulatory approval for marketing]; (iv) where the act consists of the preparation for individual cases, in a pharmacy or by a medical doctor, of a medicine in accordance with a medical prescription or acts concerning the medicine so prepared. (b) The provisions of paragraphs (1) and (2) shall not be interpreted as affecting the freedom that Contracting Parties have under the Paris Convention ... to allow, under certain circumstances, the performance of acts without the authorization of the owner of the patent. [rms: Those freedoms don't make provision for excluding software from patent coverage. Thus, alternative B as a whole does not allow such an exception.] (4) [Omitted here. This concerns contributory infringement] Article 19, Alternative C, differs in certain details. (1)(i) the making of the product, (ii) the offering for sale of the product, and the using of the product. (2) [Processes] Where the subject matter of the patent concerns a process, the owner of the patent shall have the right to prevent third parties from performing, without his authorization, the using of the process. (3)(i) [irrelevant minor differences] (ii) where the act is done privately and on a non-commercial scale, (iii) where the act consists of making or using for exclusively experimental, academic or scientific research purposes; (iv) [same as Alternative B] (b) [same as Alternative B] [rms: Alternative C likewise does not permit an exemption for software.] ------- End of forwarded message -------
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/04/91)
I don't understand software patents. How do they differ from copyrights? If I hold several copyrights, can I obtain software patents?
daveh@cbmvax.commodore.com (Dave Haynie) (04/24/91)
In article <1991Apr3.185516.12631@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > I don't understand software patents. How do they differ from >copyrights? If I hold several copyrights, can I obtain software patents? Here's an engineer's attempt at explaining this junk: Patents and copyrights are entirely different things. If you copyright a program (which is essentially automatic, though folks intending a court battle generally register their copyrights with the appropriate government agency), no one can legally make copies of it other than you and your licensees. However, someone can come along and make a program that works very much like yours (look and feel copyright legislation notwithstanding). A patent, on the other hand, is an "invention". You pay lawyers big bucks to write up a description of your invention, in big $25 lawyer-type words. Then you send it to the patent office. If they deem it a true invention, something unique that's never been done before, you get a patent for 17 years. During that time, no one can use your invention without your permission, even if they invent it independently after you've applied. And you don't even have to let anyone use your invention, though typically folks have found they can get money for patent licenses, and so they do often let other use the patents. The real problem with software patents is that the patent office hasn't had Clue #1 about software until very recently. So there are all these patents on real obvious things that have been around for years, but never patented (since, of course, they were obvious to their original inventors, and way back when software patents were not accepted in the US). The other main problem with software patents is the magnitude of unique ideas you'll find in a piece of code. You might have 10-20 real patentable things in a piece of hardware. If you're unlucky, 2 or 3 of them might actually be covered by a valid patent, and you could pay a couple of percent of your income on these to license said 2 or 3 patents. In a piece of software, you might have 10,000-20,000 things the patent office considers patentable. If you have to pay 1% each, and only 1000 of them are patented, you lose big if you try to market your piece of software. The other big problem is that big companies spend lots of money trying to get patents, just because they know they can make big bucks off them. Little guys can't afford that many court cases even if they know a good portion of the patents held against them are invalid based on documentable prior art, so they give in. This kind of thing is just really starting to happen, and could throw the whole software community into chaos in a few years if it keeps going on its currently wacky course. Stay tuned... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.