GPL, 상용 프로그램, 그리고 젊은 놈의 넋두리 -_-;

상용화 하지 말라는 말을
GPL 어디에서도 발견을 못했는디

글고,,,세계를 리드하는 회사가
울나라에도 있다라고 말하는 후배들 보다.

공개된 소스를 바탕으로 나도 열씨미 하면 세계를 리드하는 회사를 창립할수 있다라고 하는 후배들이 앞으로 나올수 있는게 더 좋아 보이는것이 아닌감?

참고)리눅스 초보자의 개인적인
생각임,,,넘 오해마시길
글고,,,세계를 리드하는
기술력있는 회사를 만든
선배보다,
자기 기술을 공개하여
후배들도 세계적인 기술자로 만들어 주는 선배가 난
더 자랑스러븜

저도 직업 프로그래머라 많은 프로그램을 봐왔고 짜봤지만
몇개 또는 몇십개의 함수나 모듈들만의 아이디어만으로 훌륭한
프로그램이 되는 경우는 보지 못했읍니다.
게다가 사업성까지 갖춘다는건 제 상식으로는 힘들다고 보입니다.

위에 전제한 훌륭한 프로그램이나 획기적인 프로그램정도라면
시스템을 두루 잘아는 프로그래머가 시장을 정확히 판단하고
거기에 맞는 적절한 기능을 갖추고 있고 여러번의 시행 착오와
또는 여건이 된다면 많은 테스터들이 참여하여 신뢰성을 충분히
확보해야하고 덧붙여 전체 코드들이 조화를 이루고 있다면
혹시나 가능할까, 그래도 어느정도의 운도 따라줘야 제대로
사업이 되는 아이템이 될겁니다.

님이 하시고져하는 것이 무언지도 모르면서 초치는 얘기만
늘어논것 같은데 결론적으로 제가 지금까지 봐온 프로그램들
중 리눅스에서 GPL라이선스때문에 공개하기는 정말 아깝다는
생각이 들었던건 없었읍니다.
만약 님의 아이디어가 정말 획기적인거라면 저같으면 요즘같은
살벌하고 추잡한 사업 환경속에서 괜히 헤매기보다 확 공개해
버리고 유명인되고 나서 년봉 몇억에 쥐도새도 모르게 스카웃
당하는게 속편할것 같은데요....

꿈나무 wrote..
: 저는 임베디드 리눅스 개발에 관심이 많은 22살의 학생입니다(14살부
터
: 리눅스 사용). 지금 한창 공부 중에 있고, 아주 기가막힌(?) 아이디어
: 를 구현하여 상용화 하려는 계획이 있습니다. 앞서의 논의대로라면, 저
: 는 리눅스를 쓰면 어쩌면, 범법자가 되나요?
: 어디까지가 GPL을 따라야 하는 범위인지 궁금합니다. 누구나가 GPL을
말
: 하지만, GPL의 명확한 범위를 말하는 이는 없습니다.
:
: 예를 들어, 커널에 어떠한 기능을 수행하는 하나의 시스템 콜
(anycall)
: 을 다음과 추가하였다고 합시다.
:
: File entry.S
: ----------------
: ...
: .long SYMBOL_NAME(sys_fopen)
: .long SYMBOL_NAME(sys_anycall)
: ...
:
: File unistd.h
: ----------------
: ...
: NR_sys_fopen 170
: NR_sys_anycall 171
: ...
:
: File anycall.c
: ----------------
: ...
: asmlinkage int anycall()
: {
: ...
: ...
: }
: ...
:
: anycall 함수는 어떤 회사가 만든 최신 기술이 담긴 그들만의 밥줄이
걸
: 린 코드라고 가정합시다. 이 경우, anycall 소스의 바디까지 공개하여
: 야 하는가요? 아님 API만 공개하여야 하나요?.
: 이상적으로만 생각하지 마시고, 현실적으로 anycall 함수는 그 회사
의
: 고유의 기술이고 밥줄인데, 플래폼이 리눅스라는 이유만으로 함수 바디
: 를 공개하여야 하나요? 제발 "그러면, 리눅스를 떠나거나 FreeBSD를
쓰
: 거라~~ "하지 마세요.그 반대로 GPL의 정의를 정확히 내려주셔서
: "이부분은 이건데 이렇게 하면 GPL의 범위가 아니고, 이런건 GPL에 의
: 해 공개해햐 한단다."라는 말을 듣고 싶습니다.
: 앞서의 논의들은 어린 저에게 상당히 연구개발의지를 꺽는 상황으로밖
에
: 들리지 않습니다.
:
: 제 주변의 어떠한 사람도 GPL을 말하지만, 그것의 명확한 범위를 말하
진
: 않습니다. "GPL이면 무조건 소스를 공개하라." 라고 말하는 것은 정말
이
: 지 저같은 상황에서 허무하고 회의가 들 정도로 의지를 꺽는 일입니
다.
: modify의 개념이 소스를 한 줄이라도 건들이면, 그것을 공개하라 가
GPL
: 인가요?
:
: GPL 규정중에, "만약, 어떠한 저작물이 2차적 프로그램에 포함되어 있
: 는 부분과 동일한 것이라 하더라도 그것이 양도받은 프로그램으로부터
파
: 생된 것이 아니라 별도의 독립 저작물로 인정될 만한 상당한 이유가 있
을
: 경우,이 저작물의 개별적인 배포 과정에는 본 라이센스와 규정들이 적
용
: 되지 않는다."라고 말하고 있습니다.
:
: 그렇다면, anycall이 상당한 고유의 저작물로 인식이 된다면, GPL에
의
: 하여 공개를 하지 않아도 되지 않나여?
:
: 또한 커널의 소스 한줄도 건드리지 않고, adding만 한 경우
(anycall.c
: 를 만들어서 커널 소스 한줄도 안건드리고, 커널 소스트리에 추가하여
컴
: 파일 하는 경우, 이경우도 상당한 저작물임.)도 모든 소스코드를 공개
해
: 야 하나요?
:
: 정말이지 어디까지가 GPL 규정의 범위인지 혼란스럽습니다. 명확한 범
위
: 부탁드립니다.
:
: 제가 지금까지 말한 내용이 "눈가리고 아웅이다. ~ 건 사기다.~ 다 공
개
: 해라~."입니까?
:
: 그러면, 어떠한 방법으로 해야 하지요? 그럼 리눅스 커널을 건드려서
는
: 절대 상용화 제품이 나올수 없는 겁니까?
:
: 제발 현실과 이상의 조화를 가지고 이성적으로 누군가 답변해 주셨으
면 좋
: 겠습니다.
:
: 정말로 답답합니다. 어린 놈이 돈독이 올르셨다고 욕을 해도 좋습니
다.
:
: '리눅스 커널 기반의 상용 프로그램은 절대 불가'라면, 전 리눅스를 떠
나
: 겠습니다. 정말로 미련없이 떠나겠습니다.
:
: 전 리눅스를 사랑하였고, 리눅스를 이용하여 세계적으로 기술을
leading
: 할 수 있는 회사를 만들어 제 후배들이 대한민국을 한번쯤 자랑스럽게
여
: 기도록 하는게 제 꿈이었는데...
:
: 전 GPL을 사랑했지만, GPL이 저를 버렸군요.
:
: 그럼 전 linux community를 떠나겠습니다.
:
: 안녕히 계세요.

위의 두분이 라이센스 문제를 말씀하셨지만 어쨌던 사업 아이디어를 말씀
하셨으니 사업성이 걱정되는 군요.

말씀하신 내용을 보니
1. 고객이 커널을 재컴파일하거나
2. 독자적인 배포판을 만들어야 할 것 같군요.

2의 경우라면 _엄청나게 기가막힌_ 것이 아니면 붐비는 배포판 시장에 뛰
어들어도 이익이 남지 않을 것 같습니다(그런데 현재 배포판으로 이익을
남기는 곳이 있나요?).

1의 경우에는
a. 소스를 넘겨주거나
b. 바이너리 모듈 파일(이렇게 부르는 것이 맞나요?)을 배포해야 할 것
같은데,

a의 경우 기대보다 매출이 적겠죠?
b의 경우 고객이 사용중인 커널 버전에 따라 사용자 지원 문제가 골치
아파 매출도 순익도 별로 나질 않을 것 같군요.

님의 아이디어 내용을 모르니 뭐라 확실히 말할 수 없지만
_엄청나게 기가 막한_ 아이디어라면 GNOME이 생겼던 것과 마찬가지로 비슷
한 기능을 제공하는 GPL 소스가 생겨나지 않을까요?
이 가상의 경쟁자를 누르며면 확실한 수준차가 나던지(그래도 시간이 지남
에 따라 수준차가 줄지 않을까요), 님의 코드를 사용하는 '동맹자'들이 대
거 출현하던지, 아니면 특허를 내야겠지요. 앞의 둘은 쉬운 일이 아니고
마지막 방법은 불에 화약통을 던져 넣은 것 이상으로 격렬한 반발이 일어
나겠죠. 시장에 성공적으로 진입하면 진입할 수록 법률 비용이 증가할 수
도 있을 겁니다. 미국 법원에서 소송이 걸리기라도 하면 ... 미국 재판은
승패와 관계없이 한 쪽이 끈덕지면 소송비용이 마구 늘어나는 특성이 있지
요.

그 정도로 _기가 막힌_ 아이디어가 아니라면 시장이 좁을 터이구요. 그 경
우에는 consulting firm의 형태를 띠게 될 터인데 우리나라에서 시장 규모
가 얼마나 될지... 세계를 무대로 한다면 필요한 working capital은 마구
늘어날 터인데 ...

이야기하다보니 비관적으로만 이야기했군요.

음 의도는 기술의 내용에 알맞는 사업 모델을 찾는 것이 무척 어렵다는 점
을 강조하려는 것이었습니다. 어쨌던 라이센스 문제를 고민하시는 모습이
일단 보기 좋네요.

부디 뜻하신 바를 이루셔서 리눅스 커뮤니티에 'giving back'하시는 날이
빨리 오기를 기대하겠습니다.

꿈나무 wrote..
[...]
:
: anycall 함수는 어떤 회사가 만든 최신 기술이 담긴 그들만의 밥줄이 걸
: 린 코드라고 가정합시다. 이 경우, anycall 소스의 바디까지 공개하여
: 야 하는가요? 아님 API만 공개하여야 하나요?.
: 이상적으로만 생각하지 마시고, 현실적으로 anycall 함수는 그 회사의
: 고유의 기술이고 밥줄인데, 플래폼이 리눅스라는 이유만으로 함수 바디
: 를 공개하여야 하나요? 제발 "그러면, 리눅스를 떠나거나 FreeBSD를 쓰
: 거라~~ "하지 마세요.그 반대로 GPL의 정의를 정확히 내려주셔서
: "이부분은 이건데 이렇게 하면 GPL의 범위가 아니고, 이런건 GPL에 의
: 해 공개해햐 한단다."라는 말을 듣고 싶습니다.
: 앞서의 논의들은 어린 저에게 상당히 연구개발의지를 꺽는 상황으로밖에
: 들리지 않습니다.

공개해야 합니다. `한 줄 추가하고 다른 파일에 만들었는데
무슨 상관이냐'라고 할 사람도 있겠지만.. 그걸 인정한다면
GPL 피해가기는 식은죽먹기잖아요?

한 가지 방법은 system call로 만들지 말고, character
device로 만들어서 kernel module을 만들어 이용하는
겁니다 (그게 불가능할 정도로 커널과 밀접하다면 어쩔 수
없지만.. anycall.c로 분리할 수 있을 정도면 가능할 것
같군요.)

RMS의 경우는 링크(static&shared 모두)한 경우
derived works라고 보고 있는데.. kernel module의
경우도 커널과 같은 address space니까 link로
볼 수 있지만, Torvalds등은 그건 인정하는 모양이더군요.
덕분에 OSS같은 드라이버도 있고...

: GPL 규정중에, "만약, 어떠한 저작물이 2차적 프로그램에 포함되어 있
: 는 부분과 동일한 것이라 하더라도 그것이 양도받은 프로그램으로부터 파
: 생된 것이 아니라 별도의 독립 저작물로 인정될 만한 상당한 이유가 있을
: 경우,이 저작물의 개별적인 배포 과정에는 본 라이센스와 규정들이 적용
: 되지 않는다."라고 말하고 있습니다.
:
: 그렇다면, anycall이 상당한 고유의 저작물로 인식이 된다면, GPL에 의
: 하여 공개를 하지 않아도 되지 않나여?
:
: 또한 커널의 소스 한줄도 건드리지 않고, adding만 한 경우(anycall.c
: 를 만들어서 커널 소스 한줄도 안건드리고, 커널 소스트리에 추가하여 컴
: 파일 하는 경우, 이경우도 상당한 저작물임.)도 모든 소스코드를 공개해
: 야 하나요?

"reasonably considered independent and
separate..."라고 애매하게 되어 있는데, 어쨌거나
독립적인 작업이며 `별도로 배포된 경우(when you
distribute them as separate works)'에만
가능하므로 커널 소스트리에 추가된 형태는 GPL에 들어갑니다.