가. 저작물성 (이전 게시물에)

나. 공정 사용 (이어서)

나. 공정 사용

배심단은 구글의 공정 사용 항변 판단을 보류하였고, 지방법원은 구글이 복제한 코드와 구조가 저작권법의 보호를 받지 못한다고 결론을 내렸다. 오라클은 항소심에서 공정 사용이 적절치 못했으며, 항소심이 오라클이 이미 경쟁하고 있는 시장에서 구글이 오라클의 업적을 상업적으로 사용한 점의 법적 문제를 발견해야 한다고 주장했다.

공정 사용은 저작권침해에 대한 항변이며, 저작권법 제107조에서 체계화 되어있다. 제107조에서는 비평, 논평, 시사보도, 학습(학습용으로 다수 복제하는 경우를 포함), 학문, 또는 연구 등과 같은 목적으로 저작물이 사용되는 것을 허용한다. 공정 사용 학설은 저작권법의 모든 문제에서 언급된다.이것은 법원이 저작권법의 엄격한 적용을 피할 때 쓰인다.

오라클은 구글의 행위가 제107조의 어느 항목에도 포함되지 않으므로 공정 사용이 아니라고 주장했다.

그러나 구글은 API를 다른 용도로 변형하여 사용한 점과 자바 API 패키지는 전체의 매우 작은 부분이었으며, 산업 기준에 부합한 언어 작업에 필수적인 사용이었으며, 오라클은 사장 영향력이 미미했다고 주장했다.
항소심은 구글의 공정 사용 항변에 대하여는 충분한 사실확인이 부족하다고 결론지었다. 따라서 공정 사용 항변에 대하여 원심으로 파기 환송하여 계속되는 절차에서 판결을 내릴 것을 명하였다.

구글의 소프트웨어 프로그램은 저작권법의 보호대상이 아니라 특허법의 보호대상이라는 많은 주장을 하였다.

또한 구글은 누구나 동일한 메소드 운영체제와 이름을 사용하여 메소드의 기능을 똑같이 구현하는 자신들만의 코드를 자유롭게 작성할 수 있기 때문에 메소드 수준에서 구글은 저작권 침해를 하지 않았으며, 클래스에 대해서도 메소드와 마찬가지로 선언라인은 동일한 이름으로 작성하는데 이러한 이름은 저작권에 의해 보호받을 수 없으므로 선언라인은 저작권 보호를 받지 못하며, 이러한 이유들 때문에 전체 코드의 3%만이 비슷하게 된 것이라고 주장했다

항소심은 구글의 이러한 주장들이 설득력이 없다고 판단했다.

항소법원에서는 37개의 Java API패키지들의 코드와 구조, 순서, 조직이 저작권에 의한 보호를 받을 수 있다고 판시하여 지방법원의 판결을 뒤집었다.

공정 사용에 대한 부분은 배심원의 결정이 나지 않았으므로 항소법원은 구글의 공정 사용 항변에 대하여 원심으로 파기 환송하여 계속되는 절차에서 판결을 내리게 하였다.

지방 법원에서 오라클은 세 개의 API (java.lang, java.io, and java.util)는 자바 언어를 쓰는데 필수적이라는 점에 대하여 어느 정도 양보하였습니다. 그러나 나머지 34개는 자바 언어를 사용하는데 필수적인 기능이 아니라고 주장하였습니다.
그리고 그 34개의 API는 한가지가 아니라 매우 여러 가지로 표현할 수 있다고 주장하였고 항소심 판결은 이를 인정한 것입니다.

여러 가지 표현 방법이 있을 수 있는지(즉 저작물성이 있는지)를 판단하는 시점

컴퓨터 소프트웨어의 저작물성은 침해 당시가 아니라 저작권이 성립했을 때를 기준으로 판단해야 합니다.이것은 미국 판례법에서 확고히 인정되고 있는 것입니다. (예컨대 Feist사건)

1심에서는 저작물성을 판단을 구글의 API복제 당시 즉 침해 당시를 기준으로 판단하였고 항소심은 이러한 잘못을 교정하여 저작물성의 판단은 저작물 성립 시 즉 Java의 클래스 및 선언문 작성시로 보아야 한다고 판시한 것입니다.

이점은 항소심의 판단이 올바른 것입니다.

소스코드와 API를 그대로 복제하였는지 아니면 리버스 엔지니어링으로 알아냈는지.

알타이케이스는 1992년 판결로 전석진변호사가 1992년 미국에서 돌아와 주목할만한 미국의 소프트웨어 관련 판례로 그 평석을 마이크로소프트웨어지에 기고한 바 있습니다.
그 후 미국에서는 많은 추종 판례들이 생겨 이 사건은 컴퓨터 소프트웨어 저작권 침해 사건에서 중요한 선례가 되었습니다.

이 판례에서는 소위 추상(Abstraction), 비저작권요소 제거(Filtering), 그리고 비교(Comparison) 의 소위 3단계 기준을 정립하였습니다.
그리고그 후에 실질적 유사성이 있는지를 판단하는 것입니다.

이 사건에서도 구조,순서,조직(structure, sequence, organization)가 저작권의 대상이 되지 않는다고는 판단하지 않았습니다. 참고 자료

이러한 미국의 Altai 사건은 우리나라 법원의 판례에서도 인정하고 있습니다.

우리나라에서 프로그램 저작권 침해 판정 기준에 관한 거의 유일한 판례가 있습니다. (판례 전문 서울중앙지방법원 2007.01.17. 선고 2005가합65093 판결)

이 판례를 읽어 보면Altai 사건에서와 같이 추상화, 비저작권요소제거,후실질적 유사성을비교 하는 3단계 과정을 사용한것을알수있습니다.

Altai사건에서는 API를 리버스엔지니어링 해서 원래 원본에 있는 아이디어와 기능을 추출한 것이었습니다. 그리고 자기 자신의 구조를 만들어 내고 자기자신의코드를 작성했던 것입니다.

소스코드를복제하지는않았습니다.

구글이 이렇게했다면 위 Altai 사건 판시에 따라 오라클은 저작권을 주장할 수 없었을 겁니다. 이것은 항소심케이스에서 항소심법원이 판시한 내용입니다.

아이디어/표현의 이분법(The idea/expression dichotomy)

아이디어와/표현의 이분법은 저작권법의 기초가 되는 이론입니다. 추상적인 이론이나 근본적인 진리 등 순수한 아이디어는 저작권으로 보호될 수없다는 이론입니다. PAMELA SAMUELSON, WHY COPYRIGHT LAW EXCLUDES SYSTEMS AND PROCESSES FROM THE SCOPE OF ITS PROTECTION, 85 TEX. L. REV. 1921 (2007)) 논문 원문
).

합체이론(The merger doctrine)

합체이론은 아이디어/표현의 이분법을 반대의 측면에서 본 이론입니다.

만일 아이디어 또는 프로세스가 표현과 분리 불가능하게 엮여 있다면 그래서 서로 분리하거나 구별할 수 없다면 그것은 저작권으로 보호되지 않는다는 것입니다.
Samuelson교수 같은 사람은 아이디어를 표현하는데 아주 소수의 방법밖에 없는 경우에는 아이디어를 보호하는 것을 피하기 위하여 저작권 보호를 인정하여서는 아니 된다고 이 원칙을 이해하고 있습니다.

합체이론은 저작물성의 성립에 관한 이론입니다.

관용적 장면의 이론(scènes à faire doctrine)

관용적 장면의 이론(scènes à faire doctrine) 은 영화작품의 저작권침해를 다룰 때 주로 쓰이는이론입니다.

예를 들면 독일전쟁영화를 찍는 경우에 하이히틀러라는 구호를 외치는 장면들이나 맥주를 마시는 장면들 이런것들은 그러한 스토리에 필수적으로 부수되는 관용적인 장면이어서 이를 복사하더라도 저작권침해가 되지 않는다는것입니다.

그 후에 이 이론은 소프트웨어 저작권 침해 여부 사건에서도 인용이 되기도 하였습니다.

관용적 장면의 이론(scènes à faire doctrine )은 침해여부 판단에 관한 이론으로 피고가 입증하여야 합니다.

오픈 소스 제품들의 총 집합-안드로이드

본 오라클 대 구글 사건은 Linux, Java, 안드로이드라는 오픈 소스 소프트웨어를 이해하지 않고는 그 배경을 이해하기 어렵습니다.

아니 오픈 소스 소프트웨어를 모르면 이제 컴퓨터 산업 자체를 이해하기 어렵습니다.

그리고 이 사건은 그 이전의 Altai, Saga사건들과 같이 독점적 소프트웨어 또는 클로즈드 소프트웨어(Proprietary software, closed software)에서의 침해 문제와는 전혀 다릅니다.

즉 이 전에는 프로그램의 기능이나 API 네이밍 형식을 알아내기 위하여 실행파일을 리버스 엔지니어링 할 수 밖에 없었습니다.

그러나 이 사건에서 문제가 된 Java는 오픈 소스로서 소스코드를 전체적으로 복제할 수 있었고 API의 구성요소로서의 클라스나 메소드의 내용을 리버스 엔지니어링 없이 정확하게 알 수가 있었던 것입니다.

그러므로 구체적인 결론(향후 전망)에 앞서서 이 사건에서 등장한 오픈 소스 이야기를 해 보도록 하겠습니다.

이 사건에서 문제가 된 안드로이드 운영 체제는 Linux 운영 체제를 기초로 하고 있습니다.

Linux 운영 체제

Linux 운영 체제는 기본적으로 소스 코드 공개 요건이 가장 강한 GPL2.0 라이선스 조건에 따라 오픈 소스로 개발되었고 그리고 지금도 GPL2.0 라이선스에 의해 오픈 소스로 유지되고 있는 가장 시장 점유율이 높은 운영체제입니다.

슈퍼컴퓨터 10대 중 9대가 Linux 운영 체제를 사용하고 있습니다. 그리고 Urbana Champaign 소재 일리노이 주립 대학에 세계에서 가장 큰 슈퍼컴퓨터가 있는데 이 컴퓨터에서도Linux 운영 체제를 쓰고 있다 합니다.

처음에는 Linus Torvalds 라는 한 프로그래머에 의해 그 커널이 오픈 소스 라이선스 GPL 2.0으로 공개되었습니다.

GPL 2.0라이선스는 그 소프트웨어를 누구나 자유롭게 사용 수정 배포할 수 있습니다.

그러나 그 결과물은 다시 GPL 2.0 라이선스에 의해 공개되어야 한다는 조건을 가지고 있습니다.

한 분석에 의하면 Linux kernel의 75%가 회사에 있는 사람들에 의해 개발되었다고 하고 있습니다. (AN ANALYSIS OF THE LINUX KERNEL SHOWED 75 PERCENT OF THE CODE FROM DECEMBER 2008 TO JANUARY 2010 WAS DEVELOPED BY PROGRAMMERS WORKING FOR CORPORATIONS, LEAVING ABOUT 18 PERCENT TO VOLUNTEERS AND 7% UNCLASSIFIED)”75% OF LINUX CODE NOW WRITTEN BY PAID DEVELOPERS”. APC.RETRIEVED JANUARY 22, 2010.

Linux kernel은 "집단 지성의 산물"인 것이고 GPL2.0라이선스가 이러한 것을 가능하게 한 것입니다.

처음에는 10,000줄이었던 핵심 코드가 2001년도에는 1,900만 라인으로 성장하였습니다.
.
2001년도의 Linux의 전체 소스 코드 라인 수는 이미 3천만 줄에 달하였습니다(WHEELER, DAVID A (29 JULY 2002). “MORE THAN A GIGABUCK: ESTIMATING GNU/LINUX’S SIZE”. RETRIEVED MAY 11, 2006.

비슷한 시기에 배포되었던 Windows 98의 코드 라인 수는 1천3백만 라인입니다(관련 근거).

2008년 60%의 웹 서버가 Linux에 의해 작동되고 있습니다.(IN SEPTEMBER 2008 MICROSOFT CEO STEVE BALLMER STATED THAT 60% OF WEB SERVERS RAN LINUX VERSUS 40% THAT RAN WINDOWS SERVER).

즉, 오픈소스프로젝트의 성공 여부는 프로젝트 기안자의 노력이 아니라 기여자(Contributor)들의 활동이 얼마나 활발한가에 달려 있는 것입니다.

Java의 발전과 오픈 소스

Java는 처음에는 비공식적으로 공개되어 운영되다가 2007년에 GPL 2.0 라이선스 조건으로 오픈 소스화하였습니다.

Java는 처음에는 8개의 API로 시작되었습니다. 그러다가 이것이 오픈 소스화 되면서 막대한 참여자들의 노력으로 168개의 API를 가진 강력한 컴퓨터 프로그래밍 언어로 자리 잡게 되었습니다.

Java가 처음 시작된 것은 당시의 독점적인 지위에 있었던 Microsoft사의 독주를 막기 위한 것이었습니다.

아래 그림을 보면 자바의 구조를 알 수가 있습니다.

즉 Java를 쓰면 Windows프로그램의 API를 사용할 필요가 없게 됩니다.

다른 플랫폼에서도 마찬가지이나 특히 Java 개발자들은 Windows 운영체제의 독점체제를 방지하기 위한 목적으로 Java를 시작한 것이었습니다.

Java는 현재 압도적으로 많은 프로그래머들의 관심대상이자 사용 언어입니다.

2012년 경에는 약 9백만명의 자바 프로그래머들이 있었습니다.

현재 전세계적으로 자바 프로그래머들의 숫자는 10,743,000명 정도가 될 것으로 추정하고 있습니다.(근거 자료)

이러한 Java의 성공도 Java 가상 머신과 API를 오픈 소스로 공개하여 집단 저작을 한 결과입니다.

Java가 GPL 2.0 라이선스 외에 상용라이선스로 이중 라이선스 구조를 가지고 있었습니다.

구글이 이를 인식하고 있었습니다.

법정에 나온 증거.참고 블로그

Java는 GPL 2.0 에 Classpath Exception이라는 예외 조항을 둔 오픈 소스 라이선스 체제를 가지고 있습니다. 이 라이선스 체제는 링킹을 허용하기 때문에 상업적으로 이용이 용이합니다. 포럼 자료

이것도 Java의 하나의 성공 요인으로 꼽는 사람들도 있습니다.