[리차드 스톨만 초청 강연회]

Save Free Internet

- 소프트웨어 특허의 문제점 -

일시 : 2000년 6월 18일(일) 오후3시~6시

장소 : 연세대학교 대강당

주최 : 진보네트워크센터

후원 : 연세대학교 총학생회

1. 취 지

○ 최근 리눅스의 급속한 확장에도 불구하고, 리차드 스톨만 자신도 우려

하듯 카피레프트의 사회적 의미는 그만큼 확산되지 못하고 있습니다.

GNU 프로젝트의 창시자인 리차드 스톨만이 Linux가 아니라, GNU/Linux

를 고집하는 것도 GNU/Linux가 단지 우수한 성능의 소프트웨어일 뿐만

아니라 아니라, 상호협력과 자유의 철학에 기반하고 있기 때문입니다.

GNU/Linux가 단지 Linux로 불리며 대중화되고 있는 현 한국사회에서,

리차드 스톨만의 초청 강연이 열리는 것은 카피레프트의 사회적,

철학적 의미를 복원하기 위한 중요한 계기가 되리라고 생각합니다.

○ 특히, 최근 소프트웨어 특허의 일종인 인터넷 비즈니스 모델 특허가

사회적인 논란이 되고 있습니다. 한국에서도 비즈니스 모델 특허의

출원이 봇물처럼 쏟아지고 있으나, 특허청에서는 단지 기업의 이해만을

대변하고 있을 뿐, 인터넷의 생명인 자유로움을 억압할 가능성에

대해서는 수수방관하고 있습니다. 리차드 스톨만도 소프트웨어 특허를

미래의 큰 위험으로 인식하고 있으며, 아마존의 원클릭 특허에 맞서

불매운동을 벌이고 있습니다. 이에 소프트웨어 특허의 문제점에 대한

그의 입장을 들어보는 것은 한국사회의 현실을 비판적으로 바라볼 수

있는 계기가 되리라고 생각합니다.

2. 내용

○ 강연내용 :  소프트웨어 특허의 문제점

3:00 ~ 3:15 개회

3:15 ~ 5:00 리차드 스톨만 강연 (순차통역으로 진행)

5:00 ~ 6:00 질의응답 (순차통역으로 진행)

6:00 폐회

○ 홈페이지 : http://networker.jinbo.net/stallman.html

<번역>

Why patents Are Bad for Software

왜 특허권이 소프트웨어에 부정적인가

SIMON L. GARFINKEL

RICHARd M. STALLMAN

MICHELL KAPOR

특허권은 컴퓨터 소프트웨어를 보호할 수도, 활성화시킬 수도 없다. 단 지, 불구로 만들 수 있을 뿐이다.

1990년 9월경, 유명한 워드프로세서 프로그램인 XyWriter의 이용자들은 프로그램 제작사인 XyQuest 사로부터 기분나쁜 메일을 받았다.

"1987년 6월, 우리는 XyWriteIII Plus 안에 자동교정 및 축약 확대 기능을 도입했다. 우리도 모르는 사이에, 관련된 기술에 대한 특허 신청이 1984년 접수되었고, 이어서 1988년에 특허권을 인정받았다. 특허권을 보유한 회사는 1989년 후반 우리에게 연락해서 그들이 특허권을 가지고 있음을 고지했다.

우리는 특허침해로 인정받지 않을 수 있도록, XyWriteIII Plus를 수정하기로 결정했다. XyWriteIII Plus의 새 버전(3.56)은 이 문제를 설명할 수 있는 두 가지 중대한 변화들을 포함하고 있다. : 오타 후 스페이스바를 눌러 통상의 오타를 자동으로 교정할 수 있는 기능을 당신은 더 이상 사용할 수 없습니다. 또한 당신의 개인 사전에 저장된 축약어를 풀기 위해서는 Ctrl-R 키나 다른 지정된 단축키를 눌러야만 합니다. "

XyQuest는 1980년대 중반 이후 미 특허상표청이 인정한 컴퓨터 알고리즘과 소프트웨어 기술들에 대한 2000개 이상의 특허권 중 하나인 소프트웨어 특허에 의해서 궁지에 몰렸다. 특허권자인 Productivity Software는 XyQuest에게 선택을 요구했다. : 특허에 대한 사용권을 얻든가, 혹은 XyQuest의 대표상품인 XyWrite의 주요 기능을 제거하든가. 만일 XyQuest 가 거부한다면, 값비싼 특허침해 소송이 뒤이을 것이 확실하다.

선택

XyQuest의 마케팅 부사장인 Jim Andelson은 XyQuest사는 특허 라이센스를 취득하려 노력햇으나, Productivity Software 가 계속 요구사항을 바꾸었다고 밝혔다. 처음에 Productive사는 XyWrite의 특정 버전에는 그 기능을 사용할 수 있다고 말했다. 그러더니, XyQuest는 그 "발명'의 한 부분만을 사용할 수 있고, 다른 부분은 안된다고 말을 바꾸었다. 그리고, Productive Software 사는 요구액을 계속 높여갔다. 결국 XyQuest 사는 포기하고 그 기능을 제거하고 말았다.

그래도, XyQuest는 선택권을 지니고 있었다는 점에서 운이 좋았다. 국가에서 가장 크고 이윤이 많은 소프트웨어 제작자들의 일부를 포함한 다른 기업들은 그들 기업의 핵심부를 공격하는 특허 통지를 받은 바 있다. 가장 유명한 사례의 하나는, Refac International 이라는 한 회사가 - 이 회사의 유일한 사업은 특허권을 취득해서 소송을 거는 것이다. - 로터스, 마이크로소프트, Ashton-Tate, 그리고 다른 세 개의 스프레드쉬트 개발사를 상대로 그들이 특허 번호 4,398,249를 침해했다는 소송을 제기한 것이다. 그 특허는 복잡한 모델에서 그 모델의 한 매개변수가 변했을 대 값을 재계산해주기 위한 순서를 명확히 해주는 기술에 대한 것이다. (Refac 은 이후에 로터스를 제외한 다른 회사들에 대해서는 소송을 취하했는데, 이것은 단지 그 회사의 변호사들이 하나의 적을 상대할 때에 성공률이 높다고 보았기 때문이다.)

특허 4,398,249는 스프레드쉬트와 특별한 어떤 관계도 없다２: 그 기술은 어떤 그래픽 포르그램이나 인공지능 프로그램에도 사용된다. 그리고, 스프레드쉬트의 값이 그 특허에 명시된 순서로 재계산되어야 한다는 것은 너무도 명백해서 누가 스프레드쉬트 프로그램을 짜더라도 그렇게 했을 것이다. 그러나, '명확성'에 대한 특허청의 기준은 매우 낮다. : 1년의 프로그램 교육과정에서 답해질 수 있을 정도의 기본적인 아이디어에 대해서도 특허권이 주어져왔던 것이다.

사실상 한달에 한번은 , 광범위하게 사용되는 기본적인 개념에 대해 부여된 또다른 특허에 대한 뉴스들로 컴퓨터 네트워크가 바글바글댄다. 특허청이 아이디어에 대해서는 특허권을 부여하지 않도록 되어있지만, 소프트웨어 특허에 대해서 실지로 그들이 하고 있는 것은 바로 아이디어에 특허권을 부여하고 있는 것이다. 컴퓨터 과학의 지적 영역을 가르고, 출원을 쌓아놓고 있는 회사에게는 사실상 어떤 것도 주지않으면서. 그리고, 이러한 과정은 미국의 소프트웨어 산업을 황페화시키고 있다.

만일 의회가 컴퓨터 프로그램에 대한 특허법의 적용을 빨리 재정의하지 않는다면, 새 컴퓨터 프로그램의 도입에 직면하고 있는 법의 지뢰밭은 매우 위협적이어서-그리고 잠재적으로 매우 값비싼 비용을 치루게 할 것이어서- 작은 회사들은 효과적으로 시장진입이 가로막히게 될 것이다. 반면 크고, 안정된 회사들은 전체 산업을 무력화할 만큼의 영향을 미칠 소송에 휘말리게 될 것이다.

무엇이 특허가 되는가?

소프트웨어 특허권이 모든 프로그램들을 포괄하지는 않는다. ; 대신, 알고리즘이나 기술적인 측면 - 한 프로그램에서 특정 작업을 컴퓨터가 어떻게 수행해야 할지 말해주는 지시들-을 다룬다. 하나의 프로그램은 수천개의 지시들로 구성된다. 그러나 한 프로그램에서 알고리즘과 기법의 독특한 조합은 (책이나 노래처럼) "표현'으로 인정되어 저작권법의 보호를 받는 반면, 알고리즘이나 기법 자체는 특허를 위한 적합한 절차들로 다루어진다.

이러한 '적격성'에 대한 법적 기반은 기껏해야 빈약하기 그지없다. 미국 법은 발명가들에게-그들이 아무리 명석하다 하더라도 - 자연법칙에 대한 특허권을 인정하지 않고 있으며, 두 개의 대법원 판결에서 (Gottschalk v, Benson, 1972 과 Parker v. flook, 1978) 법원은 이 원칙을 컴퓨터 알고리즘과 소프트웨어 기법에도 확장했다. 그러나, 1981년 Diamond v. Diehr 소송에서, 법원은 특정 컴퓨터 알고리즘에 의해서 제어되는 산업적 과정에 특허권이 부여될 수 있다고 판결했으며, 특허청은 알고리즘과 기법의 특허성을 일반적으로 인정하는 판결로 간주했다.

소프트웨어 특허권은 놀라운 속도로 부여되고 있는데, 어떤 통계에 따르면, 매년 천건 이상이 발급되었다. 불행하게도, 특허권의 대부분이 밥-그 자체로는 단순하지만, 많은 복잡한 요리의 핵심 부분이 되는-의 요리법과 같이 명료하고 근본적인 것들이다. (소프트웨어 특허권 중) 많은 것들이 다양한 영역의 프로그램들에 쓰이는 매우 작고 특정한 알고리즘과 기법들을 포괄하고 있다. 종종 특허 출원서에 "발명"이라고 지칭되는 것들이 그것이 출원되었을 당시에 이미 독립적으로 공식화되었거나, 다른 프로그래머에 의해서 이미 사용되고 있던 것들이다.

특허청이 알고리즘이나 기법들에 특허를 부여한다는 것은, 프로그래머들에게 "소유자"의 허락없이, 문제를 풀기위해 특정 방법을 사용하지 말라고 말하는 것이나 마찬가지다. 그들에게 있어서, 알고리즘이나 기법들에 특허권을 부여하는 것은, 일련의 음악 선율이나 화음에 특허를 부여하고 작곡가들에게 "음악적 선율 라이센스"를 구매하라고 강요하는 것이나 마찬가지이다.

서로 충돌하는 시스템

특허권에 대한 전통적인 존재이유는, 발명의 보호는 혁신을 불러일으키고, 기술적 진보에 대한 정보 확산에 도움을 준다는 것이다. 다른 사람들이 발명을 복제하는 것을 금지함으로써, 특허는 발명가들에게 개발과정에서의 투자를 보상하게 하며, 동시에 새 발명의 성과를 공중에 공개하는 것이다.

그러나, 특허 제도가 컴퓨터 산업에 있어서는 역효과를 가져온다는 증거가 있다. ; 정말로, 특허 제도 그 자체가 소프트웨어 개발의 특성과 맞지 않는 듯하다. 오늘날의 컴퓨터 프로그램들은 매우 복잡해서 말그대로 수천개의 알고리즘과 기법들로 이루어져 있는데, 이들 각각은 특허청의 기준에 의한다면 특허가 인정될 수 있는 것들이다. 한 소프트웨어 회사가 그러한 특허들을 모두 라이센스한다는 것이 타당한가? 혹은 그렇게 법률적으로 위험한 상품을 시장에 내놓는 것이 타당한가? 더욱 상황이 복잡하게도, 특허청은 특별한 기능을 구현하는 알고리즘과 기법의 조합 또한 특허로 인정하였다. 예를 들어, 애플(Apple)사는 자사의 Hypercard 프로그램이 특허 제 4,736,308을 위반한 혐의로 고소를 당했는데, 그 특허는, 간단히 말해서, 텍스트의 각 라인의 선택된 부분을 보여주는(display) 데이터베이스를 통해 스크롤링(scrolling)을 구현하는 특정한 기법에 대한 것이다. 스크롤링과 디스플레이 기능 각각은 컴퓨터 프로그램에서 일상화된 수법이지만, 특허 4,736,308의 특허권자로부터 허가없이 그것을 결합하는 것은 이제 명백하게 불법이 되었다.

소프트웨어 특허에 있어서 또 다른 문제점은, 특허 취득까지 걸리는 시간이 오래 걸린다는 것이다. 예를 들어, 20년 이상 변하지 않아왔던 Valium 제조법에 대한 특허가 있는 회사의 경우에는, 2년에서 5년이 걸리는 특허 청구에서 취득까지의 기간이 수용할만 하다. 그러나, 소프트웨어 업계에선 새로운 버젼의 프로그램을 출시하지 않는 업체는 시장에서 퇴출될 수 밖에 없다. 그들의 성공은 수요를 간파하고, 가능한 한 빨리 해결책을 개발할 수 있느냐에 달려있다.

불행하게도, 특허 검색을 수행하는 것은 느리고, 신중한 과정이며, 그래서 소프트웨어 개발에 이용이 될 때는, 개발 과정에서 혁신을 가로막을 수 있다. 그리고, 특허 출원은 비밀리에 이루어지므로, 컴퓨터 프로그래머가 자신이 작성한 것이 아직 공포되지 않은 어떤 특허를 위반하지 않았는지 확신할 수 있는 어떤 방법도 없다. 그래서, XyQuest 사는 Productivity Software사가 출원을 신청하고 특허권을 취득하는 시간 사이에, 자사의 자동 오타교정 시스템을 "재개발"하고 시장에 제품을 내놓았던 것이다.

그러한 예들은 점점 일반화되고 있다. 또 다른 예로, IEEE Computer 라는 잡지는 지난 1984년 6월호에서 데이터 압축을 실행하는 효과적인 알고리즘을 발표했다. 저널의 독자와 편집진들 모르게, 그 기사의 필자들은 그들의 발명에 대한 특허를 동시에 신청했다. 다음해에, 소위 "LZW 데이터 압축"을 실행하는 수많은 프로그램들이 만들어지고 배포되었다. 그 압축 시스템은 심지어 국가 표준으로 채택이 되었으며, 국제적 기준으로 제안되었다. 그리고, 1985년, 특허청은 그 글의 저자들의 한명에게 특허 4,558,302를 부여하였다. 현재 특허권자인 Unisys는 그 알고리즘의 사용에 대해 로열티를 요구하고 있다. 비록 그 알고리즘을 포함한 프로그램들은 아직 공공 자산으로 남아있지만, 그 프로그램들을 사용하는 것은 소송의 위험을 감수해야함을 의미한다.

특허 승인 과정이 느릴뿐만 아니라, 소프트웨어 영역에서 '선행기술'- 특허 출원 당시에 발명이 이미 존재하는지에 대해 특허청이 판단하는 기준-을 검색하는 것은 거의 불가능하다. 25년 이상, 특허청은 알고리즘과 기법에 대한 특허 분류 시스템을 개발하지 못하고 있으며, 그러한 시스템이 실현가능하지도 않다. 마치 수학자가 때때로 본질적으로 동일한 정식적 과정이 수학의 다른 영역에서 다른 용어아래 사용되고 있다는 것을 인식하지 못하는 것처럼, 컴퓨터 과학 내의 서로 다른 영역들도 종종 다른 목적을 위해서 같은 알고리즘을 다시 개발한다. 시간에 쫒기는 특허 심사관이 모든 중복된 부분을 인식하기를 기대하는 것은 불합리하다. 예를 들어, IBM 사는 Unisys가 소유한 것과 동일한 데이터 압축 알고리즘에 대해 특허를 발급받았다. 특허청은 아마도 똑같은 알고리즘에 대해 두개의 특허를 부여했다는 것을 깨따지 못했을 것이다. 왜냐하면, 수학적으로는 동일한 공식을 사용했을지라도, 각 특허의 요약 자체는 매우 상이하기 때문이다.

컴퓨터 과학 문헌들이 믿기지 않을 만큼 방대하다는 사실로 인해, 선행기술에 대한 탐색은 매우 복잡하다. 그것은 학술잡지 뿐만 아니라, 이용자 메뉴얼, 공개된 소스코드, 그리고 컴퓨터 광들을 위한 잡지에 있는 대중적 해설도 포함한다. 주요 대학에서 연구하는 한 화학공학팀이 해마다 20-30 페이지 분량의 논문을 생산하는 반면, 프로그래머들은 그 보다 몇백배 많은 분량을 쉽게 생산한다. 알고리즘과 기법의 조합에 부여된 특허의 경우, 상황은 더욱 복잡해진다. 프로그래머들은 종종 새로운 알고리즘과 기법들을 발표하지만, 과거의 것을 조합하는 새로운 방식에 대해서는 거의 발표를 하지 않는다. 과거에 개별적인 알고리즘과 기법들은 수많은 다른 방식으로 조합되어 왔음에도 불구하고, 그 역사를 확립할 수 있는 좋은 방법이 없다.

심사관이 선행기술을 발견할 수 없다면, 거의 특허를 내줄 수 밖에 없기 때문에, 선행 기술을 완전히 검색하는 것이 불가능하다는 것은 매우 중요한 문제이다. 그 결과 특허청의 정의에 의하더라도 "독창적"이지 않은 수많은 특허들에 특허권이 부여되었고, 법원에서 성공적으로 보호될 수 있었다. 그것은 단지 심사관이나 법정에서의 피고나 선행기술의 존재를 알지 못한다는 것 때문이다.

상업 소프트웨어 공동체의 몇몇 회원들은 현재 1980년 이전에 존재했던 소프트웨어의 선행 기술을 확인하기 위해 "소프트웨어 특허 기관"의 설립을 제안하고 있다. 그러나, 설사 그러한 기관이 미국의 모든 프로그래머들에 의해서 만들어진 모든 발견을 목록화하더라도, 단지 1980년 이전의 작품만을 공공영역이라고 임의적으로 선언하는 것은 말이 되지 않는다. 게다가, 그 목적이 무엇이란 말인가? 자연의 수학적 법칙에 특허를 부여하기 위해서?

사업측면에서의 부정성

특허가 사전에 알려졌을 경우에도, 소프트웨어 제작자들은 일반적으로 그 알고리즘과 기법들에 대해서 라이센스를 받지 않아왔다. 대신, 그들은 특허에 명시되어있는 특정한 과정의 사용을 피하기 위해 그들 프로그램을 수정하려고 노력한다. 때때로 이것은 불가능한데, 이런 경우 종종 회사들은 새로운 기능을 모두 구현하는 것을 피하는 것을 선택해왔다. 지난 몇년간의 증거로 보았을 때, 소프트웨어 특허가 새로운 기술을 촉진시킨다기 보다는 실제적으로 새로운 기술을 채택하는 것을 막아왔다는 것이 명백해 보인다.

그리고, 소프트웨어 특허는 혁신 또한 촉진하지 않는 것 같다. 종종 소프트웨어 개발의 전위를 형성하지만, 특허검색이나 소송 비용을 감당할 수 없는 작은 회사들에게 소프트웨어 특허는 상당한 위험을 부여한다. 새로운 상품을 프로그램하는 것은 수십만 달러의 비용이 든다. ; 새로운 프로그램이 사용하는 각 기법이나 기법들의 조합에 대한 특허 검색 비용은 그와 같거나 그것을 초과하기 쉽다. 그리고, 하나의 특허 소송 비용은 백만달라 이상이다.

"나는 특허 소송에 드는 것보다, 더 비용이 많이 드는 소송은 한번도 보지 못했다" 라고 WordPerfect Co. 의 자문이사 겸 부사장인 R.Duff Thompson는 밝혔다. 하지만, Tompson이 가장 걱정하는 것은 지금까지 소프트웨어 산업의 창조력의 원천이었던 젊고, 자신감에 넘치는 프로그래머들을 소프트웨어 특허가 고사시키지 않을까 하는 것이다. Tompson은 말한다. "소프트웨어에 관한 굉장한 아이디어를 가지고 있는 23살의 한 젊은이가 특허권자의 요구 편지를 받고 좌절하는 상황을 상상해보세요"

정보의 교환이라는 측면에서 보자면, 소프트웨어 특허의 확장은 대학에서 개발되고 무료로 배포되는 소프트웨어 - 몇년동안 대학, 회사, 정보의 컴퓨터 사용자들의 기반이 되어왔던 소프트웨어-의 종말을 의미한다. 많은 그러한 프로그램들-X 윈도 시스템, EMACS 문서 편집기, 파일 압축 유틸리티인 "compress", 그외 많은 프로그램들-이 현존하는 특허권들을 위반한 것으로 보인다. 특허권은 또한 학교에서 컴퓨터를 사용가능하게 하는데 있어서 중요한 역할을 해왔던 공공 소프트웨어의 종말을 의미한다. 프로그램을 무료로 배포하려는 저작자가 그 프로그램을 만드는데 사용된 수백개의 기법들 중 하나가 특허가 부여된 것일 때, 로열티를 지불하기 위한 협상을 해야한다는 것은 명백하게 말이되지 않는다.

특허가 그들의 사업에 필요하다고 믿는 프로그래머나 기업가는 거의 없다. 대신, 알고리즘과 기법에 대한 특허에 대한 욕구는 두가지 외부적인 요소로부터 발생한다. 더 나은 제품을 개발하지 않고도 경쟁자를 이길 수 있는 방법으로 특허권을 바라보는 대기업의 간부와 자신의 사업을 크게 확장시킬 수 있는 잠재력으로 특허권을 바라보는 변리사들이다.

오늘날, 회사들이 수행하는 대부분의 특허는 협상할 때 쓰기 위한 것이거나 혹은 다른 특허 침해 소송에 대항하여 방어하기 위한 것이다. 소프트웨어를 특허받는 것은 경쟁적 입지를 강화시켜준다고 변호사들은 총고하고 있다. 이러한 접근이 마이크로소프트나 애플, 그리고 IBM 같은 큰 기업에게는 타당할지 모르나, 작은 기업이나 심지어 중간 정도의 기업에게는 타당하지 않다. 미래의 신생 기업들은 거인들이 부과하는 어떠한 가격도 지불하도록 강제당할 것이다.

저작권과 영업비밀

소프트웨어 특허의 필요성을 반박하는 가장 좋은 논거는 역사 그 자체일 것이다. 로터스, 마이크로소프트, 워드퍼펙트, 그리고 노벨은 모두 소프트웨어 제작 산업에서 그들 제품에 힘입어 세계적인 선도자가 되었다. 이들 회사 중 누구도 자금 확보나 시장 지위를 유지하기 위해 특허를 필요로 하지 않았다. 그들 모두는 현재의 소프트웨어 특허 붐이 시작되기 전에 그들의 부를 만들어내었다. 컴퓨터 프로그램의 발전을 보증하기위해 특허가 필요한 것은 아니라는 것은 명백하다. 그리고, 그들의 자산으로 생각되는 것을 더욱 확실하게 보장하기를 원하는 자들을 위해, 컴퓨터 산업은 두개의 다른 시스템을 이미 채택하였다. : 그것은 저작권과 영업비밀이다.

오늘날 거의 모든 프로그램에 저작권이 인정되고 있다. 저작권은 소프트웨어 프로그램의 이용자가 프로그램에 대한 권한을 가지고 있는 개인이나 회사의 허가없이 (예를 들어, 친구에게 주기위해) 그것을 복사하는 것을 금지한다. 저작권은 한 회사가 다른 회사의 작품을 사용하여 자기가 만든 것처럼 파는 것을 금지한다. 그러나, 저작권의 존재가 프로그래머로 하여금 그들의 작품에 어떤 프로그램의 알고리즘이나 기법을 사용하는 것을 금지하는 것은 아니다. 하나의 소프트웨어 기법은 완전히 다른 작업을 하기위해 다른 방식으로 시행될 수 있다. ; 저작권은 단지 특정한 프로그래머가 작성한 코드 자체를 사용하는 것을 금지할 뿐이다.

일반적으로 저작권과 특허는 서로 매우 다른 종류의 대상에 적용된다고 생각되었다. ; 저작권이 '아이디어의 표현'에 적용된다면, 특허는 '어떤 결과를 얻기위한 과정'에 적용된다. 단지 몇년 전까지만 해도, 컴퓨터 알고리즘과 기법은 특허될 수 없는 것으로 널리 인식되어왔다. 그리고, 하버드 대학 정책 분석가인 Brian Kahin의 기록에 의하면, 저작권이 널리 정착된 산업이 갑자기 특허의 영향하에 놓이게 된 것은 역사상 처음있는 일이다.

실로, 의회나 대법원의 의식적인 행동없이, 소프트웨어 생산의 가장 기본적인 원칙-즉, 당신이 프로그램을 만들었다면, 그것은 당신의 것이다-이 변할 것이다. 새로운 원칙은 다음과 같은 것이다. 당신은 당신이 작성한 것을 소유할 수 있다. - 만일 그것이 과거의 작품으로부터 어떠한 것도 가져오지 않을만큼 혁명적인 것이라면. 소프트웨어 외 영역의 어떠한 작가도 그렇게 비현실적으로 높은 기준을 지킬 수는 없다.

미국 특허 시스템의 형성은 특허가 영업비밀을 위축시켰으면 하는 미 헌법 고안자의 희망에 기인한다. 기술들이 상업적 이익을 위해 비밀로 유지된다면, 그것들은 다른 사람이 사용할 수 있도록 결코 알려지지 않을 것이며, 심지어 유실될 수도 있다. 그러나, 다른 영역에서처럼, 소프트웨어에서도 영업비밀이 문제일 수 있지만, 특허가 그 문제를 교정할 수는 없다.

소프트웨어 영역에서의 유영한 개발의 상당수는 XyWrite Ⅲ Plus 의 자동교정 및 축약어 확장기능처럼 새로운 기능으로 구성되어있다. 프로그램의 기능을 그 프로그램의 사용자로부터 감추는 것이 불가능하기 때문에, 영업비밀의 가능성이 없으며, 그래서 영업비밀을 막기위한 어떠한 조치를 할 필요가 없다. 소프트웨어 시스템에서 내부적으로 사용되는 기법은 비밀로 유지될 수 있다. ; 그러나 과거에는 중요한 것들은 거의 그렇게 되지 않았다. 학문세계와 마찬가지로 상업 영역에서도 컴퓨터 과학자들이 그들의 발견을 공표하는 것은 일반적인 일이다. 다시한번 말하자면, 기법에 대한 비밀은 중요한 문제가 아니었기 때문에, 그것을 무력화시키기 위해 특허 시스템을 채택하여 얻을 것이 아무것도 없다.

소프트웨어에서 영업비밀이 광범위하게 사용되는 영역은 프로그램의 "원시 코드"에서이다. 컴퓨터 프로그래밍에서, 영업비밀은 프로그램을 "기계코드"-컴퓨터가 읽어들이는, 프로그램 언어의 실제로 판독불가능한 번역인-로 배포하는 것에 의해서 유지된다. 다른 프로그래머가 기계 코드로부터 원 저작자가 쓴 원래 과정을 따라간다는 것은 극히 어렵다. 그러나, 소프트웨어 특허는 영업비밀의 이러한 형태를 제한하는 것과 어떠한 관계도 없다. 소스코드를 감춤으로써, 회사는 특정한 기법이 아니라 전체 시스템을 위한 디자인을 생산하기 위해 수많은 기법들을 조합하는 방식에 대한 비밀을 유지할 수 있다. 전체 디자인을 특허내는 것은 현실적이지도 효과적이지도 않다. 소프트웨어 특허를 가지고 있는 회사들조차 아직 기계코드로만 프로그램을 배포하고 있다. 따라서, 어떠한 영역에서도 소프트웨어 특허가 영업비밀을 두드러지게 감소시키고 있지는 않다.

방향을 돌려라

많은 정책입안자들은 지적재산권 보호를 강화시키는 것은 그 영역의 누구에게나 이롭다고 가정한다. 우리가 밝히려고 한 바와같이, 컴퓨터 프로그램 영역에서 이것은 확실히 진실이 아니다. 거의 모든 프로그래머들은 그들이 일을 할 수 있는 능력과 표현의 자유를 제한하는 달갑지않은 방해로 특허를 바라보고 있다.

이러한 점에서, 아주 많은 특허들이 특허상표청에 의해 발급되었기 때문에, 선행기술을 발견함으로써, 한번에 하나씩, 그것을 제압하겠다는 전망은 거의 생각할 수 없다. 설사 특허청이 미래에 소프트웨어에 대해서 더 잘 이해한다고 하더라도, 현재 행해진 오류들은 극적인 정책 변환이 없는 한, 다음 세기에도 이어질 것이다.

최근 미 특허상표청은 특허법 개정에 관련된 자문 위원회를 설립했다. 이 자문위원회는 많은 문제를 검토하게 되는데, 여기에는 소프트웨어 특허 -그들은 "컴퓨터 프로그램 관련 발명"에 관한 특허라고 부르는 것을 선호한다-가 포함된다. 불행하게도 이 위원회의 소프트웨어에 관한 소위원회는 소프트웨어 특허에 의문을 표해왔던 유명한 소프트웨어 산업의 대표자들 중 누구도 포함하고 있지 않다. 그러나, 그 소위원회는 공공의 의견을 고려해야만 한다. 그 위원회의 마지막 보고서는 1992년 8월까지는 완료되지 않으므로, 아직 누군가 의견을 표할 시간은 있다.

특허청에 영향력을 미치는 것이 어떤 이득을 줄 수도 있겠지만, 진정으로 필요한 개혁은 대법원이나 의회에 개입하는 방식으로밖에 이루어질 것 같지 않다. 법원의 결정을 기다리는 것은 답이 아니다. ; 누구도 대법원이 관련 판결을 재결정하도록 강제할 수 없으며, 법원이 특허청의 실행을 변화시키는 판결을 하거나, 기존 특허에 관해 어떠한 것을 판결하리라는 보장이 없다. 그러므로, 가장 효과적인 실천 전략은 소프트웨어 특허를 불허하고, 가능하다면, 이미 특허받은 것을 무효화시키도록 특허법을 개정하라고 의회에 촉구하는 것이다. Willian J. Hughes(D-N.J.) 가 의장으로 있는 지재권에 관한 백악관 소위원회와 법무부는 그 주제에 대한 공청회를 계획하고, 의회가 후원하는, 소프트웨어 특허가 산업에 미치는 영향에 대한 경제적 분석을 요구함으로써 이 문제의 해결에 앞장서야 한다.

컴퓨터 산업은 특허없이도 활발하고 건강하게 성장했다. 소프트웨어 특허를 원하는 누군가가 그것이 건강한 산업발전에 필요함을 증명하지 못한다면, 의회는 혁신에 대한 이 장벽을 제거하는 것이 정당하다고 판단해야만 한다.

추천 문서

Brian Kahin, "The Software Patent Crisis," Technology Review (April 1990): 53-58.

Mitchell Kapor, Testimony at Hearings before U.S. House of Representatives, Subcommittee on Courts, Intellectual Property and the Administration of Justice, of the Committee on the Judiciary (March 5,1990).

Pamela Samuelson, "Benson Revisited: Should Patent Protection Be Available for Algorithms and Other Computer Program-Related Inventions?" Emory Law Journal(Fall 1990): 1025-1154.

Pamela Samuelson, "Should Program Algorithms Be Patented?" Communications of the ACM (August 1990):23-27.

Simson Garfinkel is a senior editor at NeXTWORLD magazine (San Francisco) and the coauthor of the book Practical UNIX Security.

Richard M. Stallman is one of the founders of the League for Programming Freedom (Cambridge, Massachusetts) and the recipient of the Association for Computing Machinery's Grace Hopper Award.

Mitchell Kapor, a founder of the Lotus Development Corporation, is president of the Electronic Frontier Foundation (Cambridge,Massachusetts).

Quotes:

The Patent Office is carving up the intellectual domain of computer science and handing little pieces to any company that files anapplication. The most effective course of action is to encourage Congress to amend patent law to disallow software patents.

<원문>

From Issues in Science and Technology, Fall 1991:

SIMSON L. GARFINKEL

RICHARD M. STALLMAN

MITCHELL KAPOR

Why Patents Are Bad for Software

Patents can't protect or invigorate the computer software

industry; they can only cripple it.

In September 1990, users of the popular XyWrite word processing

program got a disturbing letter in the mail from XyQuest, Inc., the

program's publisher:

"In June of 1987, we introduced an automatic correction and

abbreviation expansion feature in XyWrite III Plus.  Unbeknownst to us,

a patent application for a related capability had been filed in 1984

and was subsequently granted in 1988.  The company holding the patent

contacted us in late 1989 and apprised us of the existence of their

patent.

We have decided to modify XyWrite III Plus so that it cannot be

construed as infringing.  The newest version of XyWrite III Plus (3.56)

incorporates two significant changes that address this issue: You will

no longer be able to automatically correct common spelling errors by

pressing the space bar after the misspelled word.  In addition, to

expand abbreviations stored in your personal dictionary, you will have

to press control-R or another designated hot key."

XyQuest had been bitten by a software patent--one of the more than

two thousand patents on computer algorithms and software techniques

that have been granted by the U.S.  Patent and Trademark Office since

the mid-1980s.  The owner of the patent, Productivity Software, had

given XyQuest a choice: license the patent or take a popular feature

out of XyWrite, XyQuest's flagship product.  If XyQuest refused, a

costly patent-infringement lawsuit was sure to follow.

Some choice.

XyQuest tried to license the patent, says Jim Adelson, vice

president for marketing, but Productivity Software kept changing its

terms.  First Productivity said that XyQuest could keep the feature in

some versions of XyWrite, but not in others.  Then the company said

that XyQuest could use one part of the "invention," but not other

parts.  And Productivity Software kept increasing the amount of money

it wanted.  XyQuest finally gave up and took the feature out.

XyQuest was lucky it had that option.  Other firms--including some of

the nation's largest and most profitable software publishers--have

been served with notice of patents that strike to the heart of their

corporate vitality.  In one of the most publicized cases, a company

called Refac International--whose sole business is acquiring and

litigating patents--sued Lotus, Microsoft, Ashton-Tate, and three

other spreadsheet publishers, claiming they had all infringed on

patent number 4,398,249, which spells out the order in which to

recalculate the values in a complicated model when one parameter in

the model changes.  (Refac has since dropped its claims against all the

companies except Lotus, but only because company lawyers anticipated a

better chance of success if they faced just one opponent.)

Patent 4,398,249 does not have anything to do with spreadsheets in

particular; the technique also appears in some graphics drawing and

artificial intelligence programs.  And the idea that values in a

spreadsheet should be recalculated in the order specified by the

patent is so obvious that it has probably occurred to nearly everyone

who has written a spreadsheet program.  But the Patent Office's

standard for obviousness is extremely low; patents have been granted

for ideas so elementary that they could have been answers to problems

in a first-year programming course.

Practically once a month, the nation's computer networks are abuzz

with news of another patent issued on a fundamental concept that is

widely used.  Although the Patent Office isn't supposed to grant

patents on ideas, that's essentially what it's doing with software

patents, carving up the intellectual domain of computer science and

handing little pieces to virtually any company that files an

application.  And the practice is devastating America's software

industry.

If Congress does not act quickly to redefine the applicability of

patent law to computer programs, the legal minefield confronting the

introduction of new computer programs will be so intimidating--and

potentially so costly--that small companies will effectively be barred

from the marketplace, while large, established firms will become

embroiled in litigation that will have a stultifying effect on the

entire industry.

What's being patented?

Software patents do not cover entire programs; instead, they cover

algorithms and techniques--the instructions that tell a computer how

to carry out a specific task in a program.  Thousands of instructions

make up any one computer program.  But whereas the unique combination

of algorithms and techniques in a program is considered an

"expression" (like a book or a song) and is covered by copyright law,

the algorithms and techniques themselves are treated as procedures

eligible for patenting.

The judicial basis for this eligibility is tenuous at best.  U.S. law

does not allow inventors, no matter how brilliant they are, to patent

the laws of nature, and in two Supreme Court cases

(Gottschalk v. Benson, 1972, and

Parker v. Flook, 1978) the Court extended this

principle to computer algorithms and software techniques.  But in the

1981 case Diamond v. Diehr, the Court said

that a patent could be granted for an industrial process that was

controlled by certain computer algorithms, and the Patent Office seems

to have taken that decision as a green light on the patentability of

algorithms and techniques in general.

Software patents are now being granted at an alarming rate--by some

counts, more than a thousand are issued each year.  Unfortunately, most

of the patents have about as much cleverness and originality as a

recipe for boiled rice--simple in itself but a vital part of many

sophisticated dishes.  Many cover very small and specific algorithms or

techniques that are used in a wide variety of programs.  Frequently the

"inventions" mentioned in a patent application have been independently

formulated and are already in use by other programmers when the

application is filed.

When the Patent Office grants a patent on an algorithm or technique,

it is telling programmers that they may not use a particular method

for solving a problem without the permission of the idea's "owner." To

them, patenting an algorithm or technique is like patenting a series

of musical notes or a chord progression, then forcing composers to

purchase a "musical sequence license."

Systems at odds

The traditional rationale for patents is that protection of inventions

will spur innovation and aid in the dissemination of information about

technical advances.  By prohibiting others from copying an invention,

patents allow inventors to recoup their investment in development

while at the same time revealing the workings of the new invention to

the public.

But there's evidence that the patent system is backfiring in the

computer industry; indeed, the system itself seems unsuited to the

nature of software development.  Today's computer programs are so

complex that they contain literally thousands of algorithms and

techniques, each considered patentable by the Patent Office's

standards.  Is it reasonable to expect a software company to license

each of those patents, or even to bring such a legally risky product

into the marketplace? To make things even more complicated, the Patent

Office has also granted patents on combinations of algorithms and

techniques that produce a particular feature.  For example, Apple was

sued because its Hypercard program allegedly violates patent number

4,736,308, which covers a specific technique that, in simplified

terms, entails scrolling through a database displaying selected parts

of each line of text.  Separately, the scrolling and display functions

are ubiquitous fixtures of computer programming, but combining them

without a license from the holder of patent 4,736,308 is now

apparently illegal.

Another problem with patenting software is the amount of time it

takes to do so.  The two to five years required to file for and obtain

a patent are acceptable if a company is patenting, say, the formula

for Valium, which hasn't changed in more than 20 years.  But in the

software industry, companies that don't continually bring out new

versions of their programs go out of business.  Success for them

depends on spotting needs and developing solutions as quickly as

possible.

Unfortunately, conducting a patent search is a slow, deliberative

process that, when harnessed to software development, could stop

innovation in its tracks.  And because patent applications are

confidential, there is simply no way for computer programmers to

ensure that what they write will not violate some patent that is yet

to be issued.  Thus XyQuest "reinvented" its automatic spelling-error

correction system and brought the product to market between the time

that Productivity Software had filed for its application and been

awarded the patent.

Such examples are becoming increasingly common.  In another case, the

journal IEEE Computer in June 1984 published a

highly efficient algorithm for performing data compression;

unbeknownst to the journal's editors or readers, the authors of the

article had simultaneously applied for a patent on their invention.  In

the following year, numerous programs were written and widely

distributed for performing the so-called "LZW data compression." The

compression system was even adopted as a national standard and

proposed as an international one.  Then, in 1985, the Patent Office

awarded patent number 4,558,302 to one of the authors of the article.

Now Unisys, the holder of the patent, is demanding royalties for the

use of the algorithm.  Although programs incorporating the algorithm

are still in the public domain, using these programs means risking a

lawsuit.

Not only is the patent approval process slow, but the search for

"prior art"--the criterion the Patent Office uses to determine whether

an invention already exists at the time of a patent application--is

all but impossible to conduct in the realm of computer software.  After

more than 25 years, the Patent Office has not developed a system for

classifying patents on algorithms and techniques, and no such system

may be workable.  Just as mathematicians are sometimes unaware that

essentially identical mental processes are being used in separate

areas of mathematics under different terminology, different parts of

computer science frequently reinvent the same algorithm to serve

different purposes.  It is unreasonable to expect that a patent

examiner, pressed for time, would recognize all such duplication.  For

example, IBM was issued a patent on the same data-compression

algorithm that Unisys supposedly owns.  The Patent Office was probably

not aware of granting two patents for the same algorithm because the

descriptions in the patents themselves are quite different even though

the formulas are mathematically equivalent.

The search for prior art is complicated by the fact that the

literature of computer science is unbelievably large.  It contains not

only academic journals, but also users' manuals, published source

code, and popular accounts in magazines for computer enthusiasts.

Whereas a team of chemists working at a major university might

produce 20 or 30 pages of published material per year, a single

programmer might easily produce a hundred times that much.  The

situation becomes even more complex in the case of patented

combinations of algorithms and techniques.  Programmers often publish

new algorithms and techniques, but they almost never publish new ways

of combining old ones.  Although individual algorithms and techniques

have been combined in many different ways in the past, there's no good

way to establish that history.

The inability to search the literature thoroughly for prior art is

crucial, because unless an examiner can find prior art, he or she is

all but obligated to issue the patent.  As a result, many patents have

been granted--and successfully defended in court--that are not

"original," even by the Patent Office's definition.  It was simply the

case that neither the patent examiner nor the defendants in the

lawsuit knew of the prior art's existence.

Some members of the commercial software community are now proposing

the creation of a "Software Patent Institute" to identify software's

prior art that existed before 1980.  But even if such an institute

could catalogue every discovery made by every programmer in the United

States, it makes no sense to arbitrarily declare that only pre-1980

work is in the public domain.  Besides, what would be the purpose? To

allow the patenting of nature's mathematical laws?

Bad for business

Even when patents are known in advance,

software publishers have generally not licensed the algorithms or

techniques; instead, they try to rewrite their programs to avoid using

the particular procedure that the patent describes.  Sometimes this

isn't possible, in which case companies have often chosen to avoid

implementing new features altogether.  It seems clear from the evidence

of the last few years that software patents are actually

preventing the adoption of new technology,

rather than encouraging it.

And they don't seem to be encouraging innovation, either.  Software

patents pose a special danger to small companies, which often form the

vanguard of software development but can't afford the cost of patent

searches or litigation.  The programming of a new product can cost a

few hundred thousand dollars; the cost of a patent search for each

technique and combination of techniques that the new program uses

could easily equal or even exceed that.  And the cost of a single

patent suit can be more than a million dollars.

"I'm not familiar with any type of ligation that is any more costly

than patent litigation," says R. Duff Thompson, vice president and

general counsel of the WordPerfect Corporation.  But Thompson's

greatest fear is that software patents will wipe out young,

independent programmers, who until now have been the software

industry's source of inspiration.  Imagine what happens, says Thompson,

when "some 23-year-old kid who has a terrific idea in a piece of

software is hammered by a demand letter from someone holding a

patent."

As for aiding the exchange of information, the expansion of software

patents could mean instead the end of software developed at

universities and distributed without charge--software that has been a

mainstay of computer users in universities, corporations, and

government for years.  Many such programs--the X Window system, the

EMACS text editor, the "compress" file-compression utility, and

others--appear to be in violation of existing patents.  Patents could

also mean an end to public-domain software, which has played an

important part in making computers affordable to public schools.  There

is obviously no way that an author who distributes a program for free

could arrange to pay for royalties if one of the hundreds of

techniques that were combined to create the program happens to be

patented.

Few programmers and entrepreneurs believe that patents are necessary

for their profession.  Instead, the impetus for patents on algorithms

and techniques comes from two outside sources: managers of large

companies, who see patents as a means for triumphing over their

competitors without having to develop superior products, and patent

attorneys, who see the potential for greatly expanding their business.

Today, most patenting by companies is done to have something to

trade or as a defense against other patent-infringement suits.

Attorneys advise that patenting software may strengthen competitive

position.  Although this approach will work for large companies such as

Microsoft, Apple, and IBM, small and even mid-sized companies can't

play in their league.  A future startup will be forced to pay whatever

price the giants choose to impose.

Copyright and trade secrecy

The best argument against the wisdom of software patents may be

history itself.  Lotus, Microsoft, WordPerfect, and Novell all became

world leaders in the software publishing industry on the strength of

their products.  None of these companies needed patents to secure

funding or maintain their market position.  Indeed, all made their

fortunes before the current explosion of software patents began.

Clearly patents are not necessary to ensure the development of

computer programs.  And for those who want more control over what they

see as their property, the computer industry has already adopted two

other systems: copyright and trade secrecy.

Today, nearly all programs are copyrighted.  Copyright prohibits the

users of a software program from making copies of it (for example, to

give to their friends) without the permission of the individual or

company that licenses the program.  It prevents one company from

appropriating another company's work and selling it as its own.  But

the existence of a copyright doesn't prevent other programmers from

using algorithms or techniques contained in the program in their own

work.  A single software technique can be implemented in different ways

to do totally different jobs; copyright only prohibits appropriating

the actual code that a particular programmer wrote.

In general, copyrighting and patenting are thought to apply to very

different kinds of material: the former to the expression of ideas,

and the latter to a process that achieves a certain result.  Until just

a few years ago, computer algorithms and techniques were widely seen

as unpatentable.  And as Harvard University policy analyst Brian Kahin

notes, this is the first time in history that an industry in which

copyright was widely established was suddenly subjected to patenting.

Indeed, without conscious action by Congress or the Supreme Court,

the most fundamental rule of software publishing--if you write a

program, you own it--will change.  The new rule will be that you might

own what you write--if it is so revolutionary that it owes nothing to

any previous work.  No author in areas other than software is held to

such an unrealistically high standard.

The U.S. patent system was created because the framers of the

Constitution hoped that patents would discourage trade secrecy.  When

techniques are kept secret for commercial advantage, they may never

become available for others to use and may even be lost.  But although

trade secrecy is a problem for software, as it is for other fields, it

is not a problem that patents help to correct.

Many of the useful developments in the field of software consist of

new features such as the automatic correction and abbreviation

expansion feature in XyWrite III Plus.  Since it is impossible to keep

a program's features secret from the users of the program, there is

no possibility of trade secrecy and thus no need for measures to

discourage it.  Techniques used internally in a software system can be

kept secret; but in the past, the important ones rarely were.  It was

normal for computer scientists in the commercial as well as the

academic world to publish their discoveries.  Once again, since secrecy

about techniques was not a significant problem, there is little to be

gained by adopting the patent system to discourage it.

The place where trade secrecy is used

extensively in software is in the "source code" for programs.  In

computer programming, trade secrets are kept by distributing programs

in "machine code," the virtually indecipherable translation of

programming languages that computers read.  It is extremely difficult

for another programmer to glean from a machine-code program the

original steps written by the program's author.  But software patents

haven't done anything to limit this form of trade secrecy.  By

withholding the source code, companies keep secret not a particular

technique, but the way that they have combined dozens of techniques to

produce a design for a complete system.  Patenting the whole design is

impractical and ineffective.  Even companies that have software patents

still distribute programs in machine code only.  Thus, in no area do

software patents significantly reduce trade secrecy.

Reversing direction

Many policymakers assume that any increase in intellectual property

protection must be good for whoever works in the field.  As we've tried

to show, this is assuredly not the case in the field of computer

programming.  Nearly all programmers view patents as an unwelcome

intrusion, limiting both their ability to do their work and their

freedom of expression.

At this point, so many patents have been issued by the Patent and

Trademark Office that the prospect of overturning them by finding

prior art, one at a time, is almost unthinkable.  Even if the Patent

Office learns to understand software better in the future, the

mistakes that are being made now will follow the industry into the

next century unless there is a dramatic turnaround in policy.

The U.S. Patent and Trademark Office recently established an

Advisory Commission on Patent Law Reform that is charged with

examining a number of issues, including software patents--or what it

prefers to call patents on "computer-program-related inventions."

Unfortunately, the commission's subcommittee on software does not

include any prominent software industry representatives who have

expressed doubts about software patents.  But the subcommittee is

required to consider public comment.  The commission's final report is

not due until August 1992, so there is still time to make one's voice

heard.

Although influencing the Patent Office might produce some benefits,

the really necessary reforms are likely to come only through

intervention by the Supreme Court or Congress.  Waiting for Court

action is not the answer: No one can force the Supreme Court to rule

on a relevant case, and there is no guarantee that the Court would

decide to change Patent Office practice or to do anything about

existing patents.  The most effective course of action, therefore, is

to encourage Congress to amend the patent law to disallow software

patents and, if possible, invalidate those that have already been

awarded.  The House Subcommittee on Intellectual Property and the

Administration of Justice, chaired by Representative William J. Hughes

(D-N.J.), should take the lead by scheduling hearings on the subject

and calling for a congressionally sponsored economic analysis of the

effect of software patents on the industry.

The computer industry grew to be vibrant and healthy without

patents.  Unless those who want software patents can demonstrate that

they are necessary to the health of the industry, Congress should feel

justified in eliminating this barrier to innovation.

Recommended reading

Brian Kahin, "The Software Patent Crisis," Technology

Review (April 1990): 53-58.

Mitchell Kapor, Testimony at Hearings before U.S. House of

Representatives, Subcommittee on Courts, Intellectual Property and the

Administration of Justice, of the Committee on the Judiciary (March 5,

1990).

Pamela Samuelson, "Benson Revisited: Should Patent Protection Be

Available for Algorithms and Other Computer Program-Related

Inventions?" Emory Law Journal

(Fall 1990): 1025-1154.

Pamela Samuelson, "Should Program Algorithms Be Patented?"

Communications of the ACM (August 1990):

23-27.

Simson Garfinkel is a senior editor at NeXTWORLD magazine (San

Francisco) and the coauthor of the book Practical UNIX Security.

Richard M. Stallman is one of the founders of the League for

Programming Freedom (Cambridge, Massachusetts) and the recipient of

the Association for Computing Machinery's Grace Hopper Award.

Mitchell Kapor, a founder of the Lotus Development Corporation, is

president of the Electronic Frontier Foundation (Cambridge,

Massachusetts).

Quotes:

The Patent Office is carving up the intellectual domain of computer

science and handing little pieces to any company that files an

application.

The most effective course of action is to encourage Congress to amend

patent law to disallow software patents.