저작권-혹 복사의 의미...
글쓴이: geekforum / 작성시간: 수, 2000/06/28 - 1:06오후
전에 모 신문에서
우리나라 오케스트라나 합창단 같은 경우 인쇄되지 않은..
손을 베낀 악보를 사용하여 연습및 연주를 한다라는
기사를 본 적이 있습니다.
왜 손으로 베낀 악보를 사용하느냐고 기자가 관계자에게
물어보니 저작권때문에 그렇다는 것이읍니다.
저작권을 물어서 연주나 연습을 하려면 상당한 돈이 들지만
저작권을 가진 악보를 가져다가 손으로 베낀 다음
한 두소절만 다르게 하면 저작권을 피해 갈 수 있기때문
이라는 것입니다. 한두 소절정도야 아주 약간 틀리게 하면
솔직히 전공자가 아닌 이상 잘 모르죠..
위에서처럼
하나의 저작권을 가진 소스를 구한 다음
모든 내용을 새로이 타이핑 하면서 약간의 내용을 고친다
라고 하면 새로이 타이핑한 소스는 타이핑한 사람이
저작권을 주장할 수 있을까요?
그리고
GNU/LINUX 에서
기존의 UNIX의 저작권을 피하기위해 모든 기반 프로그램들을
새로이 작성하였다고 한다면 이때는 어느 정도선 까지..
새로이 만들었까요?
Forums:
글틀이 wrote.. : 전에 모 신문에서 : 우리나라 오
글틀이 wrote..
: 전에 모 신문에서
: 우리나라 오케스트라나 합창단 같은 경우 인쇄되지 않은..
: 손을 베낀 악보를 사용하여 연습및 연주를 한다라는
: 기사를 본 적이 있습니다.
:
: 왜 손으로 베낀 악보를 사용하느냐고 기자가 관계자에게
: 물어보니 저작권때문에 그렇다는 것이읍니다.
:
: 저작권을 물어서 연주나 연습을 하려면 상당한 돈이 들지만
:
: 저작권을 가진 악보를 가져다가 손으로 베낀 다음
: 한 두소절만 다르게 하면 저작권을 피해 갈 수 있기때문
: 이라는 것입니다. 한두 소절정도야 아주 약간 틀리게 하면
: 솔직히 전공자가 아닌 이상 잘 모르죠..
:
잘은 모릅니다만 클래식 악보는 여러가지 종류가 있습니다.
베토벤이나 모짜르트가 쓴 원래 악보는 copyright가 아예 없죠.
누구나 쓸 수 있는 Public domain에 속합니다. 막말로
그때 악보 내용을 이렇게 팔아먹든 저렇게 팔아먹든 죽은지
수백년이 지난 베토벤이 뭘 하겠습니까? :)
이 경우 저작권에 해당하는 악보는 '오케스트라 용으로 편곡이
된' 악보입니다. 베토벤의 원전, 혹은 여러 종류의 필사본 중에서
괜찮은 걸 골라서 정리하고 악기별로 따로따로 만든거죠. 내용이
바뀌었는지는 잘 모르겠습니다만... 국내 오케스트라에서 필사를
하는 이유는 악보 프린팅 업자에게 돈을 주고 맡겨서 악보를
찍는 것이 명백해 카피라이트에 걸리니까 (공공장소에서의
상연에 쓰는 거니까 소송 걸기 딱 좋죠.) 한 카피를 사서
알아서 손으로 베끼는 거죠. 손으로 베끼든 TeX으로 조판하든
그건 별 문제가 아닐겁니다.
: 위에서처럼
: 하나의 저작권을 가진 소스를 구한 다음
: 모든 내용을 새로이 타이핑 하면서 약간의 내용을 고친다
: 라고 하면 새로이 타이핑한 소스는 타이핑한 사람이
: 저작권을 주장할 수 있을까요?
:
GPL의 경우는 이때 새로이 타이핑한 소스는 공개되어야 하며
(바이러스성 라이센스라고 그려죠. 이 특징때문에) 고친 부분은
고친 사람이 저작권을 갖고 원래 내용은 원래 내용을 쓴 사람이
저작권을 갖습니다. 상당히 합리적이에요... 소스 코드 공개의
원칙만 준수한다면요.
: 그리고
: GNU/LINUX 에서
: 기존의 UNIX의 저작권을 피하기위해 모든 기반 프로그램들을
: 새로이 작성하였다고 한다면 이때는 어느 정도선 까지..
: 새로이 만들었까요?
예를들어 ls 명령어의 경우 ls -l 하면 자세한 파일 리스트가
나오죠? GNU fileutils의 경우 ls -l 하면 다른 유닉스 시스템과
똑같은 형식으로 출력이 되도록 재주껏 짠 겁니다. 시스템 콜도
마찬가지로 만들어졌구요. 규격대로 흉내내는겁니다. 그리고
소스코드 공개를 보장하기 위해서 GPL로 라이센스를 걸어버렸죠.
유닉스 진영의 재밌는 점은... 상용 유닉스도 소스코드가 공개된
경우가 많다는 점입니다. (오리지날 AT&T 유닉스가 대표적이죠.)
대신 소스코드를 마음대로 베껴 쓰지 못하는 문제가 있었죠. 뭐...
돈을 내면 가능했습니다만 돈 규모가 장난이 아니니까.
이런 까닭으로 라이센스 문제가 불거지기 전까지는 대충대충 패치해서
프로그램을 많이 썼었다고 합니다. AT&T나 기타 상용 유닉스 업체가
시비를 걸기 시작하니까 FreeBSD같이 새로 코드를 rewriting하는
움직임이 생겼습니다. Linux는 태생은 좀 다르지만, 라이센스를
피하는 것은 마찬가지죠.
BSD나 MIT X 라이센스로 공개된 프로그램이 아니라면 아마
모두 새로 만들었을겁니다. 대표적인 케이스가 gcc, gdb와 같은
킬러 어플들이죠.
BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
자신이 없네요.
많은 분들이 궁금해하시는 GPL과 BSD를 섞어쓰면 어떻게 되는지 의
많은 분들이 궁금해하시는 GPL과 BSD를 섞어쓰면 어떻게 되는지
의 정답은 GPL입니다. 왜냐하면 라이센스의 엄격성이 GPL > BSD이기
때문이죠. 실제로 GNU Mach 커널은 BSD 라이선스를 따르는 Utah Mach4 커널과 GPL을 따르는 리눅스 디바이스 드라이버를 합쳐서 전체
적으로 GPL하에 배포하고 있습니다. 물론 그중에 Mach 부분만 떼어
내면 그건 BSD 라이센스의 적용만을 받게 되지요. 몇몇 사람들은
마이크로소프트처럼 Kerberos를 마음대로 뜯어고쳐 호환이 안되게
만든 예를 들어 BSD 라이선스의 단점을 지적하곤 하지만 BSD 사람들은 어떤 면에서 GNU 사람들보다 더 자유를 중요시하기 때문에 소프트웨
어를 가지고 어떤 일을 하든 그건 개인적인 판단의 문제라고 생각합니다. 물론 다른 사람의 소소를 가져다가 자기가 만들었다고 이름을 싹
바꾸는 일은 용납하지 않지만요. 소프트웨어의 목적과 용도에 따라
GPL과 BSD를 적절히 적용하는 게 가장 좋은 방법이라고 생각합니다.
: BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
: 모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
: 자신이 없네요.
logout wrote.. : : 예를들어 ls 명령어의 경우 l
logout wrote..
:
: 예를들어 ls 명령어의 경우 ls -l 하면 자세한 파일 리스트가
: 나오죠? GNU fileutils의 경우 ls -l 하면 다른 유닉스 시스템과
: 똑같은 형식으로 출력이 되도록 재주껏 짠 겁니다. 시스템 콜도
: 마찬가지로 만들어졌구요. 규격대로 흉내내는겁니다. 그리고
: 소스코드 공개를 보장하기 위해서 GPL로 라이센스를 걸어버렸죠.
:
: 유닉스 진영의 재밌는 점은... 상용 유닉스도 소스코드가 공개된
: 경우가 많다는 점입니다. (오리지날 AT&T 유닉스가 대표적이죠.)
: 대신 소스코드를 마음대로 베껴 쓰지 못하는 문제가 있었죠. 뭐...
: 돈을 내면 가능했습니다만 돈 규모가 장난이 아니니까.
소스코드를 볼 수 있는 거랑 소스코드를 구입할 수 있는 거랑은
다릅니다. AT&T코드나 BSD/OS코드는 *구입해야만* 볼 수 있죠.
자유로이 볼 수 있는 것과는 다릅니다.
: 이런 까닭으로 라이센스 문제가 불거지기 전까지는 대충대충 패치해서
: 프로그램을 많이 썼었다고 합니다. AT&T나 기타 상용 유닉스 업체가
: 시비를 걸기 시작하니까 FreeBSD같이 새로 코드를 rewriting하는
: 움직임이 생겼습니다. Linux는 태생은 좀 다르지만, 라이센스를
: 피하는 것은 마찬가지죠.
이 이야기는 조금 깁니다. 4.3BSD Networking Release 1부터의
스토리를 좀 아셔야 합니다. "오픈 소스"라는 책에 보면 BSD에 대한
장이 있으니 그것을 읽어보시면 가장 정확합니다.
4.3BSD Net/2에 기반했던 386BSD과 그 패밀리(FreeBSD, NetBSD)
는 AT&T - UCB간의 분쟁 종결에 의해서 4.4BSD 코드로 전환해야만
했죠. 그때 전체적인 rewriting이 한번 있었습니다.
Linux의 경우 이미 공개된 GNU/BSD의 코드를 차용했기 때문에
처음부터 유닉스 라이센스에 대한 시비는 없었죠. 물론 386BSD와
리눅스가 거의 동시에 생겨났지만 이러한 사건 때문에 리눅스가 더
앞서나갈 수 있었다는 이야기도 있습니다. (꼭 그렇게만 이야기할
수 없는 점도 있지만)
: BSD나 MIT X 라이센스로 공개된 프로그램이 아니라면 아마
: 모두 새로 만들었을겁니다. 대표적인 케이스가 gcc, gdb와 같은
: 킬러 어플들이죠.
:
: BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
: 모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
: 자신이 없네요.
공개 BSD들은 모두 GPL 코드를 정도는 있지만 사용하고 있습니다.
가령 gcc, binutils, gdb는 사용하지 않을 수 없기 때문이죠.
이 경우 BSD라이센스에 해당하지 않는 것들은 모두 별도의 디렉토리에
관리하고 있고 되도록이면 코드를 섞어쓰지 않죠(섞어쓰기 시작하면
GPL에 걸리기 때문에). 다만 *BSD는 가령 gcc의 경우 해당 코드를
모두 가져다 쓰는게 아니라 필요한 부분만 가져다 알맞게 고쳐서
사용합니다. 즉 *BSD에서는 BSD make를 쓰기 때문에, gcc를
컴파일한다고 해도 gcc 설치의 일반적인 절차인 ./configure
스크립트를 사용하지 않고, BSD make용 Makefile을 따로 만들어
씁니다. 물론 이러한 부분은 모두 공개되어 있고요(GPL이니까!)
중요한 것은 어느 라이센스가 더 좋은 결과를 낳느냐하는 것이지요. 제
중요한 것은 어느 라이센스가 더 좋은 결과를 낳느냐하는 것이
지요. 제가 보기에는 BSD는 문제가 많습니다. 더 많은 자유가 있다고
말하는 것은 제가 보기에는 사기입니다. 스스로 보호를 할 수없다면
--- 지금과 같이 보호하지 않으면 없어지는 시기에-- 의미가 없다고
생각합니다.
물론 BSD를 쓰시는 분들은 다르게 생각하겠지만 제가 보기에는
포기하고 Linux로 Merge하는 것이 더 좋게 보일 때도 있습니다.
비록 개인적인 생각이지만요. BSD는 스스로를 지키기위해서 발악을
하는 것 처럼보일때가 있습니다. 중요한 것은 어느것이 더 좋은--
저처럼 특수한 하드웨어를 쓰더라도--지원을 하느냐인데도 말이지요.
이유없는 반항처럼...
준호 wrote..
: logout wrote..
: :
: : 예를들어 ls 명령어의 경우 ls -l 하면 자세한 파일 리스트가
: : 나오죠? GNU fileutils의 경우 ls -l 하면 다른 유닉스 시스템과
: : 똑같은 형식으로 출력이 되도록 재주껏 짠 겁니다. 시스템 콜도
: : 마찬가지로 만들어졌구요. 규격대로 흉내내는겁니다. 그리고
: : 소스코드 공개를 보장하기 위해서 GPL로 라이센스를 걸어버렸죠.
: :
: : 유닉스 진영의 재밌는 점은... 상용 유닉스도 소스코드가 공개된
: : 경우가 많다는 점입니다. (오리지날 AT&T 유닉스가 대표적이죠.)
: : 대신 소스코드를 마음대로 베껴 쓰지 못하는 문제가 있었죠. 뭐...
: : 돈을 내면 가능했습니다만 돈 규모가 장난이 아니니까.
:
: 소스코드를 볼 수 있는 거랑 소스코드를 구입할 수 있는 거랑은
: 다릅니다. AT&T코드나 BSD/OS코드는 *구입해야만* 볼 수 있죠.
: 자유로이 볼 수 있는 것과는 다릅니다.
:
: : 이런 까닭으로 라이센스 문제가 불거지기 전까지는 대충대충 패치해서
: : 프로그램을 많이 썼었다고 합니다. AT&T나 기타 상용 유닉스 업체가
: : 시비를 걸기 시작하니까 FreeBSD같이 새로 코드를 rewriting하는
: : 움직임이 생겼습니다. Linux는 태생은 좀 다르지만, 라이센스를
: : 피하는 것은 마찬가지죠.
:
: 이 이야기는 조금 깁니다. 4.3BSD Networking Release 1부터의
: 스토리를 좀 아셔야 합니다. "오픈 소스"라는 책에 보면 BSD에 대한
: 장이 있으니 그것을 읽어보시면 가장 정확합니다.
:
: 4.3BSD Net/2에 기반했던 386BSD과 그 패밀리(FreeBSD, NetBSD)
: 는 AT&T - UCB간의 분쟁 종결에 의해서 4.4BSD 코드로 전환해야만
: 했죠. 그때 전체적인 rewriting이 한번 있었습니다.
:
: Linux의 경우 이미 공개된 GNU/BSD의 코드를 차용했기 때문에
: 처음부터 유닉스 라이센스에 대한 시비는 없었죠. 물론 386BSD와
: 리눅스가 거의 동시에 생겨났지만 이러한 사건 때문에 리눅스가 더
: 앞서나갈 수 있었다는 이야기도 있습니다. (꼭 그렇게만 이야기할
: 수 없는 점도 있지만)
:
: : BSD나 MIT X 라이센스로 공개된 프로그램이 아니라면 아마
: : 모두 새로 만들었을겁니다. 대표적인 케이스가 gcc, gdb와 같은
: : 킬러 어플들이죠.
: :
: : BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
: : 모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
: : 자신이 없네요.
:
: 공개 BSD들은 모두 GPL 코드를 정도는 있지만 사용하고 있습니다.
: 가령 gcc, binutils, gdb는 사용하지 않을 수 없기 때문이죠.
: 이 경우 BSD라이센스에 해당하지 않는 것들은 모두 별도의 디렉토리에
: 관리하고 있고 되도록이면 코드를 섞어쓰지 않죠(섞어쓰기 시작하면
: GPL에 걸리기 때문에). 다만 *BSD는 가령 gcc의 경우 해당 코드를
: 모두 가져다 쓰는게 아니라 필요한 부분만 가져다 알맞게 고쳐서
: 사용합니다. 즉 *BSD에서는 BSD make를 쓰기 때문에, gcc를
: 컴파일한다고 해도 gcc 설치의 일반적인 절차인 ./configure
: 스크립트를 사용하지 않고, BSD make용 Makefile을 따로 만들어
: 씁니다. 물론 이러한 부분은 모두 공개되어 있고요(GPL이니까!)
GPL wrote.. : 중요한 것은 어느 라이센스가 더 좋은 결과를
GPL wrote..
: 중요한 것은 어느 라이센스가 더 좋은 결과를 낳느냐하는 것이
: 지요. 제가 보기에는 BSD는 문제가 많습니다. 더 많은 자유가 있다고
: 말하는 것은 제가 보기에는 사기입니다. 스스로 보호를 할 수없다면
: --- 지금과 같이 보호하지 않으면 없어지는 시기에-- 의미가 없다고
: 생각합니다.
보호하지 않으면 없어진다... 그렇다면 현재까지 살아남고 또
BSD의 그 난리 이후에도 BSD 라이센스 스타일을 고수하는
XFree86, Apache와 GPL같은 강제 조항이 없는 perl등이 어떻게
선두적인 성공적인 오픈 소스로 남게 되었을지 설명할 방법이 없군요.
위와 같은 논리라면 이들 어플리케이션이 GPL로 바뀌었거나
처음부터 GPL로 시작하였어야 정상 아닐까요?
: 물론 BSD를 쓰시는 분들은 다르게 생각하겠지만 제가 보기에는
: 포기하고 Linux로 Merge하는 것이 더 좋게 보일 때도 있습니다.
: 비록 개인적인 생각이지만요. BSD는 스스로를 지키기위해서 발악을
: 하는 것 처럼보일때가 있습니다. 중요한 것은 어느것이 더 좋은--
: 저처럼 특수한 하드웨어를 쓰더라도--지원을 하느냐인데도 말이지요.
: 이유없는 반항처럼...
사실 자신을 지키기 위해서 노력하는 것은 GPL입니다 - 자유를 위한
강제 조항을 추가하면서까지 -. 하지만 그것이 나쁘다는 말은 하고
싶지 않군요. GPL의 탄생에는 RMS의 이력이 크게 작용하기 때문에,
그리고 그러한 조항에 대한 것도 충분히 이해가 됩니다.
BSD 코드가 상업적 영역에 가면 돌아오지 않는다 - 하지만 실제로
BSD코드를 쓰는 MacOS X도 Darwin이란 이름으로 핵심부(GUI제외)
가 오픈소스화 되어 있고, 애플의 엔지니어는 BSD진영과 협력하여
유닉스에 새로운 기능을 추가하려 하고 있습니다. FreeBSD에
포함된 NETGRAPH라는 네트워크 스택도 IBM에서 만들어서 다시
오픈 소스로(BSD라이센스로) 돌려준 것입니다. BSDi사도 이번에
BSD/OS의 SMP코드를 개선해서 FreeBSD에 뛰어난 SMP 커널 스레드
기능을 넣으려 하고 있죠. 따라서 BSD 라이센스가 자신을 지킬
수 없다는 점은 조항상으로 인정할 수 있지만, 현실적으로 오픈
소스를 인정하는 여러 영리/비영리 단체에 의해 다시 개발자들에게
그 성과가 돌아오고 있습니다. 물론 그렇지 않을 수도 있다는 점이
특징이겠죠...
반면에 리눅스 기반으로 무엇무엇을 만든다 하면서 정작 자신들이
건드린 GPL코드조차도(독자개발한 코드야 자신의 선택이므로 예외로
치고) 공개하지 않는 일부 회사들을 생각해 보세요. 차라리 BSD코드를
썼으면 비난조차 들을 필요가 없지 않을까요?
제가 말씀드린 보호라는 것은 개작물등을 다시 다른 사용자가 자유롭게이
제가 말씀드린 보호라는 것은 개작물등을 다시 다른 사용자가 자유롭게
이용할 수 있느냐하는 뜻입니다.(제가 한국어가 약해서 :-))
BSD를 이용한 많은 상업용 제품이나 운영체계 중에서 다른 사람들도
같이 이용할 수 있는 것은 상당히 드문것으로 압니다.
GPL의 경우 무조건 무료로 얻을 수 있지는 않더라도 그 결과물을 다른
사람들이 자유롭게 이용을 할 수는 있지요.
준호 wrote..
: GPL wrote..
: : 중요한 것은 어느 라이센스가 더 좋은 결과를 낳느냐하는 것이
: : 지요. 제가 보기에는 BSD는 문제가 많습니다. 더 많은 자유가 있다고
: : 말하는 것은 제가 보기에는 사기입니다. 스스로 보호를 할 수없다면
: : --- 지금과 같이 보호하지 않으면 없어지는 시기에-- 의미가 없다고
: : 생각합니다.
:
: 보호하지 않으면 없어진다... 그렇다면 현재까지 살아남고 또
: BSD의 그 난리 이후에도 BSD 라이센스 스타일을 고수하는
: XFree86, Apache와 GPL같은 강제 조항이 없는 perl등이 어떻게
: 선두적인 성공적인 오픈 소스로 남게 되었을지 설명할 방법이 없군요.
: 위와 같은 논리라면 이들 어플리케이션이 GPL로 바뀌었거나
: 처음부터 GPL로 시작하였어야 정상 아닐까요?
:
: : 물론 BSD를 쓰시는 분들은 다르게 생각하겠지만 제가 보기에는
: : 포기하고 Linux로 Merge하는 것이 더 좋게 보일 때도 있습니다.
: : 비록 개인적인 생각이지만요. BSD는 스스로를 지키기위해서 발악을
: : 하는 것 처럼보일때가 있습니다. 중요한 것은 어느것이 더 좋은--
: : 저처럼 특수한 하드웨어를 쓰더라도--지원을 하느냐인데도 말이지요.
: : 이유없는 반항처럼...
:
: 사실 자신을 지키기 위해서 노력하는 것은 GPL입니다 - 자유를 위한
: 강제 조항을 추가하면서까지 -. 하지만 그것이 나쁘다는 말은 하고
: 싶지 않군요. GPL의 탄생에는 RMS의 이력이 크게 작용하기 때문에,
: 그리고 그러한 조항에 대한 것도 충분히 이해가 됩니다.
:
: BSD 코드가 상업적 영역에 가면 돌아오지 않는다 - 하지만 실제로
: BSD코드를 쓰는 MacOS X도 Darwin이란 이름으로 핵심부(GUI제외)
: 가 오픈소스화 되어 있고, 애플의 엔지니어는 BSD진영과 협력하여
: 유닉스에 새로운 기능을 추가하려 하고 있습니다. FreeBSD에
: 포함된 NETGRAPH라는 네트워크 스택도 IBM에서 만들어서 다시
: 오픈 소스로(BSD라이센스로) 돌려준 것입니다. BSDi사도 이번에
: BSD/OS의 SMP코드를 개선해서 FreeBSD에 뛰어난 SMP 커널 스레드
: 기능을 넣으려 하고 있죠. 따라서 BSD 라이센스가 자신을 지킬
: 수 없다는 점은 조항상으로 인정할 수 있지만, 현실적으로 오픈
: 소스를 인정하는 여러 영리/비영리 단체에 의해 다시 개발자들에게
: 그 성과가 돌아오고 있습니다. 물론 그렇지 않을 수도 있다는 점이
: 특징이겠죠...
:
: 반면에 리눅스 기반으로 무엇무엇을 만든다 하면서 정작 자신들이
: 건드린 GPL코드조차도(독자개발한 코드야 자신의 선택이므로 예외로
: 치고) 공개하지 않는 일부 회사들을 생각해 보세요. 차라리 BSD코드를
: 썼으면 비난조차 들을 필요가 없지 않을까요?
GPL wrote.. : 제가 말씀드린 보호라는 것은 개작물등을 다시
GPL wrote..
: 제가 말씀드린 보호라는 것은 개작물등을 다시 다른 사용자가 자유롭게
: 이용할 수 있느냐하는 뜻입니다.(제가 한국어가 약해서 :-))
뉘앙스의 차이는 있겠지만, 그것이 강제되는 것이 GPL이고,
아닌 것의 대표적인 것이 BSD 라이센스겠죠.
: BSD를 이용한 많은 상업용 제품이나 운영체계 중에서 다른 사람들도
: 같이 이용할 수 있는 것은 상당히 드문것으로 압니다.
: GPL의 경우 무조건 무료로 얻을 수 있지는 않더라도 그 결과물을 다른
: 사람들이 자유롭게 이용을 할 수는 있지요.
네. 맞습니다.
이것 때문에 저는 상업 영역으로 들어갔던 코드가 다시 오픈 소스로
나온 예를(전체가 아니라 일부일지라도) 들었습니다. GPL은 이렇게
할 수는 없기 때문에 나름대로의 영역을 구축하지 않으면 안되죠.
그러나 GPL코드를 이용했으면 공개해야 함에도 불구하고 그렇지 않을
우려가 있다고 이야기도 하였습니다. 티나게 쓰지 않으면 알길이 없죠.
즉 "무조건 자유롭게 이용해야 한다" 가 GPL이고, "자유롭게 이용하는
것이 좋지만 꼭 그럴 필요는 없다"가 BSD라는 것입니다.
어느쪽인가는 정치적인 선택이라고 말할 수 있겠죠.. 전 그렇다고
해서 BSD에 특별히 매달리고 싶은 생각도 없습니다. 상황을 보아서
적절한 것을 택하겠죠..
준호 wrote.. : GPL wrote.. : : 제가 말씀드린
준호 wrote..
: GPL wrote..
: : 제가 말씀드린 보호라는 것은 개작물등을 다시 다른 사용자가 자유롭게
: : 이용할 수 있느냐하는 뜻입니다.(제가 한국어가 약해서 :-))
:
: 뉘앙스의 차이는 있겠지만, 그것이 강제되는 것이 GPL이고,
: 아닌 것의 대표적인 것이 BSD 라이센스겠죠.
:
: : BSD를 이용한 많은 상업용 제품이나 운영체계 중에서 다른 사람들도
: : 같이 이용할 수 있는 것은 상당히 드문것으로 압니다.
: : GPL의 경우 무조건 무료로 얻을 수 있지는 않더라도 그 결과물을 다른
: : 사람들이 자유롭게 이용을 할 수는 있지요.
:
: 네. 맞습니다.
:
: 이것 때문에 저는 상업 영역으로 들어갔던 코드가 다시 오픈 소스로
: 나온 예를(전체가 아니라 일부일지라도) 들었습니다. GPL은 이렇게
: 할 수는 없기 때문에 나름대로의 영역을 구축하지 않으면 안되죠.
: 그러나 GPL코드를 이용했으면 공개해야 함에도 불구하고 그렇지 않을
: 우려가 있다고 이야기도 하였습니다. 티나게 쓰지 않으면 알길이 없죠.
:
다시 나온 것이 있다니 즐거운 일이네요 :-) 그리고 GPL을 공개하지
않는 곳이 있다면 문제입니다. 그냥 재미로 한, 두줄 고치고 마는
것이 아니라면 말이죠..
: 즉 "무조건 자유롭게 이용해야 한다" 가 GPL이고, "자유롭게 이용하는
: 것이 좋지만 꼭 그럴 필요는 없다"가 BSD라는 것입니다.
말씀이 간단하지만 비교적 정확하다고 생각합니다.
:
: 어느쪽인가는 정치적인 선택이라고 말할 수 있겠죠.. 전 그렇다고
: 해서 BSD에 특별히 매달리고 싶은 생각도 없습니다. 상황을 보아서
: 적절한 것을 택하겠죠..
예, 저도...
BSD 가 걱정해야 하는것이 code forking 이라면(BSD
BSD 가 걱정해야 하는것이 code forking 이라면
(BSD 스타일의 라이센스 반대하는 사람들이 말하는 것처럼)
GPL 이 걱정해야 하는 것은 GPL이 '사문화'되는 것이라고 봅니다.
일일이 GPL 위반 사례 추적(?) 하면서 소송 걸 수도 없는것 아닙니까. -_-;
GPL wrote..
: 준호 wrote..
: : GPL wrote..
: : : 제가 말씀드린 보호라는 것은 개작물등을 다시 다른 사용자가 자유롭게
: : : 이용할 수 있느냐하는 뜻입니다.(제가 한국어가 약해서 :-))
: :
: : 뉘앙스의 차이는 있겠지만, 그것이 강제되는 것이 GPL이고,
: : 아닌 것의 대표적인 것이 BSD 라이센스겠죠.
: :
: : : BSD를 이용한 많은 상업용 제품이나 운영체계 중에서 다른 사람들도
: : : 같이 이용할 수 있는 것은 상당히 드문것으로 압니다.
: : : GPL의 경우 무조건 무료로 얻을 수 있지는 않더라도 그 결과물을 다른
: : : 사람들이 자유롭게 이용을 할 수는 있지요.
: :
: : 네. 맞습니다.
: :
: : 이것 때문에 저는 상업 영역으로 들어갔던 코드가 다시 오픈 소스로
: : 나온 예를(전체가 아니라 일부일지라도) 들었습니다. GPL은 이렇게
: : 할 수는 없기 때문에 나름대로의 영역을 구축하지 않으면 안되죠.
: : 그러나 GPL코드를 이용했으면 공개해야 함에도 불구하고 그렇지 않을
: : 우려가 있다고 이야기도 하였습니다. 티나게 쓰지 않으면 알길이 없죠.
: :
:
: 다시 나온 것이 있다니 즐거운 일이네요 :-) 그리고 GPL을 공개하지
: 않는 곳이 있다면 문제입니다. 그냥 재미로 한, 두줄 고치고 마는
: 것이 아니라면 말이죠..
:
: : 즉 "무조건 자유롭게 이용해야 한다" 가 GPL이고, "자유롭게 이용하는
: : 것이 좋지만 꼭 그럴 필요는 없다"가 BSD라는 것입니다.
:
: 말씀이 간단하지만 비교적 정확하다고 생각합니다.
:
: :
: : 어느쪽인가는 정치적인 선택이라고 말할 수 있겠죠.. 전 그렇다고
: : 해서 BSD에 특별히 매달리고 싶은 생각도 없습니다. 상황을 보아서
: : 적절한 것을 택하겠죠..
:
: 예, 저도...
기본적으로 BSD는 사람들이 소프트웨어를 가지고 어떤 일을 하든 그것은
기본적으로 BSD는 사람들이 소프트웨어를 가지고 어떤 일을 하든 그것은 그 나름대로 존중받을 이유가 있다고 생각하는 것입니다. 소스를
공개하고 안하고는 원저자의 권한이 아니라 사용자와 개발자의 권한
이라고 생각하는 것이죠.
그리고 BSD를 한번도 쓰지 않았으면서 평가하거나 비난하는 일은 삼가해
주십시오.
GPL wrote..
: 중요한 것은 어느 라이센스가 더 좋은 결과를 낳느냐하는 것이
: 지요. 제가 보기에는 BSD는 문제가 많습니다. 더 많은 자유가 있다고
: 말하는 것은 제가 보기에는 사기입니다. 스스로 보호를 할 수없다면
: --- 지금과 같이 보호하지 않으면 없어지는 시기에-- 의미가 없다고
: 생각합니다.
: 물론 BSD를 쓰시는 분들은 다르게 생각하겠지만 제가 보기에는
: 포기하고 Linux로 Merge하는 것이 더 좋게 보일 때도 있습니다.
: 비록 개인적인 생각이지만요. BSD는 스스로를 지키기위해서 발악을
: 하는 것 처럼보일때가 있습니다. 중요한 것은 어느것이 더 좋은--
: 저처럼 특수한 하드웨어를 쓰더라도--지원을 하느냐인데도 말이지요.
: 이유없는 반항처럼...
:
: 준호 wrote..
: : logout wrote..
: : :
: : : 예를들어 ls 명령어의 경우 ls -l 하면 자세한 파일 리스트가
: : : 나오죠? GNU fileutils의 경우 ls -l 하면 다른 유닉스 시스템과
: : : 똑같은 형식으로 출력이 되도록 재주껏 짠 겁니다. 시스템 콜도
: : : 마찬가지로 만들어졌구요. 규격대로 흉내내는겁니다. 그리고
: : : 소스코드 공개를 보장하기 위해서 GPL로 라이센스를 걸어버렸죠.
: : :
: : : 유닉스 진영의 재밌는 점은... 상용 유닉스도 소스코드가 공개된
: : : 경우가 많다는 점입니다. (오리지날 AT&T 유닉스가 대표적이죠.)
: : : 대신 소스코드를 마음대로 베껴 쓰지 못하는 문제가 있었죠. 뭐...
: : : 돈을 내면 가능했습니다만 돈 규모가 장난이 아니니까.
: :
: : 소스코드를 볼 수 있는 거랑 소스코드를 구입할 수 있는 거랑은
: : 다릅니다. AT&T코드나 BSD/OS코드는 *구입해야만* 볼 수 있죠.
: : 자유로이 볼 수 있는 것과는 다릅니다.
: :
: : : 이런 까닭으로 라이센스 문제가 불거지기 전까지는 대충대충 패치해서
: : : 프로그램을 많이 썼었다고 합니다. AT&T나 기타 상용 유닉스 업체가
: : : 시비를 걸기 시작하니까 FreeBSD같이 새로 코드를 rewriting하는
: : : 움직임이 생겼습니다. Linux는 태생은 좀 다르지만, 라이센스를
: : : 피하는 것은 마찬가지죠.
: :
: : 이 이야기는 조금 깁니다. 4.3BSD Networking Release 1부터의
: : 스토리를 좀 아셔야 합니다. "오픈 소스"라는 책에 보면 BSD에 대한
: : 장이 있으니 그것을 읽어보시면 가장 정확합니다.
: :
: : 4.3BSD Net/2에 기반했던 386BSD과 그 패밀리(FreeBSD, NetBSD)
: : 는 AT&T - UCB간의 분쟁 종결에 의해서 4.4BSD 코드로 전환해야만
: : 했죠. 그때 전체적인 rewriting이 한번 있었습니다.
: :
: : Linux의 경우 이미 공개된 GNU/BSD의 코드를 차용했기 때문에
: : 처음부터 유닉스 라이센스에 대한 시비는 없었죠. 물론 386BSD와
: : 리눅스가 거의 동시에 생겨났지만 이러한 사건 때문에 리눅스가 더
: : 앞서나갈 수 있었다는 이야기도 있습니다. (꼭 그렇게만 이야기할
: : 수 없는 점도 있지만)
: :
: : : BSD나 MIT X 라이센스로 공개된 프로그램이 아니라면 아마
: : : 모두 새로 만들었을겁니다. 대표적인 케이스가 gcc, gdb와 같은
: : : 킬러 어플들이죠.
: : :
: : : BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
: : : 모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
: : : 자신이 없네요.
: :
: : 공개 BSD들은 모두 GPL 코드를 정도는 있지만 사용하고 있습니다.
: : 가령 gcc, binutils, gdb는 사용하지 않을 수 없기 때문이죠.
: : 이 경우 BSD라이센스에 해당하지 않는 것들은 모두 별도의 디렉토리에
: : 관리하고 있고 되도록이면 코드를 섞어쓰지 않죠(섞어쓰기 시작하면
: : GPL에 걸리기 때문에). 다만 *BSD는 가령 gcc의 경우 해당 코드를
: : 모두 가져다 쓰는게 아니라 필요한 부분만 가져다 알맞게 고쳐서
: : 사용합니다. 즉 *BSD에서는 BSD make를 쓰기 때문에, gcc를
: : 컴파일한다고 해도 gcc 설치의 일반적인 절차인 ./configure
: : 스크립트를 사용하지 않고, BSD make용 Makefile을 따로 만들어
: : 씁니다. 물론 이러한 부분은 모두 공개되어 있고요(GPL이니까!)
어느 BSD 개발자가 라이센스 문제에 관해서 다음과 같은 말을 남겼습니다
어느 BSD 개발자가 라이센스 문제에 관해서 다음과 같은 말을 남겼습니다.
'설령 MS가 BSD 코드를 사용해서 상용 프로그램을 개발한다고 해도
결과적으로 뛰어난 BSD 코드가 사용자들에게 큰 혜택이 될것이므로
그걸로 좋다.'
바보같은 말일지도 모르겠지만 아래에서 쓰신것처럼 '보호하지 않으면
없어지는 시대'에 보호받기를 거부하는(밑에는 또 지키려고 발악하는
이라고 하시는데..) BSD 개발자들의 BSD에 대한 자부심과 장인정신은
옆에서 지켜보기에도 상당히 매력적입니다.
물론 이런게 싫다면 할 수 없는 일이지만요..
방준영 wrote..
: 기본적으로 BSD는 사람들이 소프트웨어를 가지고 어떤 일을 하든 그것은 그 나름대로 존중받을 이유가 있다고 생각하는 것입니다. 소스를
: 공개하고 안하고는 원저자의 권한이 아니라 사용자와 개발자의 권한
: 이라고 생각하는 것이죠.
:
: 그리고 BSD를 한번도 쓰지 않았으면서 평가하거나 비난하는 일은 삼가해
: 주십시오.
:
: GPL wrote..
: : 중요한 것은 어느 라이센스가 더 좋은 결과를 낳느냐하는 것이
: : 지요. 제가 보기에는 BSD는 문제가 많습니다. 더 많은 자유가 있다고
: : 말하는 것은 제가 보기에는 사기입니다. 스스로 보호를 할 수없다면
: : --- 지금과 같이 보호하지 않으면 없어지는 시기에-- 의미가 없다고
: : 생각합니다.
: : 물론 BSD를 쓰시는 분들은 다르게 생각하겠지만 제가 보기에는
: : 포기하고 Linux로 Merge하는 것이 더 좋게 보일 때도 있습니다.
: : 비록 개인적인 생각이지만요. BSD는 스스로를 지키기위해서 발악을
: : 하는 것 처럼보일때가 있습니다. 중요한 것은 어느것이 더 좋은--
: : 저처럼 특수한 하드웨어를 쓰더라도--지원을 하느냐인데도 말이지요.
: : 이유없는 반항처럼...
: :
: : 준호 wrote..
: : : logout wrote..
: : : :
: : : : 예를들어 ls 명령어의 경우 ls -l 하면 자세한 파일 리스트가
: : : : 나오죠? GNU fileutils의 경우 ls -l 하면 다른 유닉스 시스템과
: : : : 똑같은 형식으로 출력이 되도록 재주껏 짠 겁니다. 시스템 콜도
: : : : 마찬가지로 만들어졌구요. 규격대로 흉내내는겁니다. 그리고
: : : : 소스코드 공개를 보장하기 위해서 GPL로 라이센스를 걸어버렸죠.
: : : :
: : : : 유닉스 진영의 재밌는 점은... 상용 유닉스도 소스코드가 공개된
: : : : 경우가 많다는 점입니다. (오리지날 AT&T 유닉스가 대표적이죠.)
: : : : 대신 소스코드를 마음대로 베껴 쓰지 못하는 문제가 있었죠. 뭐...
: : : : 돈을 내면 가능했습니다만 돈 규모가 장난이 아니니까.
: : :
: : : 소스코드를 볼 수 있는 거랑 소스코드를 구입할 수 있는 거랑은
: : : 다릅니다. AT&T코드나 BSD/OS코드는 *구입해야만* 볼 수 있죠.
: : : 자유로이 볼 수 있는 것과는 다릅니다.
: : :
: : : : 이런 까닭으로 라이센스 문제가 불거지기 전까지는 대충대충 패치해서
: : : : 프로그램을 많이 썼었다고 합니다. AT&T나 기타 상용 유닉스 업체가
: : : : 시비를 걸기 시작하니까 FreeBSD같이 새로 코드를 rewriting하는
: : : : 움직임이 생겼습니다. Linux는 태생은 좀 다르지만, 라이센스를
: : : : 피하는 것은 마찬가지죠.
: : :
: : : 이 이야기는 조금 깁니다. 4.3BSD Networking Release 1부터의
: : : 스토리를 좀 아셔야 합니다. "오픈 소스"라는 책에 보면 BSD에 대한
: : : 장이 있으니 그것을 읽어보시면 가장 정확합니다.
: : :
: : : 4.3BSD Net/2에 기반했던 386BSD과 그 패밀리(FreeBSD, NetBSD)
: : : 는 AT&T - UCB간의 분쟁 종결에 의해서 4.4BSD 코드로 전환해야만
: : : 했죠. 그때 전체적인 rewriting이 한번 있었습니다.
: : :
: : : Linux의 경우 이미 공개된 GNU/BSD의 코드를 차용했기 때문에
: : : 처음부터 유닉스 라이센스에 대한 시비는 없었죠. 물론 386BSD와
: : : 리눅스가 거의 동시에 생겨났지만 이러한 사건 때문에 리눅스가 더
: : : 앞서나갈 수 있었다는 이야기도 있습니다. (꼭 그렇게만 이야기할
: : : 수 없는 점도 있지만)
: : :
: : : : BSD나 MIT X 라이센스로 공개된 프로그램이 아니라면 아마
: : : : 모두 새로 만들었을겁니다. 대표적인 케이스가 gcc, gdb와 같은
: : : : 킬러 어플들이죠.
: : : :
: : : : BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
: : : : 모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
: : : : 자신이 없네요.
: : :
: : : 공개 BSD들은 모두 GPL 코드를 정도는 있지만 사용하고 있습니다.
: : : 가령 gcc, binutils, gdb는 사용하지 않을 수 없기 때문이죠.
: : : 이 경우 BSD라이센스에 해당하지 않는 것들은 모두 별도의 디렉토리에
: : : 관리하고 있고 되도록이면 코드를 섞어쓰지 않죠(섞어쓰기 시작하면
: : : GPL에 걸리기 때문에). 다만 *BSD는 가령 gcc의 경우 해당 코드를
: : : 모두 가져다 쓰는게 아니라 필요한 부분만 가져다 알맞게 고쳐서
: : : 사용합니다. 즉 *BSD에서는 BSD make를 쓰기 때문에, gcc를
: : : 컴파일한다고 해도 gcc 설치의 일반적인 절차인 ./configure
: : : 스크립트를 사용하지 않고, BSD make용 Makefile을 따로 만들어
: : : 씁니다. 물론 이러한 부분은 모두 공개되어 있고요(GPL이니까!)
BSD는 CSRG에서 꾸준하게 AT&T 코드를 제거하는 작업을 수
BSD는 CSRG에서 꾸준하게 AT&T 코드를 제거하는 작업을 수행하다가
BSD 4.3 인가 4.4 인가에서 몇개의 코드를 남겨둔 상태에서 릴리스를
했다가 (물론 그전에도 계속 릴리스는 있었지만...) 법정 분쟁에
휘말립니다. 라이센스 문제는 FreeBSD 이전에 이미 끝난 것이죠.
BSD 라이센스를 명기하는 한 GPL을 추가하든 뭘 추가하든 상관 없지만
이렇게 하면 어떤 사람들은 '모양새가 좋지 않다. 라이센스가 덕지덕지
붙어있는게 뭐냐.. 그냥 GPL로 통일하자..' 이러더군요.. -_-;
logout wrote..
:
:
: 글틀이 wrote..
: : 전에 모 신문에서
: : 우리나라 오케스트라나 합창단 같은 경우 인쇄되지 않은..
: : 손을 베낀 악보를 사용하여 연습및 연주를 한다라는
: : 기사를 본 적이 있습니다.
: :
: : 왜 손으로 베낀 악보를 사용하느냐고 기자가 관계자에게
: : 물어보니 저작권때문에 그렇다는 것이읍니다.
: :
: : 저작권을 물어서 연주나 연습을 하려면 상당한 돈이 들지만
: :
: : 저작권을 가진 악보를 가져다가 손으로 베낀 다음
: : 한 두소절만 다르게 하면 저작권을 피해 갈 수 있기때문
: : 이라는 것입니다. 한두 소절정도야 아주 약간 틀리게 하면
: : 솔직히 전공자가 아닌 이상 잘 모르죠..
: :
: 잘은 모릅니다만 클래식 악보는 여러가지 종류가 있습니다.
: 베토벤이나 모짜르트가 쓴 원래 악보는 copyright가 아예 없죠.
: 누구나 쓸 수 있는 Public domain에 속합니다. 막말로
: 그때 악보 내용을 이렇게 팔아먹든 저렇게 팔아먹든 죽은지
: 수백년이 지난 베토벤이 뭘 하겠습니까? :)
:
: 이 경우 저작권에 해당하는 악보는 '오케스트라 용으로 편곡이
: 된' 악보입니다. 베토벤의 원전, 혹은 여러 종류의 필사본 중에서
: 괜찮은 걸 골라서 정리하고 악기별로 따로따로 만든거죠. 내용이
: 바뀌었는지는 잘 모르겠습니다만... 국내 오케스트라에서 필사를
: 하는 이유는 악보 프린팅 업자에게 돈을 주고 맡겨서 악보를
: 찍는 것이 명백해 카피라이트에 걸리니까 (공공장소에서의
: 상연에 쓰는 거니까 소송 걸기 딱 좋죠.) 한 카피를 사서
: 알아서 손으로 베끼는 거죠. 손으로 베끼든 TeX으로 조판하든
: 그건 별 문제가 아닐겁니다.
:
: : 위에서처럼
: : 하나의 저작권을 가진 소스를 구한 다음
: : 모든 내용을 새로이 타이핑 하면서 약간의 내용을 고친다
: : 라고 하면 새로이 타이핑한 소스는 타이핑한 사람이
: : 저작권을 주장할 수 있을까요?
: :
:
: GPL의 경우는 이때 새로이 타이핑한 소스는 공개되어야 하며
: (바이러스성 라이센스라고 그려죠. 이 특징때문에) 고친 부분은
: 고친 사람이 저작권을 갖고 원래 내용은 원래 내용을 쓴 사람이
: 저작권을 갖습니다. 상당히 합리적이에요... 소스 코드 공개의
: 원칙만 준수한다면요.
:
: : 그리고
: : GNU/LINUX 에서
: : 기존의 UNIX의 저작권을 피하기위해 모든 기반 프로그램들을
: : 새로이 작성하였다고 한다면 이때는 어느 정도선 까지..
: : 새로이 만들었까요?
:
: 예를들어 ls 명령어의 경우 ls -l 하면 자세한 파일 리스트가
: 나오죠? GNU fileutils의 경우 ls -l 하면 다른 유닉스 시스템과
: 똑같은 형식으로 출력이 되도록 재주껏 짠 겁니다. 시스템 콜도
: 마찬가지로 만들어졌구요. 규격대로 흉내내는겁니다. 그리고
: 소스코드 공개를 보장하기 위해서 GPL로 라이센스를 걸어버렸죠.
:
: 유닉스 진영의 재밌는 점은... 상용 유닉스도 소스코드가 공개된
: 경우가 많다는 점입니다. (오리지날 AT&T 유닉스가 대표적이죠.)
: 대신 소스코드를 마음대로 베껴 쓰지 못하는 문제가 있었죠. 뭐...
: 돈을 내면 가능했습니다만 돈 규모가 장난이 아니니까.
:
: 이런 까닭으로 라이센스 문제가 불거지기 전까지는 대충대충 패치해서
: 프로그램을 많이 썼었다고 합니다. AT&T나 기타 상용 유닉스 업체가
: 시비를 걸기 시작하니까 FreeBSD같이 새로 코드를 rewriting하는
: 움직임이 생겼습니다. Linux는 태생은 좀 다르지만, 라이센스를
: 피하는 것은 마찬가지죠.
:
: BSD나 MIT X 라이센스로 공개된 프로그램이 아니라면 아마
: 모두 새로 만들었을겁니다. 대표적인 케이스가 gcc, gdb와 같은
: 킬러 어플들이죠.
:
: BSD와 GPL의 호환성 문제(코드를 섞어 쓰면 어떻게되는지)는 잘
: 모르겠습니다. 아마도... incompatible 하지 않을까 싶은데
: 자신이 없네요.