비즈니스를 위한 오픈 소스 소프트웨어

13장 오픈 소스 소프트웨어와 특허 (부여, 방어적 종료)

소프트웨어 특허는 엄청난 정치적 앙금과 함께 온다 - 저자가 집필한 모든 기사 중에서, 소프트웨어 특허에 관한 기사가 저자에게 가장 심한 항의문서를 가져다 줬다. 하지만, 소프트웨어 특허가 좋은 정책이든 나쁜 정책이든, 현재 법의 일부다.¹ 그리고 오픈소스 소프트웨어와 특허 사이에 객관적이고 실무적인 교차 분석을 발견하기 어려울 수 있기 때문에, 사업하시는 분들은 현행 법규에 기반해서 소프트웨어 특허에 관한 합리적인 의사결정을 취할 얼개가 필요하다.

이번 장에서 두가지 주제를 다룬다. 첫번째는 오픈소스 소프트웨어를 사용하는데 커뮤니티 자유에 제3자 특허(오픈소스 라이선싱에 관여하지 않은 당사자가 소유한 특허)가 영향을 주는 방법에 대한 질문이다. 두번째는 오픈소스 라이선스가 오픈소스 라이선싱에 관여한 사람의 특허에 영향을 주는 방법에 관한 질문이다. 첫번째는 주로 정책 질문이다. 두번째는 라이선스 해석과 지적재산 전략에 대한 질문이다.

위대한 특허 논쟁 ²

인터넷은 소프트웨어 특허가 오픈소스(일반적으로 소프트웨어에 대한 위험과 반대로)에 특정 위협인지에 관해서 뿐만 아니라 소프트웨어 특허가 옳은 것인지 틀린 것인지에 관한 논의로 와글거렸다. 일부 논의는 흥미롭고 사려깊었다. 그리고 일부는 불경스럽고 증오가 가미되었다 (따라서 흥미롭지만 특히 유용하지는 않았다.) 하지만 한가지는 확실하다: 오픈소스 커뮤니티는 소프트웨어 특허를 혐오했다. 예를 들어, GPL 서문은 “어떤 자유 프로그램도 소프트웨어 특허로부터 지속적인 위협이 있다”는 문장이 담겨있다. 그리고 FSF와 다른 자유 소프트웨어 단체는 활발하게 특정 특허 혹은 일반적으로 소프트웨어 특허를 물리치기 위한 로비와 노력을 경주하고 있다.

소프트웨어 특허가 비도덕적이라는 것에 동의하든 동의하지 않던, 이런 태도는 오늘날 소프트웨어 엔지니어 사이에 광범위하게 퍼져있다는 것을 이해해야만 된다. 따라서, 실용적인 측면에서, 특허 포트폴리오 관리에 소프트웨어 엔지니어를 관여시키는 것이 어려울 수 있다. 역사적으로, 특허 변호사는 엔지니어와 가깝게 작업을 해서 특허공개와 특허출원을 준비했다; 오늘날, 일부 엔지니어는 해당 프로세스에 관여를 거부한다. 2012년 트위터는 “혁신자의 특허 합의서(Innovator’s Patent Agreement)”를 출판했다. 트위터 임직원은 공격적 목적으로 특허를 사용하지 않겠다는 발명자에 대한 서약.³

It is a commitment from Twitter to our employees that patents can only be used for defensive purposes. We will not use the patents from employees’ inventions in offensive litigation with- out their permission. What’s more, this control flows with the patents, so if we sold them to others, they could only use them as the inventor intended.

다른 회사도 격식없는 서약에 다음과 같이 언급하면서 서명했다: “25명보다 적은 회사에 대한 첫번째로 특허 사용안하기(No first use of patents against companies with fewer than 25 people)”⁴

행간을 읽어 뜻을 유추하면, 만약 회사가 공격적 목적에 특허를 사용하지 않겠다는 약속을 하지 않는다면 가장 똑똑한 최고 엔지니어를 보유할 수 없거나 특허 추진(patent prosecution) 노력에 지원을 확실할 수 없다고 볼 수 없다. 다른 많은 회사가 유사한 결정과 약속을 했다-대체로 공개적이 아닌 방식으로. 기술 회사에서 엔지니어는 가장 유능한 재원이고 경영관리는 이런 재원의 정치적 성향을 맞춘다.

더 혹은 덜 위험에 처해 지나?

오픈소스 커뮤니티는 확실히 좀더 커다란 특허 논쟁을 해결하지 못할 것이다. 왜냐하면 특허자격 주제에 대한 범위를 한정하는 정책결정은 오픈소스 소프트웨어를 훨씬 넘어서기 때문이다. 하지만, 오픈소스 소프트웨어가 독점적 소프트웨어보다 더 특허 침해 주장에 조금 더 혹은 조금 덜 취약한지에 대한 좀더 협의의 질문이 있다 - 아마도 좀더 흥미있는데 이유는 답할 수 있을 것같기 때문이다.

GPL2는 “어떤 자유 프로그램도 소프트웨어 특허로부터 지속적인 위협이 있다”고 언급하고 있다. 하지만, 위협을 받는 것과 좌절당하는 것에는 차이가 있다. 오픈소스가 특히 사용에 위험한가(특허 심판청구에 노출되었다는 의미에서)에 대한 질문은 사업에 오픈소스 소프트웨어를 사용하는 사람에게는 상당히 실무적으로 중요하다. 이것은 단지 자유 소프트웨어 사언이라기 보다는 오픈소스 사안이다. 하지만, 제3자가 특허 심판청구를 제기할 수 있는 기량은 소프트웨어에 적용되는 외부로 나가는 라이선스 조건과는 아무 관련이 없다. 그리고 부분적으로 이점이 상기 질문에 답할 수 있는 열쇠가 된다.

지적재산법에서 가장 어려운 개념중에 하나가 이것이다: 특허는 권리이며 권리외는 아무것도 아니다. 특허를 소유하는 것은 소유자에게 특허에 청구된 발명을 다른 사람이 실시하는 것을 제외하는 권리를 제외하고 아무것도 부여하지 않는다. 특허는 종종 권능을 부여하지 않는 권리(non-enabling right)라고 일컷는다. 특허 소유자가 어떤 제품을 만들거나 특정 사업에 관여하는 권능을 부여하지 않는다. 특허 침해 소송을 제기해서 특허를 시행하는 것은 특허 소유자가 보호하려는 어떤 사업에 관여할 것을 요건으로 하지 않는다. 이점이 특허 “괴물(troll)”이 존재할 수 있는 이유다. 특허 괴물회사는 특허침해에 대해서 다른 회사에 소송을 제기하는 것 외에는 어떤 사업에도 관여하고 있지 않다. 특허는 단지 소극적 권리(negative right)다.

대조적으로 자작권법 아래서, 저자는 실질적으로 권리를 소유할 무언가를 창조해야만 한다. 다른 지적재산체제에서도 마찬가지다 - 상표(trademark)와 영업비밀(trade secret); 각 경우에, 권리를 소유할 무언가를 실질적으로 창조해야만 한다. 누군가 기밀사업정보를 창조했기 때문에 영업비밀이 발생한다. 상표는 누군가 재화의 원천과 출처를 지정하려고 교역에서 사용했기 때문에 발생한다.

권능을 부여하지 않는 특허권의 본질이 사람들이 특허를 싫어하게 되는 일부 사유가 된다. 일리가 없지는 않지만, 이런 분들은 특허가 사회에 순손실이라는 견해를 갖는데 이유는 특허 소유자가 스스로 어떤 것에도 관여하지 않으면서 혁신에 다른 사람들이 관여하지 못하게 막기 때문이다. 하지만, 특허법 전제는 특허 공보(publication of the patent)가 세상에 발명(이를 “특허”로 함)을 드러냄으로써 유용한 기예를 발전시키려는 의도가 있다. 아마도 특허 시스템이 오늘날 망가진 것으로 보는 이유는 특허가 더이상 혁신을 일러주는 좋은 방식이라고 생각하지 않기 때문이다. 결국, 아마도 이러한 점은 진정한 혁신과 최신 기술에 기반해서 자명하지 않은 발명에 특허를 제한한 특허 사무소의 실패로 여겨지는 것에 기인한다. 시행되고 이는 특허의 절반은 대게 자명함으로 인해 무효화되는데, 이점을 동의하지 않기 어렵다.

게다가, 다른 지적재산체제 아래서 독립적 저작은 침해주장에 대한 피고가 된다. 저작권과 영업비밀 아래서, 만약 누군가 다른사람의 독점적 재료를 사용하거나 빼끼지 않고 바퀴를 다시 발명하는 시간과 노력을 들였다면, 그 사람은 바퀴를 사용할 수 있다. 설사 피고가 모방하기 보다 독립적으로 바퀴 아이디어를 창안했다는 것을 증명하는데 애를 먹을 수 있을 지라도, 그밖의 누군가 먼저 바퀴를 사용했다는 사실도 차이가 없다. 독립적 발명이 특허 침해에 변호가 되지 못한다. 그리고 결과로 설사 다른 사람의 아이디어를 “훔치지” 않고 발명을 했더라도, 모르고 특허를 쉽게 침해할 수 있다.

이론은 자유로이 누구나 읽을 수 있고 배울 수 있는 기발행된 특허는 실시 방법과 발명의 세계에 대한 건설적인 고지(constructive notice)가 된다. 단어 특허(patent)는 열람에 열여있다는 의미지만, 실무에서는 실시하려는 발명을 포괄하는 특허를 검색하는 것은 비싸고, 시간이 소요되고, 복잡하다 - 따라서 기능적으로 불가능하다. 사실, 법이 이런 검색을 수행하는데 대해 의욕을 꺾는 것을 만들어 냈다 (종종 운용자유 연구(freedom-to-operate study)로 알려짐). 왜냐하면 잠재적 특허 침해를 인지하는 것이 “고의적(willful)” 침해 위험에 노출되는데, 이는 최고 손해와 변호사 수임료에 대해 잠재적으로 지불의무가 되기 때문이다. 그래서, 특허법은 지뢰밭이 되었고, 승자는 흔히 전혀 혁신하지 않는 회사처럼 보인다.

특허권의 권능을 부여하지 않는 속성의 결과로, 소프트웨어는 어떤 방식으로든 개발될 수 있고, 특허침해주장 위험에 노출되어 있다. 완전 처음부터 새롭게 한줄한줄 작성된 코드(그런 코드가 존재한다면) 조차도 특허를 침해할 수 있고, 개발자는 소송을 당할 때까지 그런 사실을 알지 못한다. 해당 코드가 독점적 혹은 오픈소스 코드일 수 있고, 그런 것이 문제가 되지는 않는다.

그래서 모든 자유 소프트웨어가 항시 소프트웨어 특허로부터 위협받고 있다는 주장은 사실이다 - 하지만, 단지 일부만 사실이다. 어떤 소프트웨어나 항시 소프트웨어 특허의 위협을 받고 있고, 여전히 소프트웨어를 사용하고 있다. 하지만, 오픈소스 소프트웨어와 소프트웨어 특허는 함께 성장했다; Diamond v. Diehr, 450 US 175 판결(소프트웨어 특허를 허용한 기념비적인 사례)은 1981년 내려졌다; GPL은 1991년에 작성되었다; 그리고 State Street Bank v. Signature Financial Group, 149 F.3d 1368 판결(비즈니스방법(BM)특허를 허용한 사례)은 1998년에 내려졌다. 소프트웨어 특허 (그리고, 친동생인 비즈니스방법(BM)특허)와 오픈소는 1990년대와 21세기 초반에 엄청난 성공을 거두었다.⁵

양파 한겹을 벗겨내면, 오픈소스 소프트웨어가 특별히 소프트웨어 특허에 취약한가에 대한 질문이 좀더 흥미롭다. 소프트웨어 합의를 협상해 본 누구나 소프트웨어가 제3자 특허를 침해했는지를 아는 것은 불가능성해서, 특허침해에 대한 배상책임이 소프트웨어 거래에서 다뤄지는 어려운 사안임을 잘 알고 있다. 어느 쪽(라이선스 허가자/피허가자 혹은 양도인/양수인)도 제어할 수 없고 잠재적으로 값비싼 책무를 부담하고 싶지는 않다. 순수 오픈소스 라이선스는 이런 면에서 독점 라이선스와 다르다. 순수 오픈소스 라이선스 아래 제공된 소프트웨어는 있는 그대로(as-is), 제품품질보증 없이 제공된다는 것이고, 라이선스 허가자는 특허침해주장에 대한 어떤 위험도 부담하지 않는다는 것이다. 독점 소프트웨어는 특허침해주장을 포괄하는 라이선스 허가자 배상으로 종종-항상 그렇지는 않지만-뒷받침되곤 한다.

하지만, 이것이 보이는 것처럼 그렇게 간단하지는 않다. 상당히 많은 독점 소프트웨어는 특허 침해에 대해 어떤 배상도 없다. (다음번 최종사용자 라이선스 동의를 클릭하면, 이런 한 사례를 볼 수도 있다.) 혹은 아마도 소프트웨어 가격에 한정한 배상이 있는데 특허침해주장을 변호하는 것과 비교하여 적절하지 못하다. 심지어 특허침해소송에 간단한 대응을 준비하는 것도 소송비용으로 수천달러가 소요된다. 그래서, 특허 소프트웨어가 항상 배상을 한다는 것도 사실이 아니다.

그리고 때때로 오픈소스 소프트웨어는 배상한다. 위에서, 저자는 순수 오픈소스 라이선싱을 언급했는데, 어떤 부가적인 비즈니스 조건을 갖지 않는 오픈소스 라이선스를 갖는 소프트웨어 도입을 의미한다. 설사 라이선스 그 자체로 어떤 보상을 제공하지 않지만, 오픈소스 소프트웨어를 포함하는 제품의 판매자는 통상 유지보수와 서비스 혹은 지원에 대한 댓가로서, 배상에 대한 계약에 동의할 수 있다. 배상에 관해서 기억할 중요한 사항은 경제적 비용을 갖는다는 것이다. 그래서 어느 누구도 공짜로 주지 않는다는 것이다. 오픈소스 소프트웨어는 좀더 무료일 수 있어서, 덜 빈번하게 보상없이 딸려올 것 같다. (이 질문에 조먿 자세한 사항에 대해서, 그리고 상업적 거래에서 위험을 부담하는 것에 대한 관례와 합리성에 대해서, 17장 인수 합병과 기타 거래를 참조한다.)

특허침해 법적침해에 대한 위험을 이해하기 위해서, 특허침해주장 이면에 숨은 동기를 고려할 필요가 있다. 만약 특허침해가 존재한다면, 특허소유자가 주장을 하지 않는다면, 어떤 것도 없게 된다. 특허소유자가 주장을 제기하는 위험을 평가하려면, 왜 특허소유자가 그러고자 하는지 이해해야만 된다. 종국에, 특허는 기소하는데 비용이 많이든다; 소프트웨어 특허에 대한 처음 신청서를 제출하는데 $10,000 - $20,000 정도 평균적으로 비용이 소요되는데, 여기에는 기본 법률 비용에, 주장이 실제로 허락되고 특허를 내주기 전에, 특허심사관의 반론에 대응하는 부가적인 법률비용이 추가된다. 추가로, 특허침해주장은 변호하는데 비용도 많이 들고, 특허침해주장을 제기하는데도 비용이 많이 든다. 그런데 왜 그런 돈을 왜 쓸까?

특허를 소유하고 수행원 비용을 지불하는 이유가 세가지 있다.

• 돈을 목적으로 상대방에 소송한다.
• 역으로 공격한다.
• 경쟁자를 방해한다.

돈(Money)

첫번째 이유는 가장 쉽다; 특허침해소송 원고는 금전적 배상을 목적으로 소송할 수 있다. 특허침해청구는 경제적인 무기다. 변호사 농담으로 첫번째 규칙은 다음과 같다: 돈없는 사람을 소송하지 마라. 오픈소스 프로젝트는 손해배상청구 대상으로 좋지 않다. 왜냐하면, 대체로 돈이 별로 없기 때문이다. 하지만, 오픈소스 소프트웨어를 사용해서 돈을 벌고 있는 회사는 좀더 조짐이 좋은 회사가 될 수 있다. 하지만, 거의 어떤 회사도 오픈소스 소프트웨어에서 직접적으로 돈을 벌고 있지 않다. 그래서 전반적으로 오픈소스는 독점 소프트웨어보다 특허청구에 좀더 덜 취약하다.

소송을 통해서 받아내려고 하는 금전적인 액수에 대해서, 특허배상금을 계산하기 복잡하고, 계산하는데 사용되는 방법에 대한 소송은 격렬하다. 하지만 본질적으로, 손해배상은 (a) 최소로, 특허에 대한 합리적인 라이선스 로열티 비율(35 USC 284)⁶, (b) 특허소유자의 손실 이익⁷이 된다.

어떤 것도 특히 오픈소스진영에 대해서 매력적이지 않는데 이유는 오픈소스 소프트웨어는 시스템 근간, 일반 상품, 수익성없는 기능품인 경향이 있어서, 수익 창출에 대한 공간이 그다지 크지 않아서 특허 로열티에 대한 공간도 별로 없다.

역으로 공격(Counteroffensives)

역공은 특허권 시행에 대한 주요 동기다. 특허를 보유하고 있는 대부분의 회사는 적극적 특허 시행(라이선싱 프로그램, Licensing Program)에 관여하지 않는다; 특허 소송이 제기되는 경우에 시행할 방어용 특허 포트폴리오(Defensive Patent Portfolio)를 구축한다. 특허괴물이 출현하기 전에, 이것이 규범이였다; 많은 대기업이 대기업 간에 특허침해 주장을 억제할 핵무기 교착상태가 되도록 하는 상호특허사용허가(Cross-licenses)를 맺었다. 참여하지 않는 기업은 자사가 보유한 특허 포트폴리오 가치가 제3자 청구를 억제할만큼 충분하리라는 희망을 갖는다.

역공 청구는 독점 소프트웨어에서 흔하지만, 오픈소스 소프트웨어에서는 그렇지 않다. 독점 제품을 보유한 대부분의 회사는 특허보호를 추구하지만, 오픈소스 프로젝트는 거의 시행할 특허권을 갖고 있지 않다. 오픈소스 제공자가 특허침해 청구를 제기하지 않는다면, 역공할 이유가 없다.

반례가 있는데 Open Invention Network(OIN) 같은 커뮤니티 방어 프로그램이다. ⁸ 이런 프로그램은 특허 포트폴리오를 구축해서 오픈소스를 방어하려고 한다. 설사 청구주장이 특허권 소유자 본인에 의해서 제기된 것은 아니더라도, 오픈소스 프로젝트를 고소하는 청구주장에 대한 반응으로 유용한 역공 청구주장을 갖는 특허를 갖는 독점 소프트웨어 회사같은 특허소유자로 하여금 소송을 제기하도록 한다. 하지만, 이런 노력의 성공을 가늠하기는 어려운데 이유는 이들에게 있어 성공이 특허소송이 없는 것이기 때문이다. 리눅스를 “변호(defend)”한다는 서약의 유효함에 대해서 회의적이다 - 하지만, 지지자에게 결과적으로 일부 유용한 주목을 이끌어낼 수는 있다.

하지만, 특허시행에 관해서 불평할 때, 방어적 시행에 관해서는 대체로 언급하지 않는다. 사실, 이번장 후반부에 기술되듯이, 일부 오픈소스 라이선스는 방어적 청구를 제기하는 필요성에 대해 인정한다 - 이런 청구가 오픈소스 소프트웨어를 고소하더라도 말이다.

경쟁 방해(Competitive Discruption)

특허침해주장을 제기하는 마지막 동기는 경쟁 방해다. 오픈소스 진영에 있어 특허침해주장에 대한 가장 그럴듯한 동기가 된다; 만약 특정 회사가 오픈소스 제품과 경쟁한다면, 잠재적으로 심각한 경쟁 우려가 있고, 특허지대를 경쟁관계에 있는 오픈소스 제품에 부과하고자 하는 동기도 높다. 결국, 오픈소스 소프트에어는 라이선스 비용이 없어서 쉽게 경쟁관계에 있는 독점제품의 매출을 약화시키게 된다. 예를 들어, 마이크로소프트는 짐작컨데 윈도우와 윈도우 모바일 플랫폼과의 경쟁을 방해하려는 목적으로, 임베디드 리눅스와 안드로이드 제품 라이선싱에 대해서 특허 프로그램에 공격적이며 성공적으로 관여했다. 하지만, 실무적으로 일부 회사만 오픈소스 소프트웨어를 고소하는 특허침해청구를 제기한다. 그런 청구주장을 제기하는 것은 상당히 인기없고, 이런 행동은 초토화 홍보전략이 된다. 특허괴물(보호할 제품이 없기 때문에 영업권이 필요없다)을 차치하고, 당지 두 회사만 오픈소스 소프트웨어 특허시행에 적극적이다: 마이크로소프트와 오라클. 두 회사 모두 매우 크고 시장에서 자리를 잡고 있어서 오픈소스 커뮤니티에서 제기하는 조롱을 감내할 수 있다.

다른 한편으로, 오픈소스 소송을 제기해서 사업을 망해먹은 전형적인 사례가 SCO v. IBM 이다. 거의 틀림없이 SCO는 IBM과 리눅스와 전쟁을 하기 전에 망해가는 회사였다. 하지만, 사업을 유지하려고 했다면, 이 기념비적인 소송이 자신의 관에 마지막 못을 박아넣은 결과가 되었다. SCO는 특허고소가 아니라, 오프소스와 연관된 첫번째 주요한 소송이다. (19장: 시행과 시행 장애물 논의 참조) 적어도, 이번 소송은 오픈소스 소프트웨어를 고소하는 소송을 제기하는 것이 얼마나 인기없는지 확실히 보여줬다. 상당한 특허 포트폴리오를 갖는 회사를 포함해서 대부분의 주요 기술회사는 오픈소스 소프트웨어를 고소해서 특허소송을 제기함(설사 특허 소송이 경쟁자 사업에 지장을 주더라도)으로써 실현할 수 있는 어떤 이득보다도 고객호감도(Goodwill)를 지키는데 좀더 관심을 갖고 있다.

특허침해소송을 제기하는 동기에 관한 가정에 기반해서, 오픈소스 소프트웨어가 특허침해도전에 덜 혹은 더 취약한지에 대한 질문으로 다시 돌아갈 수 있다. 전반적으로 저자 분석은 오픈소스 소프트웨어가 독점 소프트웨어 보다 덜 취약하다는 것을 보여준다. 하지만, 해당 질문은 어떤 단순한 대답이 없는 어려운 것이다. 추론과정은 다음과 같다.

발견(Discovery)

오픈 소스와 독점 소프트웨어 사이 가장 큰 차이점은 오픈 소스 소프트웨어는 자유로이 검토가 가능하다는 점이다. 잠재적으로 침해 소프트웨어가 실제로 원고 특허를 침해하는지 조사하는데 있어, 잠재적 특허 원고가 법적 발견절차(legal discovery process, 법원이 증거제출을 강제하는 명령)에 관여하지 않다도 된다는 것을 의미하게 된다.

잠재적 침해 식별을 좀더 쉽게하는 수단이 저자의 질문에 대해 두가지 효과가 있다. 한편으로, 잠재적 원고가 진실하게 독점 소프트웨어가 특정 발명 실행을 정확히 알 수 없다면, 잠재적 원고는 침해 식별을 덜 할 것 같지만, 발견 사실을 강제하려고 실제소송을 더 제기할 것 같다. 다른 한편으로, 만약 잠재적 원고가 쉽게 잠재적 침해 소프트웨어를 확인한다면, 잠재적 원고가 특허주장에 매력이 없거나 혹은 조만간 특허주장을 제기할지 좀더 잘 결정할 것 같다.

전반적으로 아마도 피고에 이점이 잇점으로 작용할 것이다. 소프트웨어가 시장에 오래 나와 있을수록, 침해소송에 잠재적 손해배상금이 많아지고, 사안을 조작하기는 더 힘들어 진다. 더욱이, 만약 고소된 소프트웨어가 장시간 소스코드 형태로 이용가능하게 된다면, 원고가 더 일찍 소송을 제기했었다고 주장할 수 있는데 이유는 발명이 실행되고 있다는 건설적 고지(constructive notice) 때문이다. 금반어(estoppel, 먼저 한 주장에 반대되는 진술을 뒤에 하는 것을 금지) 혹은 태만(laches)으로 불리는 법적원칙이 있다. 이것이 더 많은 손해배상금을 추구하도록 원고가 침해가 누적되는 것이 허용되고, 권리 위에 그냥 깔고 앉아 있지 못하게 한다.

또한, 이런 사안을 분석하는 사람은 이진코드가 특정 발명을 실행하고 있다고 판단능력에 관해서 단순하게 가정하는 것에 유의해야 한다. 일부 소프트웨어 특허는 매우 높은 수준에서 발명을 기술하는 특허청구주장을 담고 있다. 소프트웨어가 그런 발명을 실행하는지 판단하는데 소스코드를 면밀히 조사할 필요는 없고 단지 소프트웨어가 동작하는 것만 알면된다. 더욱이, 통상의 기술자는 이진코드를 조사해서 소프트웨어가 어떤 유형의 기능을 수행하는지 알아낼 수 있다. 자바 같은 언어는 쉽게 디컴파일할 수 있다. 파이썬, 루비, 펄, 자바스크립트 같은 고수준 스크립트 언어로 작성된 소프트웨어는 오픈소스 조건이든 독점 소프트에어 조건이든 관계없이 항상 소스코드 형태로 나와있다. 실행가능 형태로 배포되는 어떤 소프트에어나 호기심에 가득찬 눈에서 사실을 숨길 수 있다고 단정하지 마라 - 숨길 수도 있지만, 그렇지 않을 수도 있다.

제2의 해결책(workaround)

오픈소스 커뮤니티가 버그를 고치고 소프트웨어 개발에 쉽게 협업하는 것처럼, 특허침해주장을 우회하는데 쉽게 공동으로 협업한다. 예를 들어, Jacobsen vs. Katzer 사례에서 이런 일이 일어났다. 커뮤니티로부터 자원봉사자가 나서서 제이콥슨(Jacobsen)을 도와서 선행기술(prior art)을 정확히 찾아냈고, 캐져(Katzer)가 제기한 특허침해주장을 회피하는 방안을 제시했다. ⁹ PUBPAT, the Electronic Frontier Foundation, Software Freedom Law Center 같은 조직은 종종 자원봉사자를 조직화해서 오픈소스 소프트에어를 고소하는 특허침해주장을 철회하도록 한다. 전반적으로, 이것이 의미하는 바는 설사 특허침해로 고소되더라도, 오픈소스 소프트웨어를 좀더 쉽게 변경해서 계속 진행중인 침해를 회피하고 그럼으로써 잠재적 손해배상금을 줄이고, 법원의 명령을 회피한다는 점이다.

자명성(obviousness)/진보성

거의 모든 특허의 약 50 퍼센트가 시행될 때 무효화된다. 주로, 이런 일이 발생할 때는 피고가 특허출원과정에서 공표되지 않은 선행기술, 선행기술에 비추어 특허발명이 자명한 선행기술을 식별해낼 때다. 발명은 신규성(novel)과 비자명성(non-obvious)을 갖추어야 성공적 특허개시(patent prosecution) 대상이 된다. 이런 용어(nomenclature)가 특허법에 친숙하지 않는 사람 대부분에 혼동스럽다. 신규성 요건은 만족하기 쉽니다; 단지 발명이 새로운 것이면 된다. 하지만, 성공적 특허를 위한 근거를 구성하려면, 발명이 선행기술에 비추어서 자명하면 안된다. 따라서, 만약 발명이 새롭지만, 발명이 이루어진 시점에 통상의 기술자에게 자명한 작은 혁신이라면, 특허에 대한 근거를 구성하지 못한다.

소프트웨어 특허에 관한 불평이 있는데, 자명한 특허청구주장을 제거하는데 특허심사관을 도울 충분한 선행기술 저장소가 없다는 것이다. 소프트웨어 특허가 좀더 최근에 전개될 때, 이런 점이 좀더 강력한 주장이 된다. ¹⁰ 하지만, Diamond v. Diehr 사례 이래로, 30년 동안, 상당한 선행 특허가 소프트웨어 세상에 전개되었다. 어떤 경우에나, 오픈소스 소프트웨어는 자유로이 누구나 면밀히 조사할 수 있기 때문에, 엄청난 공개적으로 이용가능한 잠재적 선행기술 저장소이기도 하다. 따라서, 오픈소스 소프트웨어는 성공적으로 특허를 기소할 능력을 감소시키는 경향이 있다. 그렇다고 이것이 특허청구주장 그 자체로부터 오픈소스 소프트웨어를 보호하는 것은 아니다. 하지만, 일부 경우에, 오픈소스 소프트웨어는 기소되는데 사용될 특허보다 앞설 수 있다. 이것이 특허청구주장을 쉽게 격퇴할 수 있는 자명성 변호를 이끌어 낸다.

챔피온이 없다.

대항력있는 주장(오픈소스 소프트웨어가 더 위험하다)은 다음 전제에 기반한다. 독점 소프트웨어 제품은 후원하는 방어 특허 포트폴리오를 갖추고 있는 경향이 있고, 후속 역공 청구주장의 잠재성이 특허소송제기를 억제한다는 것이고, 오픈소스 프로젝트는 방어 포트폴리오를 갖추고 있지 않다는 점이다. 특허청구주장 제기에 대한 동기로서 역공조치에 관해서 상기 논의를 참조한다.

오픈소스 라이선싱에 특허 부여(patent grants)와 제공(provisions)

이제 정책에서 빠져나와 라이선싱 기술로 방향을 돌려보자. 많은 오픈소스 라이선스가 그 자체에 붙박이된 특허 라이선싱이 있다. 하지만, 이런 라이선스는 전통적 특허 상호교차라이선스와 상당히 달라보이고, 해석에는 그런 조항이 언제 왜 개발되었는지 이해가 요구된다. 오픈소스 라이선싱을 학습하려는 많은 사람들은 오픈소스 라이선스 특허 조건이 이해하기 힘들다는 것을 알게된다. 전통적 특허 라이선스가 대체로 특허권을 가능한 협소하게 부여하려고 하지만, 오픈소스 특허 라이선스는 의도적으로 폭넓다 - 그리고 일부는 의도적으로 모호하게 한다. 이것이 말하는 바는, 오픈소스 라이선스에서 대부분의 특허 부여는 대체로 범위체서는 유사하고, 그다지 이해하기가 어렵지는 않다는 것이다.

묵시적 특허 라이선스(Implied Patent Licenses)

명시적 특허부여가 부재하더라도, 모든 오픈소스 라이선스는 암묵적으로, 일부 특허권을 부여한다. 묵시적 실시권(implied license) 이론에 대한 판례법은 모호하고 별로 없다. 특허 소유자가 소프트웨어에 대한 저작권 라이선스를 부여하고 나서, 이미 사용허락된 활동에 관여한 것에 대해 특허침해로 라이선스 피허가자를 고소하는 것이 불공정하다는 전제에 법적이론이 기반하고 있다.

사실상 묵시적 실시권은 몇가지 법적 이론의 모방작품이다; 법적 금반언( legal estoppel), 공정한 금반언(equitable estoppel), 특허권 소진(patent exhaustion) (혹은 최초판매(first sale) 원칙).¹¹ 이런 질문에 대한 판례법 정독은 도전적일 수 있지만, 법원이 불공평한 결과를 회피하려고 역추론을 한다는 점과 잘못된 것을 옳게하는 이론을 식별하는데 걱정을 덜려는 점을 명심하는게 도움이 될 수 있다. Wang Lab. v. Mitsubishi Elecs. Am., 103 F.3d 1571 (Fed. Cir. 1997) 판례에서, 연방 특별 행정 고등 법원은 법적 금반언 아래, 라이선스 허가자는 이미 라이선스 피허가자에 부여한 권리를 강탈하는 특허침해청구주장을 사용할 없다고 판시했다. 공정한 금반언(equitable estoppel)은 라이선스 피허가자로 하여금 라이선스 허가자의 법적조치를 믿을 수 있도록 한다. 라이선스 피허가자로 하여금 합리적으로 라이선스 피허가자가 특허에 대한 라이선스를 갖도록 믿도록 만드는 법적조치다. ¹² 이 이론에 대한 근본은 오래되었다.¹³ 하지만, 소프트웨어에 적용은 너무 새로워서 묵시적 실시권 범위에 명확한 선을 그을 수 없다. 예를 들어, 연방 특별 행정 고등 법원은 “일반적으로 판매자가 제한 없이 제품을 판매한다면, 사실상 가격에 대한 교환댓가로 구매한 제품을 전체적으로 향유할 만족을 방해하지 않겠다는 약속을 구매자에게 한 것이다. 구매자는 판매자의 어떤 특허에 대해서도 묵시적 실시권을 보유한다. 판매자의 어떤 특허도 제품이나 당사자가 합리적으로 심사숙고하여 제품이 놓여질 곳에 어떠한 제품의 사용에 대해서도 우선하게 된다.”라고 언급했다.¹⁴ 오픈소스 라이선싱이 “제한없음(without restriction)”은 사실이지만, 이 사례는 소프트웨어 관한 것이 아니다. 일반적으로 어떤 가격도 오픈소스 라이선스로 지불되지 않는다.

공정한 금반언(equitable estoppel)에 의한 묵시적 라이선스를 회피하려면, 특허 보유자는 별도 특허 라이선스가 필요하다는 점을 의사소통할 수 있어야 한다. 오픈소스 라이선싱에서 이런 행동은 도전적일 수 있는데 이유는 오픈소스 라이선스가 어떤 권리에 대한 유보도 포함하고 있지 않고¹⁵, 카피레프트 라이선스가 라이선스 행사에 “부가적인 제약”을 두는 것을 금하고 있기 때문이다. 하지만, 많은 오픈소스 라이선스에서 개별적 특허라이선스 요건이 그런 제약인지는 분명하지 않다.¹⁶ 어떤 명시적 특허 라이선스가 존재하지 않는 곳에서 특허 라이선스가 좀더 묵시적일 것 같다 - 그래서, 명시적 특허 부여를 담고 있고, 어떤 부가적인 라이선스 유보를 담고 있지 않는 오픈소스 라이선스 조차도, 어떤 부가적인 라이선스가 묵시적이지 않다는 것이 가능하다.

특허 라이선싱에 대한 일부 기본 원칙은 특허 라이선스에 특정 조건을 다음과 같이 어떻게 정의하냐에 달려있다:

• 라이선스된 특허 정의 (획득(capture))
  • 특허 소유자
  • (향후 획득기간을 포함할 수 있는) 획득 기간
  • 등재된 혹은 특별한 특허
  • 지리적 제약
• 라이선스된 제품 정의 (라이선스 부여 대상)
  
• 라이선스 부여에 대한 분야 혹은 영역 정의 (범위 제약(scope limitations))

특허 라이선싱에 대한 전반적인 논의는 이책의 범위를 넘어선다. 하지만, 몇가지 구성요소는 오픈소스 라이선스에 있어 특허권 부여를 이해하는데 매우 중요하다.

전통적 특허 라이선스가 종종 특정한 특허 혹은 특허목록을 획득하지만, 오픈소스 특허권 부여는 항상 특허 소유자의 “불가피한 청구주장(necessary claims)”으로만 구성된다. 불가피한 청구주장에 대한 개념은 특허 라이선싱에서 오래된 개념으로, 특히 표준 라이선싱과 특허풀에서 그렇다. 이것은 놀라운 것이 아닌데, 왜냐하면 오픈소스 라이선스에서 특허 라이선스 목적은 소프트웨어를 보호할 일종의 “특허 공공재(patent commons)”를 생성하는 것이기 때문이다.

특허권 청구(patent claim)는 특허가 보장하는 발명을 기술하는 특허 부분이다. 필요 청구(necessary claim)는 특허권 청구로 이것이 없이 예를 들어, 표준을 실행하거나 소프트웨어 일부 조각을 사용하는 활동에 관여하는 것이 가능하거나 혹은 아마도 실현가능하지 못할 것이다. 다른 말로, 만약 청구항에 기술된 발명을 실행하지 않고 소프트웨어를 실현가능하게 사용하려면, 청구항이 필요한 것이 아니고, 따라서 라이선스되지 않는다. 예를 들어, 특허청구가 보라색 사용자 인터페이스를 포함하고, 소프트웨어 일부가 많은 색깔로 인터페이스를 구축할 수 있도록 한다고 가정하자. 이런 경우에, 보라색 인터페이스를 포함하는 청구항은 필요한 것은 아니다.

획득하는 범위를 평가하기 위해서, 또한 누가 소유자로 고려되는지 이해해야만 된다. 예를 들어, 특허권 부여가 특정 회사와 모든 자회사와 현지법인이 소유한 특허권을 획득하거나 단지 하나의 법인만 소유한 특허를 획득할 수도 있다. 자회사를 포괄하는 획득조항(capture provision)은 특허권을 소유하는 개별회사를 설정함(종종 세금 혹은 다른 의도로 수행되는 어떤 것)으로써 라이선스 부여자의 헛점을 회피하려는 의도가 있다. 이런 법인을 흔히 IP 지주사(holding company)라고 불린다. 하지만, 오픈소스 라이선스 대부분은 하나의 법인에 대한 특허만 획득한다. 부모 회사를 포함하는 획득은 인수에서 독약이 될 수 있다 - 오픈소스 소프트웨어에 기여한 또다른 회사를 단지 매입함으로서 모든 특허에 지장을 주는 것인지 대해서 재고할 수 있다.

또한, 획득이 종종 라이선스 허가자가 소유한 특허만 포함하고, 종종 해당 법인이 라이선스할 수 있는 모든 특허를 획득할 수도 있다. 예를 들어, “모질라 공중 라이선스 1.1에 있는 특허 청구”에 대한 정의는 다음과 같다: “Any patent claim(s), now owned or hereafter acquired … in any patent Licensable by grantor.” 이 조항은 부여자가 소유한 것이 아닌 부여자가 2차 라이선스 양도할 수 있는 권리에 대한 특허권을 포함할 수 있다.

오픈소스 라이선스 특허권 부여는 한 분야만 제약이 있다. 소프트웨어에 대해 부여된 저작권 라이선스의 행사와 연계된 경우에만 권리가 부여된다는 것이다. 그래서, 만약 오픈소스 프로젝트 기여자가 권리를 특허에 부여한다면, 이러한 권리는 단지 오픈소스 라이선스 아래서 소프트웨어 사용에만 연장되고, 발명의 개별적 전형에는 연장되지 못한다. 또다른 분야 제약(예를 들어, 영토, 상업 혹은 기술 분야, 혹은 상업적 vs. 비상업적 사용)은 오픈소스 정의와 충돌나고 따라서 결코 포함되지 못한다.¹⁷

오픈소스 라이선스 특허 부여에 대한 시간획득은 대체로 무한하고 미래지향적이다. 따라서, 만약 라이선스가 라이선스 허가자가 소유한 어떤 특허를 획득하면, 부여시점과 미래 시점에 특허에 지장을 주게된다. 예를 들어, 특허가 추후 기소되거나 부여자에 인수되면 그렇다. 대체로 다른 회사나 기술을 인수하려는 회사에게 이런 점이 염려된다; 인수가 종료되자마자, 특허 라이선스는 불쑥 튀어나게된다. 전통적 특허 라이선스 대부분은 이런 문제사안을 매우 상세하게 다룬다. 하지만, 오픈소스 라이선싱에서, 획득은 폭넓고 속기 방식으로 처리된다.

특허 라이선싱이 오픈소스 라이선스에서 어떻게 작동하는지 이해하기 위해서, 아파치 2.0의 특허조항을 살펴볼 것이다. 아파치 2.0 특허조항은 오픈소스 맥락에서 단순하고 관습적이다. 3절에서 나온 관련된 조항이 다음에 나와 있다.

Grant of Patent License. … Each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

이 조항은 두가지 부분으로 되어 있다: 특허권 라이선스 조항과 방어적 종료 조항. 특허권 라이선스는 모든 기여자(즉, 기여한 저자)로부터 나오고, 기여자에 의해서 “필연적으로 침해되는” 특허를 획득하게 된다.

이런 패러다임에서, 코드에 기여를 하지 않는 단순한 재배포자(mere redistributors)는 어떤 특허권도 부여하지 않는다. 따라서, 오픈소스 소프트웨어를 사용하고 재배포하지 않거나, 재배포하나 본인 스스로 변경한 어떤 것도 재배포하지 않는 회사는 어떤 권리를 부여하고 있는지 궁금해할 필요가 없다.

GPL3에서, 특허권 범위는 더 넓다. 또한 GPL3 특허 라이선스도 기여자에 의해서 부여되더라도, GPL3는 기여된 소프트웨어(단지, 특허권 보유자 본인의 코드 기여는 아니다)에 의해 침해된 모든 특허청구도 포괄한다.

오픈소스 라이선스에서 특허권 부여 목적이 기여자가 넣은 “잠수함(submarine)” 청구주장으로부터 소프트웨어를 자유롭게 하는데 있음을 기억하라. 특허권 부여는 제3자 비기여자가 제기한 청구주장의 위험을 관리할 수 없고, 관리할 의도도 없다.

오픈소스 라이선스에서 특허권 부여는 좁혀져서 하류 변경사항(downstream modification)으로 연장되지 않는다. 그래서 만약 독자가 X.2 버젼에 기여하고, 이를 저자에게 전달한다면, 그리고 저자가 X.2 버젼을 생성하고 나면, 저자는 저자 본인의 어떤 기여에 대해서도 특허 라이선스 혜택을 얻지 못하게 된다. 단지 상류 라이선스 허가자만 오픈소스 라이선스에 권리를 부여한다.

방어적 종료(Defensive Termination)

지엽적인 방식으로 코드를 사용하거나 단순한 재배포는 누군가의 특허에 영향을 주지 못한다. 만약 당사자(“당신”)가 라이선스를 행사하고, 만약 라이선스 아래 제공된 오픈소스 소프트웨어를 고소하는 소송을 제기하면, 오픈소스 소프트웨어에 부여된 특허 라이선스 혜택을 잃게 되지만, 저작권 라이선스가 없다는 것을 잃게되는 것은 아니다.

다른 오픈소스 라이선스는 이 주제에 대해서 변형된 방식으로 구현하고 있다. 예를 들어, 아파치 방어적 종료 조항은 방어적 특허 맞고소로 촉발된다. 만약 이것이 냉혹하게 들린다면, 종료를 촉발하기 위해서 청구주장은 아파치 소프트웨어를 고소해야만 된다는 점을 명심한다. 모질라 공중 라이선슨느 저작권 라이선스를 또한 종료하는 좀더 넓은 방어적 종료조항을 두고 있다.

부록 C에 가장 흔한 오픈소스 라이선스에 대한 특허 라이선스 부여와 방어적 종료조항에 대한 표가 나와있다.