글쎄요. 기사를 보면 오픈 오피스를 gcj로 컴파일 할 때 문제가 생기는 부분을 지적하고 있는 것 같은데 아무래도 이번 경우 역시 RMS가 조금 지나치지 않나 싶습니다. 같은 논리라면 맥 오에스텐용 오픈 소스 프로젝트도 장려하지 않는 것이 맞습니다. (개인적으로 왜 RMS가 이 부분은 건드리지 않는지 궁금합니다.) 맥용 데스크탑 어플은 맥 오에스텐이 유닉스인데도 불구하고 리눅스나 다른 유닉스 계열 운영체제로 포팅이 기본적으로 불가능하니까요.
이 문제는 전체적으로 오픈오피스 개발자들의 의견을 존중하는 것이 좋다고 봅니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
RMS 때문에 소프트웨어 개발자들이 자바라는 또다른 가능성을 폄하하고 무시하는것 같아서 좀 서운한 감도 듭니다.
서로가 사이가 안좋은 것은, 고슬링이 자신소유의 지적재산(자바 JAVA 등등)으로 돈을 버는데 스톨만씨가 방해가 된다고 생각하기 때문이 아닐까요 ?
제임스 고슬링은 IT업계에서 세계적인 독점적 권력을 행사하는 Microsoft의 빌게이츠에 대해서는 비겁한 폄하와
직접적인 공격을 가하면서도, 정작 자신은 JAVA에 대해서 개발환경뿐만아니라 OS 및 하드웨어분야(Net PC 혹은 JAVA Machine) 등의 IT의 거의 모든 영역에서 독점적인 위치를 차지하기를 간절히 바라고 있죠. 내심은 정작 빌게이츠처럼 되기를 바면서도 그에 대한 질투랄까.
내심(內心)에 도사리고 있는 kewword는 "돈(Big Money)"과 "명예욕"이겠지요.
( 결국 길고 짧아보아야 똑같은 인간들인데 :lol: )
Java는 Sun의 지적재산입니다.
제임스 고슬링꺼는 아닌데요.. 그리고 스톨만과의 유명한 불화는 "지적재산으로 돈을 벌수 있다"를 인정하느냐 않하느냐의 차이로 발생한거조. Emac때도 그랬고요. 스톨만같은 "모든 정보를 공개하고 공유하자"라는 사람은 누구하고도 싸움이 일어납니다. 뭐 해커들이야 스톨만을 지지하지만, 먹고 사는 일이 걸리는 대부분의 프로그래머들에게는 별로 받아들이기 어려운 일이기도 합니다. (심정적으로야 저도 지지합니다만...)
아무튼 그것때문에 스톨만이 고슬링을 비난하는데 사람들이 이걸 일방적으로 받아들이는 것도 문제입니다.
그리고 자바는 이미 오픈소스입니다만...
Community License로 소스코드를 받아 볼수 있고, Class 소스는 아예 JDK에 포함되어 나옵니다. 꽤나 오래전부터 그랬죠.
Java Virtual Machine 스펙이나 Java Language Spec이나 모두 공개되어 있고요.
Java는 Sun의 지적재산입니다.
제임스 고슬링꺼는 아닌데요.. 그리고 스톨만과의 유명한 불화는 "지적재산으로 돈을 벌수 있다"를 인정하느냐 않하느냐의 차이로 발생한거조. Emac때도 그랬고요. 스톨만같은 "모든 정보를 공개하고 공유하자"라는 사람은 누구하고도 싸움이 일어납니다. 뭐 해커들이야 스톨만을 지지하지만, 먹고 사는 일이 걸리는 대부분의 프로그래머들에게는 별로 받아들이기 어려운 일이기도 합니다. (심정적으로야 저도 지지합니다만...)
아무튼 그것때문에 스톨만이 고슬링을 비난하는데 사람들이 이걸 일방적으로 받아들이는 것도 문제입니다.
그리고 자바는 이미 오픈소스입니다만...
Community License로 소스코드를 받아 볼수 있고, Class 소스는 아예 JDK에 포함되어 나옵니다. 꽤나 오래전부터 그랬죠.
Java Virtual Machine 스펙이나 Java Language Spec이나 모두 공개되어 있고요.
오픈되어있는 것은 맞습니다만 그걸 가지고는 아무것도 못하도록 되어있습니다.
소스를 볼 수만 있을 뿐 소스를 수정한다거나 혹은 다른 프로그램을 개발하는데
이용한다거나 하는 것은 불가능하도록 되어있습니다.
예를 들어 java 에 들어있는 gc 구현을 보고 다른 언어(python 같은)
의 gc 알고리즘(혹은 구현)을 그렇게 수정하는 것은 라이센스 위반이 됩니다.
저도 정확히 아는 것은 아니기 때문에 제가 쓴 내용이 틀렸을 수도 있습니다.
Java는 Sun의 지적재산입니다.
제임스 고슬링꺼는 아닌데요..
.....
그리고 자바는 이미 오픈소스입니다만...
Community License로 소스코드를 받아 볼수 있고,
Class 소스는 아예 JDK에 포함되어 나옵니다. 꽤나 오래전부터 그랬죠.
Java Virtual Machine 스펙이나 Java Language Spec이나 모두 공개되어 있고요.
Sun의 대주주 및 CEO는 고슬링이기 때문에, Sun은 결국 고슬링꺼고, 결국 자바는 고슬링꺼지요! (고슬링이 SUN의 주식을 전부 다른사람에게 매각하지 않는 한, JAVA는 고슬링 소유의 재산입니다.주식회사에 대해서 공부해 보시길...)
맞습니다. JAVA가 Open Source(오픈소스)이고, GNU Free Software(프리소프트웨어) 라이센스가 아니기 때문에, 소스에 대한 어떠한 자유(Freedom)가 없으며, 아랫분의 말씀대로, 그것을 가지고 어떤 일도 할 수가 없습니다.
Anonymous wrote:
오픈되어있는 것은 맞습니다만 그걸 가지고는 아무것도 못하도록 되어있습니다.
소스를 볼 수만 있을 뿐 소스를 수정한다거나 혹은 다른 프로그램을 개발하는데
이용한다거나 하는 것은 불가능하도록 되어있습니다.
예를 들어 java 에 들어있는 gc 구현을 보고 다른 언어(python 같은)
의 gc 알고리즘(혹은 구현)을 그렇게 수정하는 것은 라이센스 위반이 됩니다.
저도 정확히 아는 것은 아니기 때문에 제가 쓴 내용이 틀렸을 수도 있습니다.
JAVA는 오픈소스에 불과하기 때문에, 그 Source Code로 어떤 것도 할 수가 없으며 따라서 "빛 좋은 게살구"에 불과하며, 자신들의 이익을 위하여 공동체를 이용하는 꼴이 되고 있어서, 결국 그것은 "손바닥으로 하늘을 가리는 격"이 되어, 공동체로부터 전폭적인 지지를 받지 못하고 있고, 그 귀결로서 고슬링이 예상한 것 보다 독점적 시장점유율을 차지하지는 못하고 있습니다.
두번째 손님이 지적하신 부분, "고슬링이 자신소유의 지적재산(자바 JAVA 등등)으로 돈을 버는데 스톨만씨가 방해가 된다고 생각하기 때문이 아닐까요 ?" 는 약간 틀립니다.
결과적으로 자바로 가장 많은 돈을 버는 업체는 Sun이 아니라 IBM입니다. IBM이 없었다면 자바는 Sun 내부 프로젝트로 종말을 고했을겁니다.
썬 홈페이지의 J2EE는 무료 배포되지만 상업용으로 사용하지 못하도록 묶여있습니다. J2EE를 상업적으로 올리려면 웹스피어, 웹로직, 썬 자바시스템 등 J2EE를 구현한 상용제품을 이용해야만 합니다. 업계에서는 웹스피어, 웹로직을 많이 사용하니 썬이 버는 돈은 별로 없지요.
그러므로 다른 손님의 "Sun의 대주주 및 CEO는 고슬링이기 때문에, Sun은 결국 고슬링꺼고, 결국 자바는 고슬링꺼지요"라는 말도 맞다고 보기는 어렵습니다. 언급하신대로 주식회사 식으로 따지자면, 제임스 고슬링이 썬에 가지고 있는 지분율만큼 자바에 대한 권리를 가진다고 볼 수 있지요. 고슬링이 얼마만큼의 지분을 가지고 있는지는 모르겠지만 50%는 안넘으니 자바에 대한 고슬링의 재산권은 50% 미만이라 볼 수 있겠네요. 50% 미만 소유하고 있는게 독점적이라 할 수 있는건지 의문입니다만.. (그러므로 주식회사식 논거는 틀렸습니다.)
자바 스펙을 결정하는 JCP에서 입김이 가장 센건 썬이 아니라 IBM입니다. IBM에서 제안한 내역의 대부분이 J2EE에 들어갔습니다. 자바라는 상표와 껍데기만 썬 것이지요.
Java라는 이름과 껍데기를 소유한 죄로 소송은 썬이 다 합니다만 실 이익은 IBM이 모조리 챙겨가고 있죠. 소송 같은 귀찮고 복잡한건 모두 썬으로 떠넘긴 IBM이 대단하죠.
"소스를 볼 수만 있을뿐 수정할 수 없다"는 부분은 JVM 스펙과 구현체는 다르다라는 관점에서 이해하셔야 할것입니다.
스펙은 공개되어 있으므로 누구나 스펙에 맞춰 제작할 수 있습니다. gcj도 이 스펙을 참조해서 개발합니다.
구현체는 스펙과 다릅니다. 스펙이 스펙으로 끝나지 않도록 코딩한 작업물이지요. JMS는 이 구현체까지도 오픈소스로 풀기를 바라는 모양입니다만.. 그렇게 된다면 Sun java뿐만 아니라 IBM, apple 등 다른 업체도 다 공개해야겠지요. 이쯤 하면 썬만 잡아 족칠 문제는 아닙니다.
자바는 리눅스 공동체로부터 전폭적 지지는 못받을지 몰라도
기업 비지니스 환경에서는 전폭적 지지를 받고 있으며 상당한 독점적 영향을 행사하고 있습니다.
자바가 썬이라는 든든한 백이 있기때문에 아이비엠과 다른 회사에서도 전폭적으로 지지를 할 수 있다고 봅니다.
만약 자바가 그냥 단순이 오픈소스였다면 지금 이정도로 엄청난 발전은 없었을 것입니다.
썬은 자바로 여러가지 이득도 보지만. 윗분 말씀하신대로 아이비엠등의 회사에 비하면 이름만 갖고 있는 것으로 볼 수 있죠.
주제로 돌아와서
제임스 고슬링은 자바를 만든 장본인이지만. CEO는 스캇 맥닐리가 맞죠. 고슬링이 회사에 얼마나 중요한 인물인지는 모르겠습니다. 아직은 필요한 사람이니까 붙어있는것이겠죠. 요즘엔 더 심해진게 사실이지만. 회사들은 살아남기 바쁘기 때문에 필요한 사람은 남아있지만. 필요없으면 바로 떨어져 나가게 됩니다.
지금은 그나마 썬이 자바 관리를 잘 해서 붙들고 있지만. 관리 못하면 다른 곳에 뺏길수도 있죠. 아이비엠 같은곳으로여..
아무튼 제가 알기론 제임스 고슬링이 그렇게 힘이 많다고 생각지는 않습니다.
리차드 스톨만은 참 신기한 사람인거 같은데 그사람 주장대로 모든 소스를 공개하고 그러면 먹구살 사람이 몇이나 있을까요?
개인적인 생각으론 스톨만씨의 GPL보다는 썬의 라이센스가 더 맘에 듭니다. (둘만 비교했을때여)
세상이너무 이익위주로 돌아가는 거 같아서 참 안타깝습니다. 스톨만 생각이 맞는지 썬 생각이 맞는지 정말 모르겠는데여. 아이비엠이 돈 버는건 확실한거 같습니다. ^^
두번째 손님이 지적하신 부분, "고슬링이 자신소유의 지적재산(자바 JAVA 등등)으로 돈을 버는데 스톨만씨가 방해가 된다고 생각하기 때문이 아닐까요 ?" 는 약간 틀립니다.
결과적으로 자바로 가장 많은 돈을 버는 업체는 Sun이 아니라 IBM입니다. IBM이 없었다면 자바는 Sun 내부 프로젝트로 종말을 고했을겁니다.
썬 홈페이지의 J2EE는 무료 배포되지만 상업용으로 사용하지 못하도록 묶여있습니다. J2EE를 상업적으로 올리려면 웹스피어, 웹로직, 썬 자바시스템 등 J2EE를 구현한 상용제품을 이용해야만 합니다. 업계에서는 웹스피어, 웹로직을 많이 사용하니 썬이 버는 돈은 별로 없지요.
그러므로 다른 손님의 "Sun의 대주주 및 CEO는 고슬링이기 때문에, Sun은 결국 고슬링꺼고, 결국 자바는 고슬링꺼지요"라는 말도 맞다고 보기는 어렵습니다. 언급하신대로 주식회사 식으로 따지자면, 제임스 고슬링이 썬에 가지고 있는 지분율만큼 자바에 대한 권리를 가진다고 볼 수 있지요. 고슬링이 얼마만큼의 지분을 가지고 있는지는 모르겠지만 50%는 안넘으니 자바에 대한 고슬링의 재산권은 50% 미만이라 볼 수 있겠네요. 50% 미만 소유하고 있는게 독점적이라 할 수 있는건지 의문입니다만.. (그러므로 주식회사식 논거는 틀렸습니다.)
자바 스펙을 결정하는 JCP에서 입김이 가장 센건 썬이 아니라 IBM입니다. IBM에서 제안한 내역의 대부분이 J2EE에 들어갔습니다. 자바라는 상표와 껍데기만 썬 것이지요.
Java라는 이름과 껍데기를 소유한 죄로 소송은 썬이 다 합니다만 실 이익은 IBM이 모조리 챙겨가고 있죠. 소송 같은 귀찮고 복잡한건 모두 썬으로 떠넘긴 IBM이 대단하죠.
"소스를 볼 수만 있을뿐 수정할 수 없다"는 부분은 JVM 스펙과 구현체는 다르다라는 관점에서 이해하셔야 할것입니다.
스펙은 공개되어 있으므로 누구나 스펙에 맞춰 제작할 수 있습니다. gcj도 이 스펙을 참조해서 개발합니다.
구현체는 스펙과 다릅니다. 스펙이 스펙으로 끝나지 않도록 코딩한 작업물이지요. JMS는 이 구현체까지도 오픈소스로 풀기를 바라는 모양입니다만.. 그렇게 된다면 Sun java뿐만 아니라 IBM, apple 등 다른 업체도 다 공개해야겠지요. 이쯤 하면 썬만 잡아 족칠 문제는 아닙니다.
자바는 리눅스 공동체로부터 전폭적 지지는 못받을지 몰라도
기업 비지니스 환경에서는 전폭적 지지를 받고 있으며 상당한 독점적 영향을 행사하고 있습니다.
잘 읽었습니다... 그리고 저도 같은 생각입니다....
흔히들 자바때문에 썬이 공격받기는 하지만 실상은 변변한 떡고물
조차 먹지 못하고 있죠....
정작 자바로 돈 번 곳은 아범, bea, 오라클이라고 볼 수있습니다...
(그런데 아범의 경우 또다른 관점에서 보면 돈을 벌만한 자격을
갖추고 있습니다. 과장해서 말하자면 이 자바때문에 아범이 일어
설 수있다고 봐도 되거든요.. )
글쎄요... 요즘 썬은 자바를 빼놓고 나면 거의 시체(?)나 다름없지
않나요? 썬이 서버로 장사하던 얘기는 이미 오래전 스토리로
알고 있습니다.
Quote:
자바가 썬이라는 든든한 백이 있기때문에 아이비엠과 다른 회사에서도 전폭적으로 지지를 할 수 있다고 봅니다.
만약 자바가 그냥 단순이 오픈소스였다면 지금 이정도로 엄청난 발전은 없었을 것입니다.
글쎄요. 오히려 썬이 자바를 말아먹은 자충수를 기억해본다면 아이비엠과
같은 회사들이 썬이라는 빽을 보고 자바를 지원하지는 않았을 것이라는
추측을 해 볼 수 있습니다.
단적인 예가 자바 애플릿입니다. 썬은 자바가 초반에 웹브라우저 내의
애플릿으로 각광받고 있을때 썬의 JVM 소스 코드 및 수정, 재배포 권한
까지 MS에 팔았습니다. 그 결과는 MS가 인터넷 익스플로러 내부의
JVM의 스펙을 썬이 아닌 MS가 결정할 수 있게 해 주었고 결과적으로
MS가 인터넷 익스플로러의 배포권을 이용해서 자바의 발전을 견제할
수 있게 해 주었습니다. 그 부작용의 하나가 다들 잘 아시다시피
액티브 엑스의 출현입니다. 뒤늦게 자신의 자충수를 깨달은 썬이
엠에스를 제소했지만 뭐... MS에서는 JVM을 완전히 윈도우즈에서
제거시키는 방법으로 응수해버렸습니다.
그나마 자바가 서버 쪽에서 살아남은 것은 썬이 잘해서가 아니라
오픈 소스 개발자들이 달라붙어 자바로 서버 사이드 솔루션들을 계속
만들어 왔기 때문입니다.
Quote:
지금은 그나마 썬이 자바 관리를 잘 해서 붙들고 있지만. 관리 못하면 다른 곳에 뺏길수도 있죠. 아이비엠 같은곳으로여..
오히려 아이비엠 같은 곳에서 자바의 미래를 전담해 주는 것이 자바의
미래를 위해서는 나은 결정이 될겁니다. :)
Quote:
리차드 스톨만은 참 신기한 사람인거 같은데 그사람 주장대로 모든 소스를 공개하고 그러면 먹구살 사람이 몇이나 있을까요?
개인적인 생각으론 스톨만씨의 GPL보다는 썬의 라이센스가 더 맘에 듭니다. (둘만 비교했을때여)
구체적으로 어떤 얘기인지는 좀 더 들어봐야하겠습니다만 RMS만큼 사람들이
잘못 이해하고 있는 경우도 드문 것 같습니다. GPL은 이윤동기를 부정하는
것이 아닙니다. GPL이 확실히 보장해 주는 것은 다른 개발자들이 소스코드를
자유롭게 볼 수 있는 권한을 부여해 주는 것입니다.
RMS가 유별난 점은 RMS는 장기적으로 모든 소프트웨어의 소스 코드는
공개되어야 한다고 주장하는 점입니다. 그의 주장에도 일리가 있는 것이
현재는 소스 코드가 비공개인 상용 라이센스와 소스 코드 공개가 의무인
GPL 양 자 사이에서 개발자들이 필요에 따라서 선택을 할 수 있지만
만약 GPL만이 사용할 수 있는 유일한 라이센스라고 한다면 모든
derivative work의 소스코드가 공개될 것이기 때문이 내 소스 코드를
공개하는 것이 소스 코드 뒤에 숨어 있는 나의 아이디어의 도용으로
이어지지 않습니다. 하지만 현실에서 소스코드의 공개는 강제할 수 있지만
아이디어을 베낀 뒤 새로운 제품을 만들고 이것을 closed source로 해서
derivative idea의 노출을 막는 것은 항상 가능하지요. 또 이를 뒷받침
해 줄 수 있는 것이 상용 라이센스이구요.
이렇다면 RMS의 말대로 모든 소프트웨어가 GPL을 따르는 것이
좋은 일이 될 수 있는 겁니다. 비록 현실적으로 실현 과정이 불가능에
가깝지만 이런 상황을 한번 가정을 해 보는 것 만으로도 상당한
의의가 있다고 봅니다. 어쨌거나, 중요한 점은 RMS가 유별나기는
하지만 GPL은 절대 이윤동기를 부정하지 않습니다. 오히려 GPL은
이윤동기를 장려하는 입장입니다.
Quote:
세상이너무 이익위주로 돌아가는 거 같아서 참 안타깝습니다. 스톨만 생각이 맞는지 썬 생각이 맞는지 정말 모르겠는데여. 아이비엠이 돈 버는건 확실한거 같습니다. ^^
현재 상황으로는 IBM이 돈을 더 많이 벌어서 자바를 썬의 영향력 아래에서
뺏어올 필요가 있지 않나 싶습니다. 하지만 요즘 IBM도 실적이 그다지
좋지는 못하더군요.
썬의 자바를보면서 개인적으로 아쉬운 점은 자바는 충분히 차세대 개발플랫폼을
MS의 윈도우즈가 아닌 한 단계 차원 높은 새로운 플랫폼으로
옮겨올 수 있는 잠재력이 충분했었습니다만 결과적으로 이 부분에서
실패를 한 셈입니다. 자바의 경쟁자로 이름이 자자하던 닷넷 플랫폼은
아직까지 많이 쓰이려면 시간이 한참 더 걸려야 하는 상황입니다.
어차피 윈도우즈 차세대 버전 롱혼이 나오면 자바가 번들될 수 없는
상황이 벌어질 것은 당연한데 여전히 자바에 대한 제어권에 집착하는
썬의 모습은 갑갑한 부분이 많이 있습니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
RMS가 유별난 점은 RMS는 장기적으로 모든 소프트웨어의 소스 코드는
공개되어야 한다고 주장하는 점입니다. 그의 주장에도 일리가 있는 것이
현재는 소스 코드가 비공개인 상용 라이센스와 소스 코드 공개가 의무인
GPL 양 자 사이에서 개발자들이 필요에 따라서 선택을 할 수 있지만
만약 GPL만이 사용할 수 있는 유일한 라이센스라고 한다면 모든
derivative work의 소스코드가 공개될 것이기 때문이 내 소스 코드를
공개하는 것이 소스 코드 뒤에 숨어 있는 나의 아이디어의 도용으로
이어지지 않습니다. 하지만 현실에서 소스코드의 공개는 강제할 수 있지만
아이디어을 베낀 뒤 새로운 제품을 만들고 이것을 closed source로 해서
derivative idea의 노출을 막는 것은 항상 가능하지요. 또 이를 뒷받침
해 줄 수 있는 것이 상용 라이센스이구요.
이렇다면 RMS의 말대로 모든 소프트웨어가 GPL을 따르는 것이
좋은 일이 될 수 있는 겁니다. 비록 현실적으로 실현 과정이 불가능에
가깝지만 이런 상황을 한번 가정을 해 보는 것 만으로도 상당한
의의가 있다고 봅니다. 어쨌거나, 중요한 점은 RMS가 유별나기는
하지만 GPL은 절대 이윤동기를 부정하지 않습니다. 오히려 GPL은
이윤동기를 장려하는 입장입니다.
이론상으로는 그런데...현실적으로 국내에 GPL 소프트웨어 만들어서 먹고 사는 소프트웨어 업체가 한군데라도 있나요? 왜 현실적으로 GPL의 이윤동기가 전혀 작동이 안되는지 살펴볼 필요가 있을 것 같습니다. 이상에 치우친 이론은 공허할 뿐이죠.
RMS가 유별난 점은 RMS는 장기적으로 모든 소프트웨어의 소스 코드는
공개되어야 한다고 주장하는 점입니다. 그의 주장에도 일리가 있는 것이
현재는 소스 코드가 비공개인 상용 라이센스와 소스 코드 공개가 의무인
GPL 양 자 사이에서 개발자들이 필요에 따라서 선택을 할 수 있지만
만약 GPL만이 사용할 수 있는 유일한 라이센스라고 한다면 모든
derivative work의 소스코드가 공개될 것이기 때문이 내 소스 코드를
공개하는 것이 소스 코드 뒤에 숨어 있는 나의 아이디어의 도용으로
이어지지 않습니다. 하지만 현실에서 소스코드의 공개는 강제할 수 있지만
아이디어을 베낀 뒤 새로운 제품을 만들고 이것을 closed source로 해서
derivative idea의 노출을 막는 것은 항상 가능하지요. 또 이를 뒷받침
해 줄 수 있는 것이 상용 라이센스이구요.
이렇다면 RMS의 말대로 모든 소프트웨어가 GPL을 따르는 것이
좋은 일이 될 수 있는 겁니다. 비록 현실적으로 실현 과정이 불가능에
가깝지만 이런 상황을 한번 가정을 해 보는 것 만으로도 상당한
의의가 있다고 봅니다. 어쨌거나, 중요한 점은 RMS가 유별나기는
하지만 GPL은 절대 이윤동기를 부정하지 않습니다. 오히려 GPL은
이윤동기를 장려하는 입장입니다.
이론상으로는 그런데...현실적으로 국내에 GPL 소프트웨어 만들어서 먹고 사는 소프트웨어 업체가 한군데라도 있나요? 왜 현실적으로 GPL의 이윤동기가 전혀 작동이 안되는지 살펴볼 필요가 있을 것 같습니다. 이상에 치우친 이론은 공허할 뿐이죠.
아 정말... 글을 써 놨으면 좀 읽어보고 댓글을 달아 주세요. RMS말대로
따라가자는 게 아니고 RMS의 허황되어 보이는 얘기에도 일고의 가치가 있다는
글을 잔뜩 적어 놓았는데 대뜸 GPL로 먹고 사는 업체가 하나라도 있냐는
동답서문이 올라오면 뭐하자는 겁니까...
국내 업체들이 오픈소스로 먹고 사는 곳이 없다고들 하는데 거꾸로
국내의 다른 상용 개발업체들의 이윤 사정은 어떤지 궁금합니다. 우리나라
업체들이야말로 순수 소프트웨어 개발 자체로는 생존 자체가 어렵지
않나요? 상용 소프트웨어 업체 사정이 이러할진대 GPL로 먹고 사는
국내 업체가 없다는 핑계로 GPL까지 평가절하 하는 것은 성급하죠.
적어도 외국으로만 눈을 돌려 봐도 레드햇과 같은 업체는 이미
GPL을 꾸준히 지키면서도 돈을 벌고 있고 배포본 시장에서만
suse니 mandrake니 여러 업체가 자리를 잡고 있지 않나요?
GPL이외에 선택할 수 있는 다른 상용 라이센스가 있다는 점은 기업들이
경쟁자들에게 이익이 될 수 있는 기술 공개를 꺼려하게 만듭니다. 기술에서
중요한 것은 아이디어이지 소스코드가 아니거든요. 현재는 경쟁사들이
오픈소스 개발사의 소스코드를 보고 아이디어를 습득한 다음 소스코드를
공개하지 않은 채로 더 나은 제품을 개발해서 팔 수 있습니다. 이렇게
되면 원 개발사는 경쟁사의 제품에 어떤 개선된 기술이 구현되었는지를
알 수 없게 되고 따라서 처음부터 기술 공개를 안하는 편이 합리적입니다.
문제는, GPL로 소스 코드 공개를 강제해도 이 부분은 막을 방법이 없습니다.
다만, 라이센스가 GPL만 존재하는 세상이 있다고 가정하면 경쟁사의
기술이 녹아 있는 소스 코드도 항상 공개 되기 때문에 경쟁사의 무임승차
문제가 해결이 될 수도 있다는 것입니다. 덧붙이자면 따라서 기업들이
내부 기술 노출의 위험 때문에 GPL 도입을 꺼리는 것은 사실상 GPL 자체의
문제보다는 GPL과 다른 라이센스가 동시에 존재하기 때문이라고 볼
수 있는 것이지요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
국내 업체들이 오픈소스로 먹고 사는 곳이 없다고들 하는데 거꾸로
국내의 다른 상용 개발업체들의 이윤 사정은 어떤지 궁금합니다. 우리나라
업체들이야말로 순수 소프트웨어 개발 자체로는 생존 자체가 어렵지
않나요? 상용 소프트웨어 업체 사정이 이러할진대 GPL로 먹고 사는
국내 업체가 없다는 핑계로 GPL까지 평가절하 하는 것은 성급하죠.
적어도 외국으로만 눈을 돌려 봐도 레드햇과 같은 업체는 이미
GPL을 꾸준히 지키면서도 돈을 벌고 있고 배포본 시장에서만
suse니 mandrake니 여러 업체가 자리를 잡고 있지 않나요?
국내 소프트웨어 시장은 패키지쪽은 불법복사때문에 전부 망했지만 아웃소싱쪽은 그냥그냥 먹고살만 합니다. 대신 소스 공개했다간 다음날로 쫄딱 망하거든요. GPL은 남의 나라 얘깁니다.
근데 그런 상황을 잘 모르시는 걸 보니 logout님은 한번도 회사에서 근무해본 적이 없으신 것 같네요. 맞죠? 저도 대학생때는 왜 GPL이 안되는지 의아했는데 회사 생활해보니까 당장 알겠더군요. 학교에만 계시지 말고 회사 생활도 해보시면서 견문을 넓히시길~
풋...아웃소싱 쪽이 Product 로 밥 벌어먹는 동네였던가요..
Product 를 만들어 내기 위해서 아웃소싱을 하더라도(과연..)
Product 가 아닌 다른 쪽으로 밥 벌어먹고 사는 동네죠.
그리고,
GPL 이 국내에서 안 먹히는 이유가 뭔지는 아십니까?
꼭 국내에서는 GPL 이 안 통하는 이유라도 있는것처럼 써 놓으셨지만,
GPL 이 국내에서 안 통하는 이유는 라이센스를 어기는 회사들 때문입니다.
GPL 로 공개된 프로그램 소스 코드 가져다 derived work 를 만들어 놓고는
마치 GPL 로 공개된 소스 가져다 쓰지 않은양 위장하고 상용 라이센스로
제품을 만들어서 팔아 먹으려는 막말로 말하자면 '막되먹은' 회사들 때문이라는 겁니다.
풋...아웃소싱 쪽이 Product 로 밥 벌어먹는 동네였던가요..
Product 를 만들어 내기 위해서 아웃소싱을 하더라도(과연..)
Product 가 아닌 다른 쪽으로 밥 벌어먹고 사는 동네죠.
그리고,
GPL 이 국내에서 안 먹히는 이유가 뭔지는 아십니까?
꼭 국내에서는 GPL 이 안 통하는 이유라도 있는것처럼 써 놓으셨지만,
GPL 이 국내에서 안 통하는 이유는 라이센스를 어기는 회사들 때문입니다.
GPL 로 공개된 프로그램 소스 코드 가져다 derived work 를 만들어 놓고는
마치 GPL 로 공개된 소스 가져다 쓰지 않은양 위장하고 상용 라이센스로
제품을 만들어서 팔아 먹으려는 막말로 말하자면 '막되먹은' 회사들 때문이라는 겁니다.
좀 현실적이 돼 봅시다. 까놓고 얘기해서 지금 GPL 위반해서 먹고사는 회사 부지기수로 많은데 아무도 제재하지 못하는 건 왜 그런가요? GPL은 국내에서는 아무 구속력이 없어요.
이거 아주 이상한 상황이지 않나요. GPL 단물 뽑아먹어서 잘될리가 있냐고 어떤 분이 위에 쓰셨는데, 현실은 GPL로 공개하면 쫄딱 망하고 GPL 도용하면 먹고살만 해지는 정반대 상황이거든요. 뭐 지금까지도 전혀 개선이 안되는 걸로 봐서 앞으로 개선될 가능성은 없는 것 같지만 현실을 자꾸 무시하고 탁상공론만 펼쳐서는 안될 것 같네요.
좀 현실적이 돼 봅시다. 까놓고 얘기해서 지금 GPL 위반해서 먹고사는 회사 부지기수로 많은데 아무도 제재하지 못하는 건 왜 그런가요? GPL은 국내에서는 아무 구속력이 없어요.
이거 아주 이상한 상황이지 않나요. GPL 단물 뽑아먹어서 잘될리가 있냐고 어떤 분이 위에 쓰셨는데, 현실은 GPL로 공개하면 쫄딱 망하고 GPL 도용하면 먹고살만 해지는 정반대 상황이거든요. 뭐 지금까지도 전혀 개선이 안되는 걸로 봐서 앞으로 개선될 가능성은 없는 것 같지만 현실을 자꾸 무시하고 탁상공론만 펼쳐서는 안될 것 같네요.
RMS의 논리는 프로그램을 중심으로 어디까지 사회가 변할 것인가(얼마나 많은 분야에 쓰이게 될 것인가)를 짚어볼 수 없는 시절에 완성되었습니다.
그리고 세상은 그런 그의 논리를 비웃기라도 하듯 엄청난 속도로 발전하면서...주변에서는 이제 GPL의 논리로는 시장 자체가 성립하지 않는 분야도 많습니다.
당시는 기업용 비지니스 프로그램 하청 받아서 제작해주듯 만들어주고 그걸 유지보수한다는 개념이 어느정도 먹혔지만 당장 주변을 둘러보십시오. 유지보수 없이 소모되는 코드도 많습니다. 이렇게 연속성이 요구되지 않는 제품은 아이디어 이전에 코드가 공개되는 것만으로 상업적인 가치가 사라집니다.
그리고 아이디어와 코드를 분리해서 이야기하시는 분들도 있는데...글쎄요? 남의 포크가 자신의 제품을 개량한 것이고, 내가 그 포크의 개량된 코드를 흡수하면 된다고 하지만...그렇다면 마케팅과 자본만이 모든걸 좌우하는 세상이 올 것 같네요.
그건 그렇고 트롤테크가 GPL로 밥벌어먹는다는건 금시초문이군요.
트롤테크는 GPL로 호객을 하고 밥은 다른걸로 벌어먹는걸로 아는데요? :)
제가 생각하기에는 이걸 GPL의 석세스 케이스로 언급하는건 자유소프트 정신을 망각한 행위 같네요.
트롤테크는 GPL로 호객을 하고 밥은 다른걸로 벌어먹는걸로 아는데요? :)
제가 생각하기에는 이걸 GPL의 석세스 케이스로 언급하는건 자유소프트 정신을 망각한 행위 같네요.
다른걸로 벌어먹는지는 제가 트롤테크 재무구조를 몰라서 뭐라 말할건 없지만, GPL의 석세스케이스로 언급하는게 자유소프트웨어 정신을 망각하는 이유가 뭔가요?
GPL을 이용하여 나온 이득을 상업적으로 이용해서?
자유소프트웨어라는게 상업용소프트웨어를 부정하는건가요?
그럼 위의 예로들은 레드햇, 수세, mysql AB 등도 마찬가지인가요? zend사는? php는 GPL이 아니라서 derived work를 하더라도 소스공개를 안해도 괜찮다고요? 그럼 GPL자체를 자유소프트웨어에서 부정하시는겁니까?
위에 손님이 말씀하신 건 트롤텍이 GPL 쓰는 건 손님 끌어모으려는 홍보 수단이고, 실제로는 상용 라이선스 판매해서 돈번단 얘깁니다. 뭐 듀얼 라이선싱 제공하는 업체들이 전부 그런 스타일이죠. 결국에 외국도 순수 GPL로는 영업 불가능하고 상용 라이선싱을 끼워야만 장사가 된다는 얘기죠.
저는 GPL이 자유소프트웨어와 상충된다고 말한 것이 아닙니다. 정확하게 말하자면,
"지금 GPL을 이용하여 득을 보고 있는 업체는 두가지다. 하나는 듀얼 라이센스를 이용하여 GPL을 광고수단으로 삼고 실제 돈은 -당신이 돈을 벌고 싶다면- 유료 라이센스를 사라고 하여 수익을 취하는 회사. 다른 하나는 수많은 오픈소스 개발자의 works를 가져다 묶어서 팔기로 결정한 뒤 자본을 모아 이걸 관리할 수명의 개발자에게만 보수를 지급하는 장사꾼의 회사다."
정도로 말할 수 있겠군요. 전자가 트롤테크, 후자를 저는 레드햇이나 SuSE라고 봅니다.
전자의 경우는 악질입니다. 그들은 분명 GPL로 성공하고 있는 것이지만 이들의 성공이 GPL의 성공은 아닙니다. 오히려 이들은 GPL로 제품을 공개하고 "이 라이센스대로는 당신은 돈을 벌 수 있는 뭔가를 할 수 없다" 라는 점을 강조합니다. 그래서 이걸로 뭔가 돈이 될만한걸 만드려면 당신은 우리에게 돈을 내야한다. 라고 한다는 것이죠. 실제로 트롤테크의 석세스 스토리를 읽어보면 대부분이 이런 비공개 라이센스를 구매한 사례입니다. GPL 자체보다는 GPL과 현실이 가진 괴리를 최대한 이용하고 이 틈에서 단물을 빨아먹는다고 할 수 있겠군요.
SuSE 같은 후자의 경우는 프리소프트 정신에 반한다고 볼 수는 없습니다. 그러나 제 개인적인 관점에서 말하자면, 수많은 사람들이 코드를 공개하고 헌납할 때 이를 묶어서 팔고 여기서 생기는 수익을 경영자와, 일부의 유지보수를 위한 개발자들에게만 몰아주는 시스템은...여기에 기여한 대다수의 개발자들에게는 한 푼도 돌아가지 않게 됩니다. 그렇다면 그들은 뭘로 먹고 살까요? 물론 다른 일을 해서 먹고 사니까 그런 여유가 있겠지요. 하지만 제품의 완성에 기여한 대부분의 개발자는 나름대로의 직업을 통해 먹고살고, 일부의 경영자와 그 경영자들이 고른 소수의 선택받은 개발자가 제품의 이득을 독식하는게 과연 옳은 일일까요?
그리고 위의 두가지에 해당되지는 않지만 지금 오픈소스 씬에서 가장 괄목할만한 성과를 보이는 프로젝트를 살펴보면 "경쟁사를 견제하기 위하여 프로젝트를 여러 기업들이 물 밑에서 밀어준 덕분에" 성공한 사례를 쉽게 찾아볼 수 있습니다. 경쟁사를 쓰러트린 다음에 이런 기업들의 태도가 어떻게 변할지는 아무도 모르겠지만 그리 이상적인 미래는 아닐 것 같습니다.
규모의 법칙이라도 있는 것일까요? 프로젝트가 일정 규모 이상이라면 대부분이 3가지 중 하나가 됩니다.
듀얼 라이센스를 이용한 수익구조, RMS는 개발자가 자신의 제품을 유지보수하여 수입을 얻으면 된다고 했지만 개발자 자신이 아닌 다른 이들이 (자본과 마케팅의 힘을 무기로) 대신 유지보수를 하고, 경쟁사를 견제하기 위한 수단의 하나로 스폰서가 되어줄 뿐...
Java는 Sun의 지적재산입니다.
제임스 고슬링꺼는 아닌데요.. 그리고 스톨만과의 유명한 불화는 "지적재산으로 돈을 벌수 있다"를 인정하느냐 않하느냐의 차이로 발생한거조. Emac때도 그랬고요. 스톨만같은 "모든 정보를 공개하고 공유하자"라는 사람은 누구하고도 싸움이 일어납니다. 뭐 해커들이야 스톨만을 지지하지만, 먹고 사는 일이 걸리는 대부분의 프로그래머들에게는 별로 받아들이기 어려운 일이기도 합니다. (심정적으로야 저도 지지합니다만...)
아무튼 그것때문에 스톨만이 고슬링을 비난하는데 사람들이 이걸 일방적으로 받아들이는 것도 문제입니다.
그리고 자바는 이미 오픈소스입니다만...
Community License로 소스코드를 받아 볼수 있고, Class 소스는 아예 JDK에 포함되어 나옵니다. 꽤나 오래전부터 그랬죠.
Java Virtual Machine 스펙이나 Java Language Spec이나 모두 공개되어 있고요.
이부분에 대한 부연 설명 부탁합니다. 오픈 소스의 핵심은 단순히 소스를 볼 수 있다가 아니고, 그 소스를 이용해서 재배포할 수 있다로 알고 있거든요. 자바 소스를 이용해서 다른걸 만들어서 배포해도 되는지 궁금합니다.
예전에 윈도2000 소스가 인터넷에 돌았지만, 특히 오픈소스 진영에서는 아예 소스를 보지 말아라 하는 말까지 있었습니다. 소스를 보면 소스를 따라하게 되고, 잘못하다간 저작권 문제가 날 수 있기 때문이죠.
SUN이 실제로 내려 놔야 하는 것은 비싼 TCK 입니다.
만약 TCK가 무료가 되거나 부담이 없는 가격이 된다면, 수많은 Open & Free JVM이 등장할 겁니다. 당장 Kaffe나 GCJ등이 TCK에 검증될수 있게 되겠죠
그럼 Java 상호 운영성이 대폭 상승 할 것이고, Embedded 시장에도 새로운 바람을 불러 일으킬수 있죠.
ps. 참고로 1 JVM on 1 OS TCK가 8만달라입니다.
특정 운영체제에서 동작하는 특정 JVM이 TCK를 통과하려면 8만 달라를 내야 합니다. -_-
운영체제가 바뀌면 또 TCK를 통과해야 합니다.
비싸죠.. -_-
그쪽 지식이 잘 없어서 TCK가 뭔지는 확실히 모르지만, 자바 호환성 테스트쯤으로 생각하겠습니다. 공식 테스트 통과한거다하고 도장찍어주는거 맞죠?
사실 이런게 비싸면 SUN의 권위를 이용하려는 중소업체의 활동에는 지장이 있을지 모르겠지만 오픈소스 진영에까지 큰 지장이 있을지는 의문입니다. 물론 만들어놓고 테스트를 안해준다고 칭얼대기는 하겠지만요. 리눅스 초기에 posix 표준 문서 보지도 많고 만들었다는 얘기도 있을 정도인데요. 오픈소스로 거나하게 만들어서 떠버리면 알아서 테스트해줄겁니다 -_-;; 아니면 래드햇 같은데에서 돈좀 내줘서 테스트할지도 모르고요.
그리고 MySQL 이야기가 잠깐 나왔는데 MySQL을 상업적으로 이용하는 것은 GPL 위반이라고 단정할 수 없습니다. GPL은 소프트웨어의 이용에 관해서는 완전한 자유를 허가하고 있습니다. 이것에 관해서는 이미 많이 논의된 바가 있죠.
다른 오픈 소스 툴들하고만 묶어서 상업화한다면 물론 GPL 위반 아니죠. 하지만 실제로는 상용 웹솔루션을 공급할 때 중간에 proprietary 코드가 안들어간 솔루션은 제가 아는 한 국내에 한개도 없습니다. 단순히 프로그램 몇개 모아놨다고 솔루션이라고 말하진 안거든요. 그러니까 100% GPL 위반인 겁니다.
오픈 소스의 핵심은 단순히 소스를 볼 수 있다가 아니고, 그 소스를 이용해서 재배포할 수 있다로 알고 있거든요.
이건 OSI의 오픈소스 정의일 뿐이지 이게 일반적으로 통용되는 오픈소스의 정의라고 보긴 무리가 있습니다. 그보다 말 그대로 소스가 오픈되어 있으면 오픈소스라고 보는 게 더 맞는 표현이겠죠.
아닙니다. 소스가 공개되어있지만 그것이 베낄 수 없는 라이센스에 걸려있다면 그림의 떡일 뿐입니다. 그 소스를 가지고는 아무것도 할 수가 없죠. 예전에 windows 2000의 소스가 퍼진 일이 있었죠. 오픈소스 개발자들은 그것을 보지 말라고 했습니다. 괜히 봤다가 본의 아니게 스며들어가면 저작권 문제가 일어날 소지가 있다는 이유였습니다.
"소스가 오픈되어 있으면 오픈소스" 라는 개념은 조금 위험해보입니다만.
Quote:
그리고 트롤텍이 악질이라는 건 아무리봐도 어거지입니다. GPL로 뻔히 배포되고 있는데 뭐가 문제란 건지. GPL이 있음에도 상용 라이센스를 따로 제공하는 것은 오히려 고객을 위한 겁니다. 생각해보세요. GPL만 있으면 기업에서는 Qt 어떻게 가져다 쓰겠습니까?
그리고 MySQL 이야기가 잠깐 나왔는데 MySQL을 상업적으로 이용하는 것은 GPL 위반이라고 단정할 수 없습니다. GPL은 소프트웨어의 이용에 관해서는 완전한 자유를 허가하고 있습니다. 이것에 관해서는 이미 많이 논의된 바가 있죠.
그리고 GPL은 국내에서도 엄연히 효력이 있습니다. 하지만 저작권의 특성상 소유권을 가진 사람이 직접 소송을 걸지 않으면 소용이 없죠. 단지 지금까지 국내에서 GPL로 소송한 경우가 없을 뿐 GPL 위반 사실만 증명된다면 충분히 법적인 보상을 받아낼 수 있습니다.
저도 트롤텍이 악질이라는 데는 동의하지 않습니다. 기업과 오픈 소스의 절묘한 관계 정도로 생각하고 있습니다. 이하 이야기는 제가 주장한 내용이 아니라서 특별히 답변할 내용은 없는거 같네요 :) 대충 동의합니다.
아닙니다. 소스가 공개되어있지만 그것이 베낄 수 없는 라이센스에 걸려있다면 그림의 떡일 뿐입니다. 그 소스를 가지고는 아무것도 할 수가 없죠. 예전에 windows 2000의 소스가 퍼진 일이 있었죠. 오픈소스 개발자들은 그것을 보지 말라고 했습니다. 괜히 봤다가 본의 아니게 스며들어가면 저작권 문제가 일어날 소지가 있다는 이유였습니다.
"소스가 오픈되어 있으면 오픈소스" 라는 개념은 조금 위험해보입니다만.
언어 표현의 의미를 결정하는데 있어서 그런 게 무슨 상관이 있으며 위험할 건 또 무엇입니까? 표현의 의미를 결정하는 것은 두 가지, 말 그대로 해석할 때 어떤 의미인가와 실제로 어떤 의미로 쓰이고 있는가입니다. 말 그대로 해석하면 분명히 그저 소스가 오픈되어 있는 것을 가리키는 것이죠. 그리고 오픈소스에 수정 및 재배포의 권한을 포함시키는 것은 단지 커뮤니티의 자의적인 정의일 뿐 개발자 집단 전체에서 널리 통용되고 있다고 보긴 힘듭니다.
언어 표현의 의미를 결정하는데 있어서 그런 게 무슨 상관이 있으며 위험할 건 또 무엇입니까? 표현의 의미를 결정하는 것은 두 가지, 말 그대로 해석할 때 어떤 의미인가와 실제로 어떤 의미로 쓰이고 있는가입니다. 말 그대로 해석하면 분명히 그저 소스가 오픈되어 있는 것을 가리키는 것이죠. 그리고 오픈소스에 수정 및 재배포의 권한을 포함시키는 것은 단지 커뮤니티의 자의적인 정의일 뿐 개발자 집단 전체에서 널리 통용되고 있다고 보긴 힘듭니다.
세계 어느 개발자 커뮤니티를 가도 '오픈소스'를 단지 소스가 공개된 프로그램으로 정의하는 경우는 못봤습니다. 적어도 최근 2-3년 전부터 말이죠. 당장 ZDNet 같은 매체만 해도 오픈소스를 언급할 때 OpenSource Initiative의 정의를 인용하는 마당에 소스가 오픈되어 있다고 오픈소스라고 말하는 것은 비현실적입니다. 그리고 실제로 이러한 오해가 위험을 자초할 수도 있습니다. 소스는 오픈되어 있지만 재배포에 제한이 있는 라이센스를 가져다 자기맘대로 배포하는 몰상식이 부지기수로 일어나거든요.
언어 표현의 의미를 결정하는데 있어서 그런 게 무슨 상관이 있으며 위험할 건 또 무엇입니까? 표현의 의미를 결정하는 것은 두 가지, 말 그대로 해석할 때 어떤 의미인가와 실제로 어떤 의미로 쓰이고 있는가입니다. 말 그대로 해석하면 분명히 그저 소스가 오픈되어 있는 것을 가리키는 것이죠. 그리고 오픈소스에 수정 및 재배포의 권한을 포함시키는 것은 단지 커뮤니티의 자의적인 정의일 뿐 개발자 집단 전체에서 널리 통용되고 있다고 보긴 힘듭니다.
아랫분이 대답하셨지만 제 주위에서도 단지 소스가 있으면 오픈 소스 소프트웨어라는 개념을 사용하는 곳은 많이 보지 못했습니다.
이 개념은 중요합니다. 그 차이가 바로 오픈소스인가 아닌가를 가르는 최대의 척도라고 생각합니다. 그리고 자바는 아직 그 척도를 넘지 못하고 있죠.
그리고 당연하지만 그 차이가 바로 오픈 소스 커뮤니티의 지원을 제대로 받을 수 있는지 없는지에 대한 척도이기도 합니다. 물론 자바가 나름의 정책을 통해 시장에서 엄청나게 성공을 하긴 했습니다만 오픈 소스 진영에서의 시각이 그리 좋지 않은 것은 바로 이 선을 넘지 못했기 때문입니다.
제 생각에 자바가 그 선을 넘지 못하는 한 오픈 소스 진영에서의 경계는 계속 되리라고 생각합니다. (물론 자바의 성공과는 별개로입니다.)
국내 소프트웨어 시장은 패키지쪽은 불법복사때문에 전부 망했지만 아웃소싱쪽은 그냥그냥 먹고살만 합니다. 대신 소스 공개했다간 다음날로 쫄딱 망하거든요. GPL은 남의 나라 얘깁니다.
그 아웃소싱하는 회사들은 오픈 소스 제품들은 하나도 쓰지 않고 장사하나보지요? GPL 덕에 그나마 먹고 사는 사람들이 무슨 GPL 핑계를 댑니까? GPL이 남의 나라 얘기면 당장 오늘부터 GPL 걸린 소프트웨어 쓰지 말고 장사하세요.
Quote:
근데 그런 상황을 잘 모르시는 걸 보니 logout님은 한번도 회사에서 근무해본 적이 없으신 것 같네요. 맞죠? 저도 대학생때는 왜 GPL이 안되는지 의아했는데 회사 생활해보니까 당장 알겠더군요. 학교에만 계시지 말고 회사 생활도 해보시면서 견문을 넓히시길~
회사 생활하면서 GPL이 왜 안되는지 당장 알았으면 구체적으로 왜 GPL이 안되는지 여기에다 몇자 적어보세요. 회사 경험 없는 사람도 좀 배우게요. 회사 생활하면서도 견문이 넓어지기는 커녕 이윤 몇푼 핑계에 아집만 느는 사람들 숱하게 봐왔습니다. 보통 그런 사람들이 현실 어쩌고 핑계 대면서 이론은 쓸데없다는 얘기를 잘 하지요. 그런데 막상 뭐가 문제인지 구체적으로 설명을 해 봐라고 하면 꼭 자네가 현실 경험을 해 보기 전에는 모른다.... 핑계를 대면서 꼬리를 내리더군요.
아.. 그리고 "logout 님"같이 개인적인 언급을 할려면 그쪽도 로긴을 하세요. 익명 뒤에 숨지 말구요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
7. Nothing in the licensing terms will prevent open source projects from creating and distributing their own compatible open source implementations of J2SE 6.0, using standard open source licenses. (Yes, you can create your own open source implementation of J2SE 6.0 if you really want to. But we're also doing everything we can to make it easy for you to use the original RI sources! See http://j2se.dev.java.net.)
이라는 내용이 나옵니다.
그리고, 위의 내용을 뒷받침 하기위해 세가지 다른 license를 적용한다는 이야기가 진행 중입니다.
Quote:
JRL: Java Research License.
The Java Research License applies to academia, and allows researchers to share code with other researchers.
JDL: Java Development License.
The Java Development License is intended for companies who wish to release their own Java implementations. As in previous times, it will still require extensive compatibility testing.
JIUL: Java Internal Use License.
Java Internal Use License is the one that is generating the most interest. The JIUL allows companies to fork Java for internal use. Although compatibility is still required, it is based on the honor system. The license does require you to agree that you will not intentionally break compatibility, but no actual compatibility testing is required. This license is intended primarily for companies to make their own bug fixes. Companies are also encouraged to contribute their bug fixes back to Java. Sun has also stated that compatibility enforcement will not be a heavy handed tactic for companies that inadvertantly break compatibility. If a company inadvertantly gets into an incompatability issue, Sun will help that company get their implementation back to being compatible again.
저 위에 링크된 Harmony 프로젝트의 결과가 어떻게 될지는 지켜보아야겠지만, Sun이 자바 license에 대한 압박을 여러 곳에서 받고 있는 중이라 수동적이기는 해도 바뀌고는 있다고 생각을 합니다.
하지만, 위의 license들로 Java Trap을 해결할 수는 없겠죠. 따라서, 어찌보면 번죽만 한 셈일수도 있는데, "오픈소스로 호환 J2SE를 만든다", "license를 바꿔라", "Open Source 해라"하고 압박이 가해지면 무엇이든 결과는 있겠죠.
ps1. Sun이 MS와 JVM 사용에 대한 합의를 했는데, Sun이 자바를 Open Source할 수 있나요?
Ps2. Mono처럼 뭔가 만들면서 압박을 하는 것도 하나의 방법이라면, 그런 점에서 Harmony 프로젝트는 자바를 Open Source화 하는데 첨병이 될 수 있을까요?
----
I paint objects as I think them, not as I see them. atie's minipage
GPL의 관점에서 보자면 악질이라는 것이지요. :)
GPL이라는 것이 FSF의 심장이라고 할 수도 있다보니, GPL을 이해하고 GPL의 관점에서 보자면 당연히 악질이잖아요? :oops:
글 쓴 저는 저 위에도 적었지만 "RMS 논리로는 시장 자체가 성립하지 않는" 분야에서 밥을 벌어먹고 있습니다. 당근 GPL과는 백만광년쯤 거리가 있구요...
그렇지만 토론을 한다면 그런 자신의 출신은 좀 덜 신경써도 되도록 남의 배경 넘겨짚기는 삼가했으면 좋겠습니다.
트롤텍이 Qt를 GPL로 배포한다고 하자 가장 반가워한 사람중 하나가 RMS인데 뭔 말씀이세요? 의심스러우면 Qt GPL 발표문 한번 읽어보세요. 인용된 사람이 누군지.
그렇다면 듀얼 라이센스를 배제하기 위한 GPL 개정의 이유는 어디서 온 것일까요?
전에도 말했지만 RMS 역시 앞으로 일어날 모든 일을 다 알고 있는 것은 아닙니다. 트롤테크가 GPL로 배포하긴 했지만 결국 이런 듀얼라이센스 업체가 프리소프트 씬에 어떤 기여를 했던가요? 최근 MySQL의 예를 봐도 알 수 있듯 GPL에 대한 FUD를 퍼트리고, 협박 무기로 쓰고 있을 뿐입니다.
open source J2SE가 나온다면 IBM이나 BEA같이 기존에 J2SE를 독자적으로 만들던 회사 입장에서는 반기지 않을까 생각하는데요.
Harmony 프로젝트가 어느정도 활성화된다면 이런 기업들의 지원을 기대해 볼 수 있지 않을까요?
그렇게되면 SUN에게도 상당한 압력이 될 것 같은데...
ps1. Sun이 MS와 JVM 사용에 대한 합의를 했는데, Sun이 자바를 Open Source할 수 있나요?
제가 아는 한도에서 MS가 썬의 공개된 JVM 코드에 contribute 한 부분은 없다고 알고 있습니다. MS는 썬에서 JVM 코드를 사서 이를바탕으로 MS의 JVM을 만들었고 이를 윈도우즈에 번들시켜 배포했습니다. 거꾸로 썬의 공개된 코드에 MS가 copyright를 주장할 부분은 없는 것으로 알고 있습니다만... 확실하지는 않구요.
Quote:
Ps2. Mono처럼 뭔가 만들면서 압박을 하는 것도 하나의 방법이라면, 그런 점에서 Harmony 프로젝트는 자바를 Open Source화 하는데 첨병이 될 수 있을까요?
충분히 가능한 얘기일 것 같습니다만 개인적으로 그 전에 어떤 이유 때문에 썬이 계속 자바에 대한 제어권을 놓으려 하지 않는지가 무척 궁금합니다. 단순히 자바를통한 매출을 잃고 싶지 않다는 것일까요? 어쨌거나 당연한 얘기이겠지만, 이 부분이 좀 더 명확해져야 Harmony 프로젝트가 효과적으로 썬에 자극을 줄 수 있을지 없을지의 판단 또한 따라서 명확해지지 않을까 싶습니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
전에도 말했지만 RMS 역시 앞으로 일어날 모든 일을 다 알고 있는 것은 아닙니다. 트롤테크가 GPL로 배포하긴 했지만 결국 이런 듀얼라이센스 업체가 프리소프트 씬에 어떤 기여를 했던가요? 최근 MySQL의 예를 봐도 알 수 있듯 GPL에 대한 FUD를 퍼트리고, 협박 무기로 쓰고 있을 뿐입니다.
듀얼라이센스 업체( GPL을 채택한 )가 기여하는 바는
듀얼라이센스가 아닌 순수 GPL 소프트웨어가 기여하는 바와
아무런 차이가 없습니다.
제가 Qt를 가져다가 Rt를 만들든 At,Bt를 만들든
MySQL을 가져다가 YourSQL을 만들든 GPL에 위반되지만
않으면 아무런 제약이 없습니다.
ps1. Sun이 MS와 JVM 사용에 대한 합의를 했는데, Sun이 자바를 Open Source할 수 있나요?
제가 아는 한도에서 MS가 썬의 공개된 JVM 코드에 contribute 한 부분은 없다고 알고 있습니다. MS는 썬에서 JVM 코드를 사서 이를바탕으로 MS의 JVM을 만들었고 이를 윈도우즈에 번들시켜 배포했습니다. 거꾸로 썬의 공개된 코드에 MS가 copyright를 주장할 부분은 없는 것으로 알고 있습니다만... 확실하지는 않구요.
Quote:
Ps2. Mono처럼 뭔가 만들면서 압박을 하는 것도 하나의 방법이라면, 그런 점에서 Harmony 프로젝트는 자바를 Open Source화 하는데 첨병이 될 수 있을까요?
충분히 가능한 얘기일 것 같습니다만 개인적으로 그 전에 어떤 이유 때문에 썬이 계속 자바에 대한 제어권을 놓으려 하지 않는지가 무척 궁금합니다. 단순히 자바를통한 매출을 잃고 싶지 않다는 것일까요? 어쨌거나 당연한 얘기이겠지만, 이 부분이 좀 더 명확해져야 Harmony 프로젝트가 효과적으로 썬에 자극을 줄 수 있을지 없을지의 판단 또한 따라서 명확해지지 않을까 싶습니다.
Sun이 MS한테 MSJVM을 2007년 말까지 사용을 할 수 있도록 한 댓가로 돈을 받았기에 최소한 2007년 말까지는 자바를 오픈소스로 풀지는 못할 것이라는 제 추측입니다. 그렇지만, Gosling은 자바는 돈을 벌기위한 수단이 아니라고 분명히 이야기 했습니다.
두번째 인용에 대해서는, 글쎄요? 표면적인 이유로는 어플리케이션 개발자를 위해서는 최소한 compatibility testing이 된 VM만을 허용하기 위해 가장 잘 아는 Sun이 그 임무를 맡겠다는 것인데... 아무래도 IBM에 대한 견제가 첫번째, 두번째는 Java라는 브랜드, 세번째는 살아남기 위해서가 이유들이 아닐까 싶습니다.
----
I paint objects as I think them, not as I see them. atie's minipage
Kaffe나 GCJ, Wonka 등의 많은 수의 VM들이 모두 JVM이 아닙니다.
TCK를 통과하지 못했기 때문이죠.
따라서 자바 언어와 자바 바이트 코드를 지원하기는 하지만 자바와 완전히 호환되는 JVM은 아닌겁니다.
이런 VM으로 뭘 할수 있을까요? 기껏해야 다른 오픈소스제작용이나 연구용으로 밖에 사용할수 없습니다. 사실 그것도 어렵죠. "내가 만든 코드가 제대로 된 JVM에서 돌아갈까?"라는 의문을 가지게 될 겁니다. 이걸 가지고 J2EE Container등을 돌릴수 있을까요?
그런데 TCK를 통과하게 되면 JVM이라고 할수 있습니다. 상호 호환성이 보장되었다는 의미입니다.
아파치에서 어떤 식으로 VM을 만들지는 모릅니다. 뭐 Kaffe를 가져와서 만들수도 있고 GCJ를 발전 시키는 형태가 될수도 있고..
하지만 어떻게 되던지 간에 그 결과물이 TCK를 통과해서 호환성을 보장받는다고 하면, 이제부터는 이야기가 달라집니다.
뭐 예상컨데 하모니 프로젝트는 x86에 linux 기반으로 TCK를 통과할겁니다. 어찌되었든 통과하게 될거고, 아파치에서는 이 JVM을 제작할때 Portability를 극대화 하는 방향으로 제작하게 될겁니다. 아마 posix기반에 makefile만 수정해주면 어디든지 포팅되는 형태가 되겠죠.
그때는 이 JVM을 다른 곳으로 포팅하고 이렇게 말할수 있습니다.
"이 JVM은 Linux에서 TCK를 통과한 코드이고, 하드웨어 의존성이 없기 때문에 이 CPU와 이 OS에서도 사실상 TCK를 통과한 것으로 간주해도 됩니다. 뭐 나중에 돈 되면 TCK를 신청하죠"라고 말이죠.
그리고 시간이 지나면 아파치에서는 대표적인 아키텍쳐와 OS들에 대해 TCK를 통과할겁니다.
그렇게 되면 이 VM은 "신뢰할수 있는" JVM이 되는 겁니다.
오픈소스용이나 연구용이 아닌 상업적으로 선택될수 있는 JVM이 되는 거죠.
(물론 Hotspot이나 jit등의 퍼포먼스 엔진은 어떻게 될지 모르겠습니만..)
신뢰할수 있는 Open source JVM을 가지게 되면 이것을 다양한 목적으로 사용할수 있게 됩니다. Openoffice에 아예 포함시킬수도 있을것이고, 다양한 프로젝트에서 java를 사용할수 있게 될겁니다.
ps. 개인적으로는 하모니 프로젝트에서 CVM도 같이 진행되었으면 하는 바램이 있습니다. TCK를 받은 프리소프트웨어인 CVM이 있다면 할수 있는게 대단히 많아지거든요.
Kaffe나 GCJ, Wonka 등의 많은 수의 VM들이 모두 JVM이 아닙니다.
TCK를 통과하지 못했기 때문이죠.
따라서 자바 언어와 자바 바이트 코드를 지원하기는 하지만 자바와 완전히 호환되는 JVM은 아닌겁니다.
못한 게 아니라 안한 것 뿐입니다. 사실은 바로 압시다.
Quote:
이런 VM으로 뭘 할수 있을까요? 기껏해야 다른 오픈소스제작용이나 연구용으로 밖에 사용할수 없습니다. 사실 그것도 어렵죠. "내가 만든 코드가 제대로 된 JVM에서 돌아갈까?"라는 의문을 가지게 될 겁니다. 이걸 가지고 J2EE Container등을 돌릴수 있을까요?
그런데 TCK를 통과하게 되면 JVM이라고 할수 있습니다. 상호 호환성이 보장되었다는 의미입니다.
이미 만들어진 오픈소스 VM들은 앞으로도 TCK를 통과못할 것이고 아직 만들어지지도 않은 가상의 VM은 TCK를 통과할 것이라고 가정하는 근거는 뭐지요? 아무리 생각해도 희한하게 들립니다.
Quote:
아파치에서 어떤 식으로 VM을 만들지는 모릅니다. 뭐 Kaffe를 가져와서 만들수도 있고 GCJ를 발전 시키는 형태가 될수도 있고..
아파치 하모니 VM은 아파치 라이센스를 따를 것이기 때문에 Kaffe나 GCJ로는 단한줄도 따올 수 없습니다.
Quote:
하지만 어떻게 되던지 간에 그 결과물이 TCK를 통과해서 호환성을 보장받는다고 하면, 이제부터는 이야기가 달라집니다.
뭐 예상컨데 하모니 프로젝트는 x86에 linux 기반으로 TCK를 통과할겁니다. 어찌되었든 통과하게 될거고, 아파치에서는 이 JVM을 제작할때 Portability를 극대화 하는 방향으로 제작하게 될겁니다. 아마 posix기반에 makefile만 수정해주면 어디든지 포팅되는 형태가 되겠죠.
그때는 이 JVM을 다른 곳으로 포팅하고 이렇게 말할수 있습니다.
"이 JVM은 Linux에서 TCK를 통과한 코드이고, 하드웨어 의존성이 없기 때문에 이 CPU와 이 OS에서도 사실상 TCK를 통과한 것으로 간주해도 됩니다. 뭐 나중에 돈 되면 TCK를 신청하죠"라고 말이죠.
그리고 시간이 지나면 아파치에서는 대표적인 아키텍쳐와 OS들에 대해 TCK를 통과할겁니다.
그렇게 되면 이 VM은 "신뢰할수 있는" JVM이 되는 겁니다.
오픈소스용이나 연구용이 아닌 상업적으로 선택될수 있는 JVM이 되는 거죠.
(물론 Hotspot이나 jit등의 퍼포먼스 엔진은 어떻게 될지 모르겠습니만..)
신뢰할수 있는 Open source JVM을 가지게 되면 이것을 다양한 목적으로 사용할수 있게 됩니다. Openoffice에 아예 포함시킬수도 있을것이고, 다양한 프로젝트에서 java를 사용할수 있게 될겁니다.
ps. 개인적으로는 하모니 프로젝트에서 CVM도 같이 진행되었으면 하는 바램이 있습니다. TCK를 받은 프리소프트웨어인 CVM이 있다면 할수 있는게 대단히 많아지거든요.
상당히 생뚱맞은 이상한 가정이네요. 하모니가 TCK를 통과할 것이란 근거없는 낙관은 대체 어디에 기반을 한 것인지...?
Kaffe나 GCJ, Wonka 등의 많은 수의 VM들이 모두 JVM이 아닙니다.
TCK를 통과하지 못했기 때문이죠.
따라서 자바 언어와 자바 바이트 코드를 지원하기는 하지만 자바와 완전히 호환되는 JVM은 아닌겁니다.
못한 게 아니라 안한 것 뿐입니다. 사실은 바로 압시다.
못했단 안 했든 TCK 인증이 없습니다.
Quote:
Quote:
이런 VM으로 뭘 할수 있을까요? 기껏해야 다른 오픈소스제작용이나 연구용으로 밖에 사용할수 없습니다. 사실 그것도 어렵죠. "내가 만든 코드가 제대로 된 JVM에서 돌아갈까?"라는 의문을 가지게 될 겁니다. 이걸 가지고 J2EE Container등을 돌릴수 있을까요?
그런데 TCK를 통과하게 되면 JVM이라고 할수 있습니다. 상호 호환성이 보장되었다는 의미입니다.
이미 만들어진 오픈소스 VM들은 앞으로도 TCK를 통과못할 것이고 아직 만들어지지도 않은 가상의 VM은 TCK를 통과할 것이라고 가정하는 근거는 뭐지요? 아무리 생각해도 희한하게 들립니다.
통과못할 거라는 근거는 또 뭔가요 ?
Quote:
Quote:
아파치에서 어떤 식으로 VM을 만들지는 모릅니다. 뭐 Kaffe를 가져와서 만들수도 있고 GCJ를 발전 시키는 형태가 될수도 있고..
아파치 하모니 VM은 아파치 라이센스를 따를 것이기 때문에 Kaffe나 GCJ로는 단한줄도 따올 수 없습니다.
아파치 재단에서 후원한다 하여 아파치 라이센스를 꼭 따라야 하나요 ?
Quote:
Quote:
하지만 어떻게 되던지 간에 그 결과물이 TCK를 통과해서 호환성을 보장받는다고 하면, 이제부터는 이야기가 달라집니다.
뭐 예상컨데 하모니 프로젝트는 x86에 linux 기반으로 TCK를 통과할겁니다. 어찌되었든 통과하게 될거고, 아파치에서는 이 JVM을 제작할때 Portability를 극대화 하는 방향으로 제작하게 될겁니다. 아마 posix기반에 makefile만 수정해주면 어디든지 포팅되는 형태가 되겠죠.
그때는 이 JVM을 다른 곳으로 포팅하고 이렇게 말할수 있습니다.
"이 JVM은 Linux에서 TCK를 통과한 코드이고, 하드웨어 의존성이 없기 때문에 이 CPU와 이 OS에서도 사실상 TCK를 통과한 것으로 간주해도 됩니다. 뭐 나중에 돈 되면 TCK를 신청하죠"라고 말이죠.
그리고 시간이 지나면 아파치에서는 대표적인 아키텍쳐와 OS들에 대해 TCK를 통과할겁니다.
그렇게 되면 이 VM은 "신뢰할수 있는" JVM이 되는 겁니다.
오픈소스용이나 연구용이 아닌 상업적으로 선택될수 있는 JVM이 되는 거죠.
(물론 Hotspot이나 jit등의 퍼포먼스 엔진은 어떻게 될지 모르겠습니만..)
신뢰할수 있는 Open source JVM을 가지게 되면 이것을 다양한 목적으로 사용할수 있게 됩니다. Openoffice에 아예 포함시킬수도 있을것이고, 다양한 프로젝트에서 java를 사용할수 있게 될겁니다.
ps. 개인적으로는 하모니 프로젝트에서 CVM도 같이 진행되었으면 하는 바램이 있습니다. TCK를 받은 프리소프트웨어인 CVM이 있다면 할수 있는게 대단히 많아지거든요.
상당히 생뚱맞은 이상한 가정이네요. 하모니가 TCK를 통과할 것이란 근거없는 낙관은 대체 어디에 기반을 한 것인지...?
무지막지하게 생뚱맞은데, 하모니가 TCK 를 통과하지 못할 것이라는 근거없는 비관은 대체 어디에 기반을 한 것인지... ?
맨땅에 헤딩하고 있든 허공에 삽질을 하든 나온다음에나 통과 여부가 결정되는 거지 나오지도 않았는데, 통과 못할 것이라는 망상은 머리세요. 통과한다고 말하는 것도 우습지만, 못할 거라는 것도 우습습니다.
그리고 역시나 나오지도 않은 놈을 아파치 라이센스일 거라고 단정하는 오류는 범하지 마세요.
아 이론...어이를 옥션에 팔아넘긴 것 같은 말씀이...아파치 재단에서 하모니를 아파치 라이센스로 개발할 거라고 프로젝트 시작하면서 명확하게 못박은바 있는데 그것도 모르시면서 하모니가 TCK를 통과할거라는 등등 말씀하시는 거는 증말 문제가 있다고 밖에는 볼 수가 없네요. 괜히 남들이 TCK 어쩌고 JVM 어쩌고 떠든다고 덩달아 끼어들어 아는 척은 삼가해 주세요.
이 얘기 벌써 몇달전에 KLDP에서도 끝난 얘긴데...non-free 프로그램은 GPL 버전의 MySQL에 접근 못하게 돼있습니다. 의심스러우시면 MySQL 사이트에 가서 라이선싱 정책을 읽어보세요.
끝나긴 뭐가 끝난 얘깁니까. 얼마 전 있었던 MySQL 토론에서도 갑론 을박이 난무했었는데.. 그리고 MySQL 사이트의 라이센스 정책은 이미 충분히 읽어봤습니다. 하지만 그건 라이센스에 대한 MySQL 측의 "입장"인 것이지 그것이 GPL에 대한 해석은 아니죠. GPL 위반 여부를 가리려면 GPL 조항이 우선인 것은 당연하지 않습니까?
이 얘기 벌써 몇달전에 KLDP에서도 끝난 얘긴데...non-free 프로그램은 GPL 버전의 MySQL에 접근 못하게 돼있습니다. 의심스러우시면 MySQL 사이트에 가서 라이선싱 정책을 읽어보세요.
끝나긴 뭐가 끝난 얘깁니까. 얼마 전 있었던 MySQL 토론에서도 갑론 을박이 난무했었는데.. 그리고 MySQL 사이트의 라이센스 정책은 이미 충분히 읽어봤습니다. 하지만 그건 라이센스에 대한 MySQL 측의 "입장"인 것이지 그것이 GPL에 대한 해석은 아니죠. GPL 위반 여부를 가리려면 GPL 조항이 우선인 것은 당연하지 않습니까?
그렇게 의심스러우시면 MySQL의 국내 총판인 바인테크던가 하는 회사에 전화걸어서 물어보세요. 바인테크가 뭐라고 떠들든 난 내맘대로 쓰겠다고 하시면 할말 없지만...
기존의 오픈소스들이 TCK를 통과하지 못한/않한 이유는 돈입니다.
TCK 비용 8만달라를 1 CPU/OS 마다 내야 합니다. 같은 CPU인데 Win 98, W2k, XP에서 각각 8만 달라씩 내야 하죠. 같은 리눅스인데 레드헷 7, 레드햇 8, 레드헷 9, FC 마다 8만달라씩 내야하죠.
(참고로 2002년엔가 IBM은 100만달라 가까운 돈을 J9의 TCK 통과 비용으로 사용했습니다. )
아랫분이 대답하셨지만 제 주위에서도 단지 소스가 있으면 오픈 소스 소프트웨어라는 개념을 사용하는 곳은 많이 보지 못했습니다.
개인적인 경험일 뿐입니다.
Quote:
세계 어느 개발자 커뮤니티를 가도 '오픈소스'를 단지 소스가 공개된 프로그램으로 정의하는 경우는 못봤습니다.
마찬가지로 개인적인 경험일 뿐이죠.
개인적인 경험을 말한다면 제가 경험했던 개발자들은 대부분 소스만 공개되어 있으면 오픈소스라고 인식했었다고 대답할 수 있습니다. 실제 SI 하는 개발자들은 오픈소스 공동체가 뭐하는 건지 잘 모릅니다. 그냥 단어의 의미를 그대로 받아들일 뿐이죠. 개발자 커뮤니티라는 것은 이미 오픈소스 공동체의 영향을 많이 받는 상태니까 그들의 정의로 사용할 수도 있겠지만 현업에서 당장 학원 6개월 다니고 들어온 개발자들이 그런 정의를 알 꺼라고 생각하십니까? 그렇다고 그들이 지식이 모자라서 착각한다고 쉽사리 말할 수 없는 것이 원래 오픈소스의 말뜻이 소스 공개의 의미이기 때문입니다.
물론 점차적으로 OSI 식 오픈소스의 정의가 확산되고 있으니 앞으로 1~2년 후는 그렇게 말할 수 있을지도 모릅니다. 하지만 최소한 지금은 자바가 오픈소스라고 인식하는 사람이 많고 오픈소스의 조건으로 소스공개만 생각하는 사람이 많기 때문에 당장 언어의 의미를 획일적으로 바꿔서 사용하는 것은 오히려 더 위험해보입니다.
Quote:
소스는 오픈되어 있지만 재배포에 제한이 있는 라이센스를 가져다 자기맘대로 배포하는 몰상식이 부지기수로 일어나거든요.
그리고 이것은 오픈소스라는 용어의 위험성이라기보다 라이센스에 대한 부주의에서 오는 위험이겠지요. 오픈소스의 OSI식 정의를 알더라도 GPL에 대해 잘 모르면 위험한 일은 얼마든지 발생할 수 있습니다. 기본적으로 개발자가 라이센스에 얼마나 신경을 쓰느냐의 문제지 용어에 대한 혼동의 문제는 아니라고 봅니다.
Quote:
제 생각에 자바가 그 선을 넘지 못하는 한 오픈 소스 진영에서의 경계는 계속 되리라고 생각합니다. (물론 자바의 성공과는 별개로입니다.)
오픈소스 진영에서 자바를 경계한다는 것은 성급한 일반화입니다. RSM을 위시한 일부 세력에서만 경계할 뿐이죠. 최근 소스포지에서 자바 프로젝트의 수가 C를 넘어서서 C++ 다음으로 2위, freshmeat에서는 C 다음으로 2위입니다. 아파치 프로젝트에는 자바 전문인 자카르타 프로젝트에서 많은 프로젝트들이 아파치 메인으로 올라올 정도로 영향력을 발휘하고 있고 그 외에도 현업과 연계되어 돌아가는 오픈소스 공동체가 많습니다.
솔직히 전 RSM의 문제 제기 자체도 지나치게 독선적이라고 봅니다. 오픈소스는 비오픈소스와의 공존에도 오픈되어 있어야합니다. 실제 JVM의 이용에 별 문제가 없는 상태에서 굳이 오픈소스 JVM을 찾아야할 필요가 있을까요.
이 얘기 벌써 몇달전에 KLDP에서도 끝난 얘긴데...non-free 프로그램은 GPL 버전의 MySQL에 접근 못하게 돼있습니다. 의심스러우시면 MySQL 사이트에 가서 라이선싱 정책을 읽어보세요.
끝나긴 뭐가 끝난 얘깁니까. 얼마 전 있었던 MySQL 토론에서도 갑론 을박이 난무했었는데.. 그리고 MySQL 사이트의 라이센스 정책은 이미 충분히 읽어봤습니다. 하지만 그건 라이센스에 대한 MySQL 측의 "입장"인 것이지 그것이 GPL에 대한 해석은 아니죠. GPL 위반 여부를 가리려면 GPL 조항이 우선인 것은 당연하지 않습니까?
저도 당시 토론에 관심이 많았었고 또다른 MySQL총판인 IT브리지에서 제가 다니는 회사에 lisence fee를 요구하기도 했었기때문에 솔깃해지네요.
당시에도 제가 궁금했던것은 MySQL측의 라이센싱 조항을 읽어보면 다들 아시다시피 듀얼 라이센스이기는 한데 commercial lisence조항이 상당히 애매합니다. 그리고 "GPL이 적용될지 commercial lisence가 적용될지에 대한 해석 권한은 MySQL AB가 가진다"라는 내용이 있어서 더더욱 헷갈리게 만들더군요. 결국 자기들 맘대로 하겠다고 만들어놓은 조항이라는 생각도 들고요.
GPL을 위반한 경우 상업 라이센스인지, 상업용도가 아닌 경우 GPL인지 이런 문제가 명확하지가 않습니다. 결국은 법정에서만 판단될 수 있는것일까요?
개인적인 경험을 말한다면 제가 경험했던 개발자들은 대부분 소스만 공개되어 있으면 오픈소스라고 인식했었다고 대답할 수 있습니다. 실제 SI 하는 개발자들은 오픈소스 공동체가 뭐하는 건지 잘 모릅니다. 그냥 단어의 의미를 그대로 받아들일 뿐이죠. 개발자 커뮤니티라는 것은 이미 오픈소스 공동체의 영향을 많이 받는 상태니까 그들의 정의로 사용할 수도 있겠지만 현업에서 당장 학원 6개월 다니고 들어온 개발자들이 그런 정의를 알 꺼라고 생각하십니까? 그렇다고 그들이 지식이 모자라서 착각한다고 쉽사리 말할 수 없는 것이 원래 오픈소스의 말뜻이 소스 공개의 의미이기 때문입니다.
일반명사와 혼동할 여지가 많은 고유명사의 맥락적 의미를 결정하는 것은 매우 지루한 일입니다. 하지만 이곳은 개발자 커뮤니티고, 지금 이 쓰레드는 적어도 '오픈소스' 세계에서 일어나는 어떤 사건에 대한 의견들이 주를 이루고 있습니다. 여기서 굳이 학원 6개월 마친 사람을 비하하는 듯한 어조로, 새삼스럽게 오픈소스가 다 뭐냐, 그냥 소스 오픈되면 오픈소스 아니냐는 식으로 말하는 건 좀 당황스럽군요. SCSL도 오픈소스고, 마이크로소프트 Shared License도 오픈소스고, 제로보드도 오픈소스군요. 이렇게 '오픈소스'를 남발하는 것이 좀더 주의 깊게 사용할 필요가 있다는 것과 비교해 어떤 점이 좋나요?
creativeidle wrote:
그리고 이것은 오픈소스라는 용어의 위험성이라기보다 라이센스에 대한 부주의에서 오는 위험이겠지요. 오픈소스의 OSI식 정의를 알더라도 GPL에 대해 잘 모르면 위험한 일은 얼마든지 발생할 수 있습니다. 기본적으로 개발자가 라이센스에 얼마나 신경을 쓰느냐의 문제지 용어에 대한 혼동의 문제는 아니라고 봅니다.
라이센스가 가진 특유의 제한사항을 완전히 숙지하지 못함으로 인해 발생하는 미묘한 위반사항들도 분명히 있을 겁니다. 아니, 이런 일이 굉장히 많을 겁니다. '오픈소스'라는 말을 주의 깊게 사용하는 것이 이런 위험을 구하지는 못할 것입니다. 하지만 '몰상식'한 위반사항들은 구제할 수 있을 겁니다. 사실 OSI의 오픈소스 정의가 주는 이점은, 기존에 있던 다양한 종류의 라이센스들에서 공통 분모를 추출하여, 혼란을 덜어주었다는 점입니다. OSI가 말하는 '오픈소스' 정의를 알고 어떤 라이센스가 OSI와 호환되는지 여부를 알면, 그 라이센스가 갖는 기본적인 제한사항들을 몰라도 사용하는 데 별 지장이 없다는 것이 주는 이점은, '오픈소스'의 일반적 용법을 제한하는 것과 비교했을 때 충분히 이롭다고 생각합니다.
이 얘기 벌써 몇달전에 KLDP에서도 끝난 얘긴데...non-free 프로그램은 GPL 버전의 MySQL에 접근 못하게 돼있습니다. 의심스러우시면 MySQL 사이트에 가서 라이선싱 정책을 읽어보세요.
끝나긴 뭐가 끝난 얘깁니까. 얼마 전 있었던 MySQL 토론에서도 갑론 을박이 난무했었는데.. 그리고 MySQL 사이트의 라이센스 정책은 이미 충분히 읽어봤습니다. 하지만 그건 라이센스에 대한 MySQL 측의 "입장"인 것이지 그것이 GPL에 대한 해석은 아니죠. GPL 위반 여부를 가리려면 GPL 조항이 우선인 것은 당연하지 않습니까?
저도 당시 토론에 관심이 많았었고 또다른 MySQL총판인 IT브리지에서 제가 다니는 회사에 lisence fee를 요구하기도 했었기때문에 솔깃해지네요.
당시에도 제가 궁금했던것은 MySQL측의 라이센싱 조항을 읽어보면 다들 아시다시피 듀얼 라이센스이기는 한데 commercial lisence조항이 상당히 애매합니다. 그리고 "GPL이 적용될지 commercial lisence가 적용될지에 대한 해석 권한은 MySQL AB가 가진다"라는 내용이 있어서 더더욱 헷갈리게 만들더군요. 결국 자기들 맘대로 하겠다고 만들어놓은 조항이라는 생각도 들고요.
GPL을 위반한 경우 상업 라이센스인지, 상업용도가 아닌 경우 GPL인지 이런 문제가 명확하지가 않습니다. 결국은 법정에서만 판단될 수 있는것일까요?
법적으로 애매하다 싶으면 저작권자한테 직접 물어보고 판단하면 될 일이겠지요? 근데 보니까 저작권자가 뭐라하든 상관없고 제맘대로 하겠다고 억지를 부리는 분이 간혹 있더군요. 억지를 부리다 고소를 당하던 벌금을 물던 저두 상관은 없지만요.
위에 보면 FSF와 GPL 사용자에게 MySQL이나 QT같은 듀얼 라이센싱 업체가 무슨 기여를 했느냐라는 의견이 있는데, 듀얼 라이센싱은 MySQL이나 QT를 GPL 프로그램에 사용할 때 그냥 사용할 수 있으므로 물론 기여한 것이 확실하고 GPL 개발자에게도 도움이 됩니다. 이건 인정하실테니 여기에 대해서는 더 이야기하지 말지요.
듀얼 라이센싱 프로그램을 독점 프로그램과 연결해서 사용할 때의 문제는 이 쓰레드에서는 이번에 새로 나온 별도의 논의지 위에서 나온 '자유 소프트웨어 진영과 GPL 사용자에게 기여한 바가 없다' 라는 논의와는 연관이 없다는 것을 한 번 짚고 넘어갑니다.
----------------------------
May the F/OSS be with you..
대체 님의 주장의 요지는 뭡니까? MySQL GPL 버전을 비공개 프로그램과 링크해도 된단 얘깁니까 안된단 얘깁니까? MySQL측은 GPL 버전을 비공개 프로그램과 링크하지 말라고 요구하는데 대체 뭐가 잘못됐습니까?
네, 잘못되었습니다. 자기네 라이센스가 GPL이라고 주장하면서 GPL 위반이 아닌 걸 두고 GPL 위반이라고 한다면 말이죠. 링크가 뭘 의도하고 한 말인지는 모르겠으나 앞서 나왔던 MySQL을 같이 배포하는 행위는 분명 GPL 위반이 아닙니다.
비공개 프로그램을 프론트엔드로 쓰고 백엔드로 MySQL GPL 버전을 쓰면 위반이란 얘깁니다. 이게 그렇게 이해가 안됩니까?
Quote:
Quote:
법적으로 애매하다 싶으면 저작권자한테 직접 물어보고 판단하면 될 일이겠지요? 근데 보니까 저작권자가 뭐라하든 상관없고 제맘대로 하겠다고 억지를 부리는 분이 간혹 있더군요. 억지를 부리다 고소를 당하던 벌금을 물던 저두 상관은 없지만요.
저작권자가 GPL로 하겠다고 해서 GPL 지키겠다는데 그것도 문제란 건가요? GPL만 잘 모르는 게 아니라 법도 잘 모르는 것 같군요.
님같은 분이 엉뚱하게 딴지를 걸어오니까 MySQL에서 원래 LGPL이었던 걸 GPL로 바꿔버리고 일부러 토까지 달아놨는데도 그건 싹 무시하고 "저작권자가 GPL로 하겠다"고 했으니 나도 그렇게 하겠다고요? 아주 좋아요. 그렇게 해서 열심히 써보세요. MySQL 국내 총판에서 연락오면 걍 씹어버리면 되겠군요. 그담엔 거액의 벌금과 사장 구속... :P
비공개 프로그램을 프론트엔드로 쓰고 백엔드로 MySQL GPL 버전을 쓰면 위반이란 얘깁니다. 이게 그렇게 이해가 안됩니까?
풉, 언제 그렇게 얘기했었는데요? 그걸 보통 링크라고 표현하나요-_-? 그리고 그래도 여전히 GPL 위반이라는 증거는 안되는데요.
Quote:
님같은 분이 엉뚱하게 딴지를 걸어오니까 MySQL에서 원래 LGPL이었던 걸 GPL로 바꿔버리고 일부러 토까지 달아놨는데도 그건 싹 무시하고 "저작권자가 GPL로 하겠다"고 했으니 나도 그렇게 하겠다고요? 아주 좋아요. 그렇게 해서 열심히 써보세요. MySQL 국내 총판에서 연락오면 걍 씹어버리면 되겠군요. 그담엔 거액의 벌금과 사장 구속... Razz
머, 무식해서 손해보고 살겠다는 사람은 말릴 생각이 없습니다. 그렇게 꼬박꼬박 안내도 되는 돈 갖다 바치면서 사세요. GPL도 모르고 법도 모르는데다 상식까지 부족하니 손해보면서 살 수 밖에..
하여간 손님들의 강짜는 어쩔 수가 없는가보군요. 뭐가 무서워서 저렇게 익명으로 할까나.. ㅋㅋ
비공개 프로그램을 프론트엔드로 쓰고 백엔드로 MySQL GPL 버전을 쓰면 위반이란 얘깁니다. 이게 그렇게 이해가 안됩니까?
풉, 언제 그렇게 얘기했었는데요? 그걸 보통 링크라고 표현하나요-_-? 그리고 그래도 여전히 GPL 위반이라는 증거는 안되는데요.
Quote:
님같은 분이 엉뚱하게 딴지를 걸어오니까 MySQL에서 원래 LGPL이었던 걸 GPL로 바꿔버리고 일부러 토까지 달아놨는데도 그건 싹 무시하고 "저작권자가 GPL로 하겠다"고 했으니 나도 그렇게 하겠다고요? 아주 좋아요. 그렇게 해서 열심히 써보세요. MySQL 국내 총판에서 연락오면 걍 씹어버리면 되겠군요. 그담엔 거액의 벌금과 사장 구속... Razz
머, 무식해서 손해보고 살겠다는 사람은 말릴 생각이 없습니다. 그렇게 꼬박꼬박 안내도 되는 돈 갖다 바치면서 사세요. GPL도 모르고 법도 모르는데다 상식까지 부족하니 손해보면서 살 수 밖에..
하여간 손님들의 강짜는 어쩔 수가 없는가보군요. 뭐가 무서워서 저렇게 익명으로 할까나.. ㅋㅋ
ㅋㅋㅋ 전세계 수만개 기업들이 전부 무식해서 일부러 MySQL에다 돈내고 라이선스 사서 쓰겠습니까?? 제발 좀 상식적으로 생각을 해보세요 네?? 그건 그렇고 MySQL 회사도 님같이 억지부리는 사람들때문에 정말 피곤하겠군요. 왜 LGPL에서 GPL로 바껐는지 이해가 됩니다.
글구 손님 모드는 여기 관리자이신 권순선님의 정책에 따라 운영되는 건데 왜케 딴지 거는 사람이 많은 건지 모르겠네여?? 정 불편하면 손님이라고 이름써진 사람은 전부 한사람이다~ 이렇게 생각하세요 네??
ㅋㅋㅋ 전세계 수만개 기업들이 전부 무식해서 일부러 MySQL에다 돈내고 라이선스 사서 쓰겠습니까?? 제발 좀 상식적으로 생각을 해보세요 네?? 그건 그렇고 MySQL 회사도 님같이 억지부리는 사람들때문에 정말 피곤하겠군요. 왜 LGPL에서 GPL로 바껐는지 이해가 됩니다.
그리고 또 전세계 수만 개의 기업이 돈 안 내고 잘 쓰고 있죠.
Quote:
글구 손님 모드는 여기 관리자이신 권순선님의 정책에 따라 운영되는 건데 왜케 딴지 거는 사람이 많은 건지 모르겠네여?
GPL 소프트웨어를 독점 시스템 안에 통합시키고 싶습니다. 가능합니까?
GPL 소프트웨어는 독점 시스템 안에 통합될 수 없습니다. GPL의 목적은 모든 사람들에게 프로그램에 대한 학습과 개작, 복제와 재배포의 자유를 부여하기 위한 것입니다. 만약 GPL 프로그램을 자유 소프트웨어 시스템이 아닌 곳에 통합시킨다면, 그것은 GPL 소프트웨어를 자유 소프트웨어가 아닌 것으로 만드는 결과가 됩니다.
GPL 프로그램이 통합된 시스템은, GPL 프로그램이 확장된 것이라고 할 수 있습니다. GPL은 GPL 프로그램을 확장한 버전을 공표할 때 그 라이선스로 GPL을 사용해야 한다고 규정하고 있습니다. 여기에는 두가지 이유가 있습니다. 첫번째는 소프트웨어를 취득한 사용자로 하여금 그들이 가질 수 있는 자유를 알게 하려는 것이고, 두번째는 그들이 만든 개선점들을 공동체로 환원하도록 격려하기 위한 것입니다.
GPL 소프트웨어가 독점 시스템에 통합된 형태인지 아니면 서로 독립적으로 작동하는 형태인지에 대한 구별은 실제적인 측면과 형식적인 측면으로 구분해서 생각해 볼 수 있습니다. 실제적인 측면에서 볼 때, 두개의 프로그램이 하나의 프로그램을 구성하는 두개의 부분으로 기능하면서 결합되는 경우에는, 두개의 프로그램을 별도의 프로그램으로 취급할 수 없기 때문에 프로그램 모두가 GPL로 취급되어야 합니다. 만약 두개의 프로그램이 커널과 컴파일러(또는 쉘, 에디터)의 경우과 같이 분리된 상태를 유지하면서 원래의 기능을 충분히 수행할 수 있다면 각각의 프로그램들을 별도의 프로그램으로 취급할 수 있습니다.
ㅋㅋㅋ 전세계 수만개 기업들이 전부 무식해서 일부러 MySQL에다 돈내고 라이선스 사서 쓰겠습니까?? 제발 좀 상식적으로 생각을 해보세요 네?? 그건 그렇고 MySQL 회사도 님같이 억지부리는 사람들때문에 정말 피곤하겠군요. 왜 LGPL에서 GPL로 바껐는지 이해가 됩니다.
그리고 또 전세계 수만 개의 기업이 돈 안 내고 잘 쓰고 있죠.
Quote:
글구 손님 모드는 여기 관리자이신 권순선님의 정책에 따라 운영되는 건데 왜케 딴지 거는 사람이 많은 건지 모르겠네여?
정말 모릅니까? 손님들은 대체로 님처럼 글을 쓰기 때문이죠. 정말 몰랐다니-_-
쉽게 말하자면 MySQL Driver를 독자적으로 개발해서 사용한다면 상용 제품이 MySQL을 Back-End로 사용하는 것도 가능합니다.
다시말하면 Comercial Product -> MySQL Driver -> MySQL DB 로 의존성을 가지는데, 이중에 MySQL DB는 앞서 올린 GPL에 따라 사용하는 방법에 따라 상업제품에도 포함시킬수 있습니다. 그러나 문제는 MySQL Driver 역시 GPL로 라이센스 되고 있으며 만약 이 MySQL Driver를 사용한다면 Comercial Product 역시 GPL이 되어야 합니다.
그런데 대부분의 상용 제품은 코드 공개를 원하지 않기 때문에 GPL을 따르지 않으려 하고 그러기 위해서는 MySQL 회사에게 상용으로 공개하지 않아도 되는 MySQL Driver를 라이센스 해서 사용해야 합니다.
아니라면 MySQL Driver를 완전히 독자적으로 구현 하면 MySQL DB를 상용제품에 포함시킬수도 있지요.
만약 제작하시는 제품이 오픈소스이고 GPL로 라이센스 하시려면 얼마든지 MySQL 사용하셔도 좋습니다.
윈 분 말씀에 거의 동의하는데 한 가지 추가해야할 것은 웹 솔루션 계약이 대체로 소스까지를 포함한다는 것입니다. 특히 MySQL이 들어가는 것은 PHP가 많은데 이건 소스가 그냥 다 포함되죠. 그래서 GPL 하에서 얼마든지 판매 가능합니다. 자바도 SI의 경우는 소스 포함 계약이 대다수입니다.
그리고 MySQL JDBC 드라이버를 자체 제작해서 쓰는 곳도 있답니다. 3.23대 버전까지가 LGPL이기 때문에 그걸 기반으로 4.0대에 맞게 수정해서 쓰고 있죠. 그 회사에서 그 버전을 공개도 하려고 했는데 MySQL과의 마찰을 우려해서 공개하지 않았다고 하더군요.
기사가 Sun JRE, JDK의 open source화의 문제인지 Jav
기사가 Sun JRE, JDK의 open source화의 문제인지 Java사용에 대한 문제인지는 잘 모르겠네요.
아무튼 자바는 여러가지 오픈소스 구현이 있기는 하지만, 아직은 써먹을만한 구현은 없다고 생각합니다. 아시겠지만, j2se 5를 apache에서 해보자는 제안이 apache incubator에 list에 올라온것 같습니다.
http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/%3CCA4BEB82-3D84-457D-9531-1477DD749919@apache.org%3E
결정된것은 아니지만, 적어도 서버사이드에서 만큼은 쓸만한 엔진이 나올것으로 기대됩니다.
--
Life is short. damn short...
글쎄요. 기사를 보면 오픈 오피스를 gcj로 컴파일 할 때 문제가 생기는
글쎄요. 기사를 보면 오픈 오피스를 gcj로 컴파일 할 때 문제가 생기는 부분을 지적하고 있는 것 같은데 아무래도 이번 경우 역시 RMS가 조금 지나치지 않나 싶습니다. 같은 논리라면 맥 오에스텐용 오픈 소스 프로젝트도 장려하지 않는 것이 맞습니다. (개인적으로 왜 RMS가 이 부분은 건드리지 않는지 궁금합니다.) 맥용 데스크탑 어플은 맥 오에스텐이 유닉스인데도 불구하고 리눅스나 다른 유닉스 계열 운영체제로 포팅이 기본적으로 불가능하니까요.
이 문제는 전체적으로 오픈오피스 개발자들의 의견을 존중하는 것이 좋다고 봅니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
RMS는 제임스 고슬링과 사이가 안좋죠.http://network.h
RMS는 제임스 고슬링과 사이가 안좋죠.
http://network.hanbitbook.co.kr/view.php?bi_id=906
RMS 때문에 소프트웨어 개발자들이 자바라는 또다른 가능성을 폄하하고 무시하는것 같아서 좀 서운한 감도 듭니다.
[quote="Anonymous"]RMS는 제임스 고슬링과 사이가 안
서로가 사이가 안좋은 것은, 고슬링이 자신소유의 지적재산(자바 JAVA 등등)으로 돈을 버는데 스톨만씨가 방해가 된다고 생각하기 때문이 아닐까요 ?
[quote="Anonymous"][quote="Anonymous"]
제임스 고슬링은 IT업계에서 세계적인 독점적 권력을 행사하는 Microsoft의 빌게이츠에 대해서는 비겁한 폄하와
직접적인 공격을 가하면서도, 정작 자신은 JAVA에 대해서 개발환경뿐만아니라 OS 및 하드웨어분야(Net PC 혹은 JAVA Machine) 등의 IT의 거의 모든 영역에서 독점적인 위치를 차지하기를 간절히 바라고 있죠. 내심은 정작 빌게이츠처럼 되기를 바면서도 그에 대한 질투랄까.
내심(內心)에 도사리고 있는 kewword는 "돈(Big Money)"과 "명예욕"이겠지요.
( 결국 길고 짧아보아야 똑같은 인간들인데 :lol: )
:lol:
[quote="Anonymous"]내심(內心)에 도사리고 있는 kew
Keyword :lol: :lol: :lol:
:!:
?? 착각이..
Java는 Sun의 지적재산입니다.
제임스 고슬링꺼는 아닌데요.. 그리고 스톨만과의 유명한 불화는 "지적재산으로 돈을 벌수 있다"를 인정하느냐 않하느냐의 차이로 발생한거조. Emac때도 그랬고요. 스톨만같은 "모든 정보를 공개하고 공유하자"라는 사람은 누구하고도 싸움이 일어납니다. 뭐 해커들이야 스톨만을 지지하지만, 먹고 사는 일이 걸리는 대부분의 프로그래머들에게는 별로 받아들이기 어려운 일이기도 합니다. (심정적으로야 저도 지지합니다만...)
아무튼 그것때문에 스톨만이 고슬링을 비난하는데 사람들이 이걸 일방적으로 받아들이는 것도 문제입니다.
그리고 자바는 이미 오픈소스입니다만...
Community License로 소스코드를 받아 볼수 있고, Class 소스는 아예 JDK에 포함되어 나옵니다. 꽤나 오래전부터 그랬죠.
Java Virtual Machine 스펙이나 Java Language Spec이나 모두 공개되어 있고요.
Re: ?? 착각이..
이 부분이 많이 궁금한데 부연설명 좀 부탁드려도 될까요? 그리고 예를 들어
썬의 자바 소스 코드를 다른 프로젝트에 copy & paste로 가져다 쓰는 것이
가능한지, 만일 가능하다면 어떤 조건이 따라 붙는지 궁금합니다.
상용 솔루션들도 API 스펙은 당연히 공개하니 이 부분은 그다지 중요하지
않을 듯 싶습니다. 어쨌거나, 스펙이 공개되어 있으면 스펙을 독자적으로
구현한 다른 클론들이 나올 수 있어서 좋기는 합니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
Re: ?? 착각이..
오픈되어있는 것은 맞습니다만 그걸 가지고는 아무것도 못하도록 되어있습니다.
소스를 볼 수만 있을 뿐 소스를 수정한다거나 혹은 다른 프로그램을 개발하는데
이용한다거나 하는 것은 불가능하도록 되어있습니다.
예를 들어 java 에 들어있는 gc 구현을 보고 다른 언어(python 같은)
의 gc 알고리즘(혹은 구현)을 그렇게 수정하는 것은 라이센스 위반이 됩니다.
저도 정확히 아는 것은 아니기 때문에 제가 쓴 내용이 틀렸을 수도 있습니다.
Re: ?? 착각이..
Sun의 대주주 및 CEO는 고슬링이기 때문에, Sun은 결국 고슬링꺼고, 결국 자바는 고슬링꺼지요! (고슬링이 SUN의 주식을 전부 다른사람에게 매각하지 않는 한, JAVA는 고슬링 소유의 재산입니다.주식회사에 대해서 공부해 보시길...)
맞습니다. JAVA가 Open Source(오픈소스)이고, GNU Free Software(프리소프트웨어) 라이센스가 아니기 때문에, 소스에 대한 어떠한 자유(Freedom)가 없으며, 아랫분의 말씀대로, 그것을 가지고 어떤 일도 할 수가 없습니다.
자바가 IT시장을 자바먹을 수 있을까 ?
JAVA는 오픈소스에 불과하기 때문에, 그 Source Code로 어떤 것도 할 수가 없으며 따라서 "빛 좋은 게살구"에 불과하며, 자신들의 이익을 위하여 공동체를 이용하는 꼴이 되고 있어서, 결국 그것은 "손바닥으로 하늘을 가리는 격"이 되어, 공동체로부터 전폭적인 지지를 받지 못하고 있고, 그 귀결로서 고슬링이 예상한 것 보다 독점적 시장점유율을 차지하지는 못하고 있습니다.
Re: ?? 착각이..
고슬링이 언제 CEO가 되었죠?... 주식도 한 51% 가지고 있습니까? :(
그는 그저 간판일 뿐이고, 엄청난 돈도, 해커들의 명예도 엊지 못해서 늘 불만인듯 싶네요.
--
Life is short. damn short...
첫번째 손님인데요.다른 손님들이 지적한 부분이 실제와 약간 어긋나는것
첫번째 손님인데요.
다른 손님들이 지적한 부분이 실제와 약간 어긋나는것 같네요.
두번째 손님이 지적하신 부분, "고슬링이 자신소유의 지적재산(자바 JAVA 등등)으로 돈을 버는데 스톨만씨가 방해가 된다고 생각하기 때문이 아닐까요 ?" 는 약간 틀립니다.
결과적으로 자바로 가장 많은 돈을 버는 업체는 Sun이 아니라 IBM입니다. IBM이 없었다면 자바는 Sun 내부 프로젝트로 종말을 고했을겁니다.
썬 홈페이지의 J2EE는 무료 배포되지만 상업용으로 사용하지 못하도록 묶여있습니다. J2EE를 상업적으로 올리려면 웹스피어, 웹로직, 썬 자바시스템 등 J2EE를 구현한 상용제품을 이용해야만 합니다. 업계에서는 웹스피어, 웹로직을 많이 사용하니 썬이 버는 돈은 별로 없지요.
그러므로 다른 손님의 "Sun의 대주주 및 CEO는 고슬링이기 때문에, Sun은 결국 고슬링꺼고, 결국 자바는 고슬링꺼지요"라는 말도 맞다고 보기는 어렵습니다. 언급하신대로 주식회사 식으로 따지자면, 제임스 고슬링이 썬에 가지고 있는 지분율만큼 자바에 대한 권리를 가진다고 볼 수 있지요. 고슬링이 얼마만큼의 지분을 가지고 있는지는 모르겠지만 50%는 안넘으니 자바에 대한 고슬링의 재산권은 50% 미만이라 볼 수 있겠네요. 50% 미만 소유하고 있는게 독점적이라 할 수 있는건지 의문입니다만.. (그러므로 주식회사식 논거는 틀렸습니다.)
자바 스펙을 결정하는 JCP에서 입김이 가장 센건 썬이 아니라 IBM입니다. IBM에서 제안한 내역의 대부분이 J2EE에 들어갔습니다. 자바라는 상표와 껍데기만 썬 것이지요.
Java라는 이름과 껍데기를 소유한 죄로 소송은 썬이 다 합니다만 실 이익은 IBM이 모조리 챙겨가고 있죠. 소송 같은 귀찮고 복잡한건 모두 썬으로 떠넘긴 IBM이 대단하죠.
"소스를 볼 수만 있을뿐 수정할 수 없다"는 부분은 JVM 스펙과 구현체는 다르다라는 관점에서 이해하셔야 할것입니다.
스펙은 공개되어 있으므로 누구나 스펙에 맞춰 제작할 수 있습니다. gcj도 이 스펙을 참조해서 개발합니다.
구현체는 스펙과 다릅니다. 스펙이 스펙으로 끝나지 않도록 코딩한 작업물이지요. JMS는 이 구현체까지도 오픈소스로 풀기를 바라는 모양입니다만.. 그렇게 된다면 Sun java뿐만 아니라 IBM, apple 등 다른 업체도 다 공개해야겠지요. 이쯤 하면 썬만 잡아 족칠 문제는 아닙니다.
자바는 리눅스 공동체로부터 전폭적 지지는 못받을지 몰라도
기업 비지니스 환경에서는 전폭적 지지를 받고 있으며 상당한 독점적 영향을 행사하고 있습니다.
Re: ?? 착각이..
제임스 고슬링이 언제 썬의 CEO가 됐나요? 4월 29일까지는 스콧 맥닐리가 썬 CEO였는데 며칠전에 제임스 고슬링으로 바꼈나요? 근데 왜 바꼈다는 소식은 세계 어느 뉴스에도 안나온 거지...
썬이...
썬이 자바로 이름값은 하고 있을 지는 몰라도..
썬은 자바회사는 아닙니다.
서버 전문이죠. 그나사 서버도 잘 안팔린다는 소리가 있긴 한데요..
자바가 썬이라는 든든한 백이 있기때문에 아이비엠과 다른 회사에서도 전폭적으로 지지를 할 수 있다고 봅니다.
만약 자바가 그냥 단순이 오픈소스였다면 지금 이정도로 엄청난 발전은 없었을 것입니다.
썬은 자바로 여러가지 이득도 보지만. 윗분 말씀하신대로 아이비엠등의 회사에 비하면 이름만 갖고 있는 것으로 볼 수 있죠.
주제로 돌아와서
제임스 고슬링은 자바를 만든 장본인이지만. CEO는 스캇 맥닐리가 맞죠. 고슬링이 회사에 얼마나 중요한 인물인지는 모르겠습니다. 아직은 필요한 사람이니까 붙어있는것이겠죠. 요즘엔 더 심해진게 사실이지만. 회사들은 살아남기 바쁘기 때문에 필요한 사람은 남아있지만. 필요없으면 바로 떨어져 나가게 됩니다.
지금은 그나마 썬이 자바 관리를 잘 해서 붙들고 있지만. 관리 못하면 다른 곳에 뺏길수도 있죠. 아이비엠 같은곳으로여..
아무튼 제가 알기론 제임스 고슬링이 그렇게 힘이 많다고 생각지는 않습니다.
리차드 스톨만은 참 신기한 사람인거 같은데 그사람 주장대로 모든 소스를 공개하고 그러면 먹구살 사람이 몇이나 있을까요?
개인적인 생각으론 스톨만씨의 GPL보다는 썬의 라이센스가 더 맘에 듭니다. (둘만 비교했을때여)
세상이너무 이익위주로 돌아가는 거 같아서 참 안타깝습니다. 스톨만 생각이 맞는지 썬 생각이 맞는지 정말 모르겠는데여. 아이비엠이 돈 버는건 확실한거 같습니다. ^^
열정!! ^^
Re: ?? 착각이..
맞네요. 그럼 자바는 현재 스콧의 개인 소유 지적재산이겠네요...~
첨언하자면...
잘 읽었습니다... 그리고 저도 같은 생각입니다....
흔히들 자바때문에 썬이 공격받기는 하지만 실상은 변변한 떡고물
조차 먹지 못하고 있죠....
정작 자바로 돈 번 곳은 아범, bea, 오라클이라고 볼 수있습니다...
(그런데 아범의 경우 또다른 관점에서 보면 돈을 벌만한 자격을
갖추고 있습니다. 과장해서 말하자면 이 자바때문에 아범이 일어
설 수있다고 봐도 되거든요.. )
Re: 썬이...
GPL License를 채택하고 있는, QT의 트롤테크(Trolltech)사나 PHP의 Zend Technologies사 등등이
공동체의 후광을 등에 업고 잘먹고 잘살고 있지 않나요?
왜 잘 못먹고 살거라는 편견과 선입견을 아직도 가지고 있나요 ?
:idea:
Re: 썬이...
글쎄요... 요즘 썬은 자바를 빼놓고 나면 거의 시체(?)나 다름없지
않나요? 썬이 서버로 장사하던 얘기는 이미 오래전 스토리로
알고 있습니다.
글쎄요. 오히려 썬이 자바를 말아먹은 자충수를 기억해본다면 아이비엠과
같은 회사들이 썬이라는 빽을 보고 자바를 지원하지는 않았을 것이라는
추측을 해 볼 수 있습니다.
단적인 예가 자바 애플릿입니다. 썬은 자바가 초반에 웹브라우저 내의
애플릿으로 각광받고 있을때 썬의 JVM 소스 코드 및 수정, 재배포 권한
까지 MS에 팔았습니다. 그 결과는 MS가 인터넷 익스플로러 내부의
JVM의 스펙을 썬이 아닌 MS가 결정할 수 있게 해 주었고 결과적으로
MS가 인터넷 익스플로러의 배포권을 이용해서 자바의 발전을 견제할
수 있게 해 주었습니다. 그 부작용의 하나가 다들 잘 아시다시피
액티브 엑스의 출현입니다. 뒤늦게 자신의 자충수를 깨달은 썬이
엠에스를 제소했지만 뭐... MS에서는 JVM을 완전히 윈도우즈에서
제거시키는 방법으로 응수해버렸습니다.
그나마 자바가 서버 쪽에서 살아남은 것은 썬이 잘해서가 아니라
오픈 소스 개발자들이 달라붙어 자바로 서버 사이드 솔루션들을 계속
만들어 왔기 때문입니다.
오히려 아이비엠 같은 곳에서 자바의 미래를 전담해 주는 것이 자바의
미래를 위해서는 나은 결정이 될겁니다. :)
구체적으로 어떤 얘기인지는 좀 더 들어봐야하겠습니다만 RMS만큼 사람들이
잘못 이해하고 있는 경우도 드문 것 같습니다. GPL은 이윤동기를 부정하는
것이 아닙니다. GPL이 확실히 보장해 주는 것은 다른 개발자들이 소스코드를
자유롭게 볼 수 있는 권한을 부여해 주는 것입니다.
RMS가 유별난 점은 RMS는 장기적으로 모든 소프트웨어의 소스 코드는
공개되어야 한다고 주장하는 점입니다. 그의 주장에도 일리가 있는 것이
현재는 소스 코드가 비공개인 상용 라이센스와 소스 코드 공개가 의무인
GPL 양 자 사이에서 개발자들이 필요에 따라서 선택을 할 수 있지만
만약 GPL만이 사용할 수 있는 유일한 라이센스라고 한다면 모든
derivative work의 소스코드가 공개될 것이기 때문이 내 소스 코드를
공개하는 것이 소스 코드 뒤에 숨어 있는 나의 아이디어의 도용으로
이어지지 않습니다. 하지만 현실에서 소스코드의 공개는 강제할 수 있지만
아이디어을 베낀 뒤 새로운 제품을 만들고 이것을 closed source로 해서
derivative idea의 노출을 막는 것은 항상 가능하지요. 또 이를 뒷받침
해 줄 수 있는 것이 상용 라이센스이구요.
이렇다면 RMS의 말대로 모든 소프트웨어가 GPL을 따르는 것이
좋은 일이 될 수 있는 겁니다. 비록 현실적으로 실현 과정이 불가능에
가깝지만 이런 상황을 한번 가정을 해 보는 것 만으로도 상당한
의의가 있다고 봅니다. 어쨌거나, 중요한 점은 RMS가 유별나기는
하지만 GPL은 절대 이윤동기를 부정하지 않습니다. 오히려 GPL은
이윤동기를 장려하는 입장입니다.
현재 상황으로는 IBM이 돈을 더 많이 벌어서 자바를 썬의 영향력 아래에서
뺏어올 필요가 있지 않나 싶습니다. 하지만 요즘 IBM도 실적이 그다지
좋지는 못하더군요.
썬의 자바를보면서 개인적으로 아쉬운 점은 자바는 충분히 차세대 개발플랫폼을
MS의 윈도우즈가 아닌 한 단계 차원 높은 새로운 플랫폼으로
옮겨올 수 있는 잠재력이 충분했었습니다만 결과적으로 이 부분에서
실패를 한 셈입니다. 자바의 경쟁자로 이름이 자자하던 닷넷 플랫폼은
아직까지 많이 쓰이려면 시간이 한참 더 걸려야 하는 상황입니다.
어차피 윈도우즈 차세대 버전 롱혼이 나오면 자바가 번들될 수 없는
상황이 벌어질 것은 당연한데 여전히 자바에 대한 제어권에 집착하는
썬의 모습은 갑갑한 부분이 많이 있습니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
[url]http://www.fsf.org/news/open-office
http://www.fsf.org/news/open-office-java.html
kbench 기사는 무슨 말을 하는지 모르겠네요.
FC4T4에는 Free Java(GNU Java)를 이용한 OpenOffice-1.9.100 패키지가 포함 되어 있습니다.
Re: 썬이...
이론상으로는 그런데...현실적으로 국내에 GPL 소프트웨어 만들어서 먹고 사는 소프트웨어 업체가 한군데라도 있나요? 왜 현실적으로 GPL의 이윤동기가 전혀 작동이 안되는지 살펴볼 필요가 있을 것 같습니다. 이상에 치우친 이론은 공허할 뿐이죠.
Re: 썬이...
아 정말... 글을 써 놨으면 좀 읽어보고 댓글을 달아 주세요. RMS말대로
따라가자는 게 아니고 RMS의 허황되어 보이는 얘기에도 일고의 가치가 있다는
글을 잔뜩 적어 놓았는데 대뜸 GPL로 먹고 사는 업체가 하나라도 있냐는
동답서문이 올라오면 뭐하자는 겁니까...
국내 업체들이 오픈소스로 먹고 사는 곳이 없다고들 하는데 거꾸로
국내의 다른 상용 개발업체들의 이윤 사정은 어떤지 궁금합니다. 우리나라
업체들이야말로 순수 소프트웨어 개발 자체로는 생존 자체가 어렵지
않나요? 상용 소프트웨어 업체 사정이 이러할진대 GPL로 먹고 사는
국내 업체가 없다는 핑계로 GPL까지 평가절하 하는 것은 성급하죠.
적어도 외국으로만 눈을 돌려 봐도 레드햇과 같은 업체는 이미
GPL을 꾸준히 지키면서도 돈을 벌고 있고 배포본 시장에서만
suse니 mandrake니 여러 업체가 자리를 잡고 있지 않나요?
GPL이외에 선택할 수 있는 다른 상용 라이센스가 있다는 점은 기업들이
경쟁자들에게 이익이 될 수 있는 기술 공개를 꺼려하게 만듭니다. 기술에서
중요한 것은 아이디어이지 소스코드가 아니거든요. 현재는 경쟁사들이
오픈소스 개발사의 소스코드를 보고 아이디어를 습득한 다음 소스코드를
공개하지 않은 채로 더 나은 제품을 개발해서 팔 수 있습니다. 이렇게
되면 원 개발사는 경쟁사의 제품에 어떤 개선된 기술이 구현되었는지를
알 수 없게 되고 따라서 처음부터 기술 공개를 안하는 편이 합리적입니다.
문제는, GPL로 소스 코드 공개를 강제해도 이 부분은 막을 방법이 없습니다.
다만, 라이센스가 GPL만 존재하는 세상이 있다고 가정하면 경쟁사의
기술이 녹아 있는 소스 코드도 항상 공개 되기 때문에 경쟁사의 무임승차
문제가 해결이 될 수도 있다는 것입니다. 덧붙이자면 따라서 기업들이
내부 기술 노출의 위험 때문에 GPL 도입을 꺼리는 것은 사실상 GPL 자체의
문제보다는 GPL과 다른 라이센스가 동시에 존재하기 때문이라고 볼
수 있는 것이지요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
Re: 썬이...
국내 소프트웨어 시장은 패키지쪽은 불법복사때문에 전부 망했지만 아웃소싱쪽은 그냥그냥 먹고살만 합니다. 대신 소스 공개했다간 다음날로 쫄딱 망하거든요. GPL은 남의 나라 얘깁니다.
근데 그런 상황을 잘 모르시는 걸 보니 logout님은 한번도 회사에서 근무해본 적이 없으신 것 같네요. 맞죠? 저도 대학생때는 왜 GPL이 안되는지 의아했는데 회사 생활해보니까 당장 알겠더군요. 학교에만 계시지 말고 회사 생활도 해보시면서 견문을 넓히시길~
오픈소스가 하나도 없다면 사업 접어야할 업체가 얼마나 많은데 그런말씀 하
오픈소스가 하나도 없다면 사업 접어야할 업체가 얼마나 많은데 그런말씀 하시는건 좀..... 당장 아파치만 걷어낸다고 해도...... 간접적인 이득은 제외하신다면이야 할말은 없지만요.
Java 소스코드 수정은 가능합니다만..
SUN이 실제로 내려 놔야 하는 것은 비싼 TCK 입니다.
만약 TCK가 무료가 되거나 부담이 없는 가격이 된다면, 수많은 Open & Free JVM이 등장할 겁니다. 당장 Kaffe나 GCJ등이 TCK에 검증될수 있게 되겠죠
그럼 Java 상호 운영성이 대폭 상승 할 것이고, Embedded 시장에도 새로운 바람을 불러 일으킬수 있죠.
ps. 참고로 1 JVM on 1 OS TCK가 8만달라입니다.
특정 운영체제에서 동작하는 특정 JVM이 TCK를 통과하려면 8만 달라를 내야 합니다. -_-
운영체제가 바뀌면 또 TCK를 통과해야 합니다.
비싸죠.. -_-
풋...아웃소싱 쪽이 Product 로 밥 벌어먹는 동네였던가요..P
풋...아웃소싱 쪽이 Product 로 밥 벌어먹는 동네였던가요..
Product 를 만들어 내기 위해서 아웃소싱을 하더라도(과연..)
Product 가 아닌 다른 쪽으로 밥 벌어먹고 사는 동네죠.
그리고,
GPL 이 국내에서 안 먹히는 이유가 뭔지는 아십니까?
꼭 국내에서는 GPL 이 안 통하는 이유라도 있는것처럼 써 놓으셨지만,
GPL 이 국내에서 안 통하는 이유는 라이센스를 어기는 회사들 때문입니다.
GPL 로 공개된 프로그램 소스 코드 가져다 derived work 를 만들어 놓고는
마치 GPL 로 공개된 소스 가져다 쓰지 않은양 위장하고 상용 라이센스로
제품을 만들어서 팔아 먹으려는 막말로 말하자면 '막되먹은' 회사들 때문이라는 겁니다.
GPL 의 단물만 뽑아먹고, 자신이 공개하긴 싫고, 그런것에만 신경쓰니,
GPL 의 단물만 뽑아먹고, 자신이 공개하긴 싫고, 그런것에만 신경쓰니,
그런회사가 잘 될리가 없죠.
경험한 사회생활이 전부인양 떠드는 것 또한 안되겠죠.
[quote="Anonymous"]풋...아웃소싱 쪽이 Product 로
좀 현실적이 돼 봅시다. 까놓고 얘기해서 지금 GPL 위반해서 먹고사는 회사 부지기수로 많은데 아무도 제재하지 못하는 건 왜 그런가요? GPL은 국내에서는 아무 구속력이 없어요.
이거 아주 이상한 상황이지 않나요. GPL 단물 뽑아먹어서 잘될리가 있냐고 어떤 분이 위에 쓰셨는데, 현실은 GPL로 공개하면 쫄딱 망하고 GPL 도용하면 먹고살만 해지는 정반대 상황이거든요. 뭐 지금까지도 전혀 개선이 안되는 걸로 봐서 앞으로 개선될 가능성은 없는 것 같지만 현실을 자꾸 무시하고 탁상공론만 펼쳐서는 안될 것 같네요.
[quote="Anonymous"]좀 현실적이 돼 봅시다. 까놓고 얘
현실현실 하는데, 예를 조금 들어주시면 감사하겠습니다.
어떤기업이 공개하고 쫄딱 망했고, 어느기업이 도용하고 잘 살고 있는지요.
반박하고자 하는 것이 아니라, 궁금해서 그렇습니다.
RMS의 논리는 프로그램을 중심으로 어디까지 사회가 변할 것인가(얼마나
RMS의 논리는 프로그램을 중심으로 어디까지 사회가 변할 것인가(얼마나 많은 분야에 쓰이게 될 것인가)를 짚어볼 수 없는 시절에 완성되었습니다.
그리고 세상은 그런 그의 논리를 비웃기라도 하듯 엄청난 속도로 발전하면서...주변에서는 이제 GPL의 논리로는 시장 자체가 성립하지 않는 분야도 많습니다.
당시는 기업용 비지니스 프로그램 하청 받아서 제작해주듯 만들어주고 그걸 유지보수한다는 개념이 어느정도 먹혔지만 당장 주변을 둘러보십시오. 유지보수 없이 소모되는 코드도 많습니다. 이렇게 연속성이 요구되지 않는 제품은 아이디어 이전에 코드가 공개되는 것만으로 상업적인 가치가 사라집니다.
그리고 아이디어와 코드를 분리해서 이야기하시는 분들도 있는데...글쎄요? 남의 포크가 자신의 제품을 개량한 것이고, 내가 그 포크의 개량된 코드를 흡수하면 된다고 하지만...그렇다면 마케팅과 자본만이 모든걸 좌우하는 세상이 올 것 같네요.
그건 그렇고 트롤테크가 GPL로 밥벌어먹는다는건 금시초문이군요.
트롤테크는 GPL로 호객을 하고 밥은 다른걸로 벌어먹는걸로 아는데요? :)
제가 생각하기에는 이걸 GPL의 석세스 케이스로 언급하는건 자유소프트 정신을 망각한 행위 같네요.
[quote="firefox"]현실현실 하는데, 예를 조금 들어주시면
저한테 물어볼 정도로 현실을 모르신다면 안다고 해도 달라지는 건 없을 겁니다. 이 바닥에서 회사 생활 몇달만 해보면 저절로 다 알게 됩니다.
힌트 하나 드릴까요? 상용 웹솔루션 공급할때 MySQL 끼워넣는 업체 전부다 GPL 위반입니다. 주변에 여러군데 알고 있는데, 여기다 이름 올려봐야 서로 좋을 일 없을 테니 밝히지는 않겠습니다. 단지 현실은 그렇다는 겁니다.
[quote="Anonymous"]트롤테크는 GPL로 호객을 하고 밥
다른걸로 벌어먹는지는 제가 트롤테크 재무구조를 몰라서 뭐라 말할건 없지만, GPL의 석세스케이스로 언급하는게 자유소프트웨어 정신을 망각하는 이유가 뭔가요?
GPL을 이용하여 나온 이득을 상업적으로 이용해서?
자유소프트웨어라는게 상업용소프트웨어를 부정하는건가요?
그럼 위의 예로들은 레드햇, 수세, mysql AB 등도 마찬가지인가요? zend사는? php는 GPL이 아니라서 derived work를 하더라도 소스공개를 안해도 괜찮다고요? 그럼 GPL자체를 자유소프트웨어에서 부정하시는겁니까?
[quote="ddoman"][quote="Anonymous"]트롤테
위에 손님이 말씀하신 건 트롤텍이 GPL 쓰는 건 손님 끌어모으려는 홍보 수단이고, 실제로는 상용 라이선스 판매해서 돈번단 얘깁니다. 뭐 듀얼 라이선싱 제공하는 업체들이 전부 그런 스타일이죠. 결국에 외국도 순수 GPL로는 영업 불가능하고 상용 라이선싱을 끼워야만 장사가 된다는 얘기죠.
[quote="Anonymous"]저한테 물어볼 정도로 현실을 모르신
뭐! 현실을 알고 모르고는 떠나서..
바라시는 것이 무엇인지 궁금해지네요.
GPL 라이선스가 좀더 실질적인 법제화(?) 되어 이런일이 없도록 하길 원하시는 것인지..
GPL 라이선스 자체를 부정하시는지 궁금해 지네요.
아시는 업체가 GPL 을 위반했다면, 공식적으로 공론화 하셔도 될 듯 합니다.
예전 프루나 사건 처럼 말이죠.
"서로 좋을 일 없다" 라는 것이 무슨의미인지?
글만 봐서는 안좋은 생각이 드네요.
결국 GPL이라는 옆길로 새버렸네요. -_-;저도 잠깐 옆길로 새
결국 GPL이라는 옆길로 새버렸네요. -_-;
저도 잠깐 옆길로 새버립니다. ^^;;
제가 생각해도 GPL은 다소 비현실적 같습니다.
GPL은 밥벌이용이라기 보다는 취미생활용에 더 적합하다고 생각됩니다.
규모가 좀 큰 프로젝트들이야 후원도 많이 받을 수 있고 이래저래 돈벌이가 용이하겠지만 소규모 프로젝트의 경우에는 답이 안보입니다.
당장 KLDP.net을 생각해봐도 그다지 돈벌이가 되겠다고 생각되는게 없습니다. (KLDP.net 개발자 여러분께 죄송합니다. -_-; )
모든 사람들에게 기부문화와 정품사용문화가 평소 삶의 일부분으로 완전히 정착되있으면 모를까 그렇지 않은 이상은 다소 비현실적인 것 같습니다.
그냥 비공개, 공개가 적당히 섞여있는 것이 가장 좋을 듯 싶네요.
그런데 GPL이 공산주의와 비슷하다는 생각도 종종 듭니다.
머리 속으로 생각하면 괜찮은 듯한데 막상 현실에 적용시키기는 좀 막막한...
저도 GPL 조금 이상에 가깝다고 생각이 되긴 합니다.우선 생각해
저도 GPL 조금 이상에 가깝다고 생각이 되긴 합니다.
우선 생각해 볼 것이 오픈소스와 GPL 을 별개로 봐야 할까요?
동일시 해야 할까요?
gnoyel 님 말씀도 보면 오픈소스와 GPL 을 동일시 하고 계시네요.
[quote="firefox"][quote="Anonymous"]저한
법제화돼서 엄격하게 규칙을 적용해야 되는데 현실적으로 불가능하단 얘깁니다.
프루나에서 걍 씹어버리니까 그 얘기도 물건너 가더군요. 국내에서는 GPL 위반해도 걍 씹으면 땡입니다. 공론화만 하면 뭐합니까. 구속력이 없는데.
다 아는 사람들끼리 얼굴 붉힐 필요 없단 얘깁니다. 이 바닥이 의외로 좁아서 한다리 건너면 전부 친구에요.
ddoman님께:저는 GPL이 자유소프트웨어와 상충된다고 말한 것
ddoman님께:
저는 GPL이 자유소프트웨어와 상충된다고 말한 것이 아닙니다. 정확하게 말하자면,
"지금 GPL을 이용하여 득을 보고 있는 업체는 두가지다. 하나는 듀얼 라이센스를 이용하여 GPL을 광고수단으로 삼고 실제 돈은 -당신이 돈을 벌고 싶다면- 유료 라이센스를 사라고 하여 수익을 취하는 회사. 다른 하나는 수많은 오픈소스 개발자의 works를 가져다 묶어서 팔기로 결정한 뒤 자본을 모아 이걸 관리할 수명의 개발자에게만 보수를 지급하는 장사꾼의 회사다."
정도로 말할 수 있겠군요. 전자가 트롤테크, 후자를 저는 레드햇이나 SuSE라고 봅니다.
전자의 경우는 악질입니다. 그들은 분명 GPL로 성공하고 있는 것이지만 이들의 성공이 GPL의 성공은 아닙니다. 오히려 이들은 GPL로 제품을 공개하고 "이 라이센스대로는 당신은 돈을 벌 수 있는 뭔가를 할 수 없다" 라는 점을 강조합니다. 그래서 이걸로 뭔가 돈이 될만한걸 만드려면 당신은 우리에게 돈을 내야한다. 라고 한다는 것이죠. 실제로 트롤테크의 석세스 스토리를 읽어보면 대부분이 이런 비공개 라이센스를 구매한 사례입니다. GPL 자체보다는 GPL과 현실이 가진 괴리를 최대한 이용하고 이 틈에서 단물을 빨아먹는다고 할 수 있겠군요.
SuSE 같은 후자의 경우는 프리소프트 정신에 반한다고 볼 수는 없습니다. 그러나 제 개인적인 관점에서 말하자면, 수많은 사람들이 코드를 공개하고 헌납할 때 이를 묶어서 팔고 여기서 생기는 수익을 경영자와, 일부의 유지보수를 위한 개발자들에게만 몰아주는 시스템은...여기에 기여한 대다수의 개발자들에게는 한 푼도 돌아가지 않게 됩니다. 그렇다면 그들은 뭘로 먹고 살까요? 물론 다른 일을 해서 먹고 사니까 그런 여유가 있겠지요. 하지만 제품의 완성에 기여한 대부분의 개발자는 나름대로의 직업을 통해 먹고살고, 일부의 경영자와 그 경영자들이 고른 소수의 선택받은 개발자가 제품의 이득을 독식하는게 과연 옳은 일일까요?
그리고 위의 두가지에 해당되지는 않지만 지금 오픈소스 씬에서 가장 괄목할만한 성과를 보이는 프로젝트를 살펴보면 "경쟁사를 견제하기 위하여 프로젝트를 여러 기업들이 물 밑에서 밀어준 덕분에" 성공한 사례를 쉽게 찾아볼 수 있습니다. 경쟁사를 쓰러트린 다음에 이런 기업들의 태도가 어떻게 변할지는 아무도 모르겠지만 그리 이상적인 미래는 아닐 것 같습니다.
규모의 법칙이라도 있는 것일까요? 프로젝트가 일정 규모 이상이라면 대부분이 3가지 중 하나가 됩니다.
듀얼 라이센스를 이용한 수익구조, RMS는 개발자가 자신의 제품을 유지보수하여 수입을 얻으면 된다고 했지만 개발자 자신이 아닌 다른 이들이 (자본과 마케팅의 힘을 무기로) 대신 유지보수를 하고, 경쟁사를 견제하기 위한 수단의 하나로 스폰서가 되어줄 뿐...
써놓고 보니 울적해지는군요.
[quote="firefox"][b]gnoyel[/b] 님 말씀도 보면
동일한건 아닙니다. 비슷하다고 생각하는거지...
저에게는 오픈소스와 GPL은 거의 같은 개념으로 와닫습니다.
물론 BSD나 기타 다른 라이센스도 많지만 아무래도 가장 널리 알려져 있고 가장 많이 접하기 쉬운 것들이다 보니 그렇게 인식되네요. -_-;
사람들이 internet 하면 www을 떠올리듯이요. -_-;
[quote="Anonymous"]전자가 트롤테크, 후자를 저는 레드햇이
회사를 한번이라도 다녀보셨다면 그런 회사보고 악질이라고 비난은 못하실텐데요? 그렇다고 RMS처럼 FSF 코리아에서 근무하실 것도 아니라면 그런 자극적인 표현은 삼가시길 바랍니다.
GPL의 관점에서 보자면 악질이라는 것이지요. :)GPL이라는 것이
GPL의 관점에서 보자면 악질이라는 것이지요. :)
GPL이라는 것이 FSF의 심장이라고 할 수도 있다보니, GPL을 이해하고 GPL의 관점에서 보자면 당연히 악질이잖아요? :oops:
글 쓴 저는 저 위에도 적었지만 "RMS 논리로는 시장 자체가 성립하지 않는" 분야에서 밥을 벌어먹고 있습니다. 당근 GPL과는 백만광년쯤 거리가 있구요...
그렇지만 토론을 한다면 그런 자신의 출신은 좀 덜 신경써도 되도록 남의 배경 넘겨짚기는 삼가했으면 좋겠습니다.
Re: ?? 착각이..
이부분에 대한 부연 설명 부탁합니다. 오픈 소스의 핵심은 단순히 소스를 볼 수 있다가 아니고, 그 소스를 이용해서 재배포할 수 있다로 알고 있거든요. 자바 소스를 이용해서 다른걸 만들어서 배포해도 되는지 궁금합니다.
예전에 윈도2000 소스가 인터넷에 돌았지만, 특히 오픈소스 진영에서는 아예 소스를 보지 말아라 하는 말까지 있었습니다. 소스를 보면 소스를 따라하게 되고, 잘못하다간 저작권 문제가 날 수 있기 때문이죠.
Re: Java 소스코드 수정은 가능합니다만..
그쪽 지식이 잘 없어서 TCK가 뭔지는 확실히 모르지만, 자바 호환성 테스트쯤으로 생각하겠습니다. 공식 테스트 통과한거다하고 도장찍어주는거 맞죠?
사실 이런게 비싸면 SUN의 권위를 이용하려는 중소업체의 활동에는 지장이 있을지 모르겠지만 오픈소스 진영에까지 큰 지장이 있을지는 의문입니다. 물론 만들어놓고 테스트를 안해준다고 칭얼대기는 하겠지만요. 리눅스 초기에 posix 표준 문서 보지도 많고 만들었다는 얘기도 있을 정도인데요. 오픈소스로 거나하게 만들어서 떠버리면 알아서 테스트해줄겁니다 -_-;; 아니면 래드햇 같은데에서 돈좀 내줘서 테스트할지도 모르고요.
[quote="Anonymous"]GPL의 관점에서 보자면 악질이라는 것
트롤텍이 Qt를 GPL로 배포한다고 하자 가장 반가워한 사람중 하나가 RMS인데 뭔 말씀이세요? 의심스러우면 Qt GPL 발표문 한번 읽어보세요. 인용된 사람이 누군지.
[quote]오픈 소스의 핵심은 단순히 소스를 볼 수 있다가 아니고, 그
이건 OSI의 오픈소스 정의일 뿐이지 이게 일반적으로 통용되는 오픈소스의 정의라고 보긴 무리가 있습니다. 그보다 말 그대로 소스가 오픈되어 있으면 오픈소스라고 보는 게 더 맞는 표현이겠죠.
그리고 트롤텍이 악질이라는 건 아무리봐도 어거지입니다. GPL로 뻔히 배포되고 있는데 뭐가 문제란 건지. GPL이 있음에도 상용 라이센스를 따로 제공하는 것은 오히려 고객을 위한 겁니다. 생각해보세요. GPL만 있으면 기업에서는 Qt 어떻게 가져다 쓰겠습니까?
그리고 MySQL 이야기가 잠깐 나왔는데 MySQL을 상업적으로 이용하는 것은 GPL 위반이라고 단정할 수 없습니다. GPL은 소프트웨어의 이용에 관해서는 완전한 자유를 허가하고 있습니다. 이것에 관해서는 이미 많이 논의된 바가 있죠.
그리고 GPL은 국내에서도 엄연히 효력이 있습니다. 하지만 저작권의 특성상 소유권을 가진 사람이 직접 소송을 걸지 않으면 소용이 없죠. 단지 지금까지 국내에서 GPL로 소송한 경우가 없을 뿐 GPL 위반 사실만 증명된다면 충분히 법적인 보상을 받아낼 수 있습니다.
[quote="creativeidler"]그리고 MySQL 이야기가 잠깐
다른 오픈 소스 툴들하고만 묶어서 상업화한다면 물론 GPL 위반 아니죠. 하지만 실제로는 상용 웹솔루션을 공급할 때 중간에 proprietary 코드가 안들어간 솔루션은 제가 아는 한 국내에 한개도 없습니다. 단순히 프로그램 몇개 모아놨다고 솔루션이라고 말하진 안거든요. 그러니까 100% GPL 위반인 겁니다.
뭔가 착각하고 있으신 것 같군요. 그게 GPL의 어떤 조문을 위반한다는
뭔가 착각하고 있으신 것 같군요. 그게 GPL의 어떤 조문을 위반한다는 것인지. 단지 같이 배포한다는 것은 결코 GPL 위반이 아닙니다.
[quote="creativeidler"][quote]오픈 소스의 핵심은
아닙니다. 소스가 공개되어있지만 그것이 베낄 수 없는 라이센스에 걸려있다면 그림의 떡일 뿐입니다. 그 소스를 가지고는 아무것도 할 수가 없죠. 예전에 windows 2000의 소스가 퍼진 일이 있었죠. 오픈소스 개발자들은 그것을 보지 말라고 했습니다. 괜히 봤다가 본의 아니게 스며들어가면 저작권 문제가 일어날 소지가 있다는 이유였습니다.
"소스가 오픈되어 있으면 오픈소스" 라는 개념은 조금 위험해보입니다만.
저도 트롤텍이 악질이라는 데는 동의하지 않습니다. 기업과 오픈 소스의 절묘한 관계 정도로 생각하고 있습니다. 이하 이야기는 제가 주장한 내용이 아니라서 특별히 답변할 내용은 없는거 같네요 :) 대충 동의합니다.
[code:1]아닙니다. 소스가 공개되어있지만 그것이 베낄 수 없는 라이
언어 표현의 의미를 결정하는데 있어서 그런 게 무슨 상관이 있으며 위험할 건 또 무엇입니까? 표현의 의미를 결정하는 것은 두 가지, 말 그대로 해석할 때 어떤 의미인가와 실제로 어떤 의미로 쓰이고 있는가입니다. 말 그대로 해석하면 분명히 그저 소스가 오픈되어 있는 것을 가리키는 것이죠. 그리고 오픈소스에 수정 및 재배포의 권한을 포함시키는 것은 단지 커뮤니티의 자의적인 정의일 뿐 개발자 집단 전체에서 널리 통용되고 있다고 보긴 힘듭니다.
[quote="creativeidler"]뭔가 착각하고 있으신 것 같군요
이 얘기 벌써 몇달전에 KLDP에서도 끝난 얘긴데...non-free 프로그램은 GPL 버전의 MySQL에 접근 못하게 돼있습니다. 의심스러우시면 MySQL 사이트에 가서 라이선싱 정책을 읽어보세요.
http://www.mysql.com/company/legal/licensing/index.html
[quote="creativeidler"]언어 표현의 의미를 결정하는데
세계 어느 개발자 커뮤니티를 가도 '오픈소스'를 단지 소스가 공개된 프로그램으로 정의하는 경우는 못봤습니다. 적어도 최근 2-3년 전부터 말이죠. 당장 ZDNet 같은 매체만 해도 오픈소스를 언급할 때 OpenSource Initiative의 정의를 인용하는 마당에 소스가 오픈되어 있다고 오픈소스라고 말하는 것은 비현실적입니다. 그리고 실제로 이러한 오해가 위험을 자초할 수도 있습니다. 소스는 오픈되어 있지만 재배포에 제한이 있는 라이센스를 가져다 자기맘대로 배포하는 몰상식이 부지기수로 일어나거든요.
----
http://nohmad.tumblr.com/
[quote="creativeidler"]언어 표현의 의미를 결정하는데
아랫분이 대답하셨지만 제 주위에서도 단지 소스가 있으면 오픈 소스 소프트웨어라는 개념을 사용하는 곳은 많이 보지 못했습니다.
이 개념은 중요합니다. 그 차이가 바로 오픈소스인가 아닌가를 가르는 최대의 척도라고 생각합니다. 그리고 자바는 아직 그 척도를 넘지 못하고 있죠.
그리고 당연하지만 그 차이가 바로 오픈 소스 커뮤니티의 지원을 제대로 받을 수 있는지 없는지에 대한 척도이기도 합니다. 물론 자바가 나름의 정책을 통해 시장에서 엄청나게 성공을 하긴 했습니다만 오픈 소스 진영에서의 시각이 그리 좋지 않은 것은 바로 이 선을 넘지 못했기 때문입니다.
제 생각에 자바가 그 선을 넘지 못하는 한 오픈 소스 진영에서의 경계는 계속 되리라고 생각합니다. (물론 자바의 성공과는 별개로입니다.)
Re: 썬이...
그 아웃소싱하는 회사들은 오픈 소스 제품들은 하나도 쓰지 않고 장사하나보지요? GPL 덕에 그나마 먹고 사는 사람들이 무슨 GPL 핑계를 댑니까? GPL이 남의 나라 얘기면 당장 오늘부터 GPL 걸린 소프트웨어 쓰지 말고 장사하세요.
회사 생활하면서 GPL이 왜 안되는지 당장 알았으면 구체적으로 왜 GPL이 안되는지 여기에다 몇자 적어보세요. 회사 경험 없는 사람도 좀 배우게요. 회사 생활하면서도 견문이 넓어지기는 커녕 이윤 몇푼 핑계에 아집만 느는 사람들 숱하게 봐왔습니다. 보통 그런 사람들이 현실 어쩌고 핑계 대면서 이론은 쓸데없다는 얘기를 잘 하지요. 그런데 막상 뭐가 문제인지 구체적으로 설명을 해 봐라고 하면 꼭 자네가 현실 경험을 해 보기 전에는 모른다.... 핑계를 대면서 꼬리를 내리더군요.
아.. 그리고 "logout 님"같이 개인적인 언급을 할려면 그쪽도 로긴을 하세요. 익명 뒤에 숨지 말구요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
자바 6.0에서는...
자바의 license는 바뀌는 중입니다. 이것을 읽다보면
이라는 내용이 나옵니다.
그리고, 위의 내용을 뒷받침 하기위해 세가지 다른 license를 적용한다는 이야기가 진행 중입니다.
저 위에 링크된 Harmony 프로젝트의 결과가 어떻게 될지는 지켜보아야겠지만, Sun이 자바 license에 대한 압박을 여러 곳에서 받고 있는 중이라 수동적이기는 해도 바뀌고는 있다고 생각을 합니다.
하지만, 위의 license들로 Java Trap을 해결할 수는 없겠죠. 따라서, 어찌보면 번죽만 한 셈일수도 있는데, "오픈소스로 호환 J2SE를 만든다", "license를 바꿔라", "Open Source 해라"하고 압박이 가해지면 무엇이든 결과는 있겠죠.
ps1. Sun이 MS와 JVM 사용에 대한 합의를 했는데, Sun이 자바를 Open Source할 수 있나요?
Ps2. Mono처럼 뭔가 만들면서 압박을 하는 것도 하나의 방법이라면, 그런 점에서 Harmony 프로젝트는 자바를 Open Source화 하는데 첨병이 될 수 있을까요?
----
I paint objects as I think them, not as I see them.
atie's minipage
[quote="Anonymous"][quote="Anonymous"]GP
그렇다면 듀얼 라이센스를 배제하기 위한 GPL 개정의 이유는 어디서 온 것일까요?
전에도 말했지만 RMS 역시 앞으로 일어날 모든 일을 다 알고 있는 것은 아닙니다. 트롤테크가 GPL로 배포하긴 했지만 결국 이런 듀얼라이센스 업체가 프리소프트 씬에 어떤 기여를 했던가요? 최근 MySQL의 예를 봐도 알 수 있듯 GPL에 대한 FUD를 퍼트리고, 협박 무기로 쓰고 있을 뿐입니다.
Re: 자바 6.0에서는...
zdnet에도 기사가 떴더군요
http://zdnet.co.kr/news/enterprise/0,39024412,39136276,00.htm
open source J2SE가 나온다면 IBM이나 BEA같이 기존에 J2SE를 독자적으로 만들던 회사 입장에서는 반기지 않을까 생각하는데요.
Harmony 프로젝트가 어느정도 활성화된다면 이런 기업들의 지원을 기대해 볼 수 있지 않을까요?
그렇게되면 SUN에게도 상당한 압력이 될 것 같은데...
----------------------------------------
Kwonjin Jeong
Re: 자바 6.0에서는...
제가 아는 한도에서 MS가 썬의 공개된 JVM 코드에 contribute 한 부분은 없다고 알고 있습니다. MS는 썬에서 JVM 코드를 사서 이를바탕으로 MS의 JVM을 만들었고 이를 윈도우즈에 번들시켜 배포했습니다. 거꾸로 썬의 공개된 코드에 MS가 copyright를 주장할 부분은 없는 것으로 알고 있습니다만... 확실하지는 않구요.
충분히 가능한 얘기일 것 같습니다만 개인적으로 그 전에 어떤 이유 때문에 썬이 계속 자바에 대한 제어권을 놓으려 하지 않는지가 무척 궁금합니다. 단순히 자바를통한 매출을 잃고 싶지 않다는 것일까요? 어쨌거나 당연한 얘기이겠지만, 이 부분이 좀 더 명확해져야 Harmony 프로젝트가 효과적으로 썬에 자극을 줄 수 있을지 없을지의 판단 또한 따라서 명확해지지 않을까 싶습니다.
"I conduct to live,
I live to compose."
--- Gustav Mahler
[quote="Anonymous"]전에도 말했지만 RMS 역시 앞으로
듀얼라이센스 업체( GPL을 채택한 )가 기여하는 바는
듀얼라이센스가 아닌 순수 GPL 소프트웨어가 기여하는 바와
아무런 차이가 없습니다.
제가 Qt를 가져다가 Rt를 만들든 At,Bt를 만들든
MySQL을 가져다가 YourSQL을 만들든 GPL에 위반되지만
않으면 아무런 제약이 없습니다.
듀얼라이센스인 동시에 GPL이기때문에
해당코드를 열람, 이용, 배포하는데 GPL의 제약사항 안에서는
자유롭습니다.
그게 기여가 안된다고 보십니까?
자꾸 주제랑 상관없는 쓸데없는 답변달아서 조금 민망하군요.. :oops:
Re: 자바 6.0에서는...
Sun이 MS한테 MSJVM을 2007년 말까지 사용을 할 수 있도록 한 댓가로 돈을 받았기에 최소한 2007년 말까지는 자바를 오픈소스로 풀지는 못할 것이라는 제 추측입니다. 그렇지만, Gosling은 자바는 돈을 벌기위한 수단이 아니라고 분명히 이야기 했습니다.
두번째 인용에 대해서는, 글쎄요? 표면적인 이유로는 어플리케이션 개발자를 위해서는 최소한 compatibility testing이 된 VM만을 허용하기 위해 가장 잘 아는 Sun이 그 임무를 맡겠다는 것인데... 아무래도 IBM에 대한 견제가 첫번째, 두번째는 Java라는 브랜드, 세번째는 살아남기 위해서가 이유들이 아닐까 싶습니다.
----
I paint objects as I think them, not as I see them.
atie's minipage
에...TCK만 통과하면 됩니다.
어떤 식으로 만들지 간에 JVM이라는 명칭을 쓰고 싶다면, TCK를 통과하면 됩니다.
통과하지 못하면 java 호환 VM이라고 말할수 없습니다.
여기가 대해 사실상 썬이 권력을 쥐고 있는 부분이고요..
아파치 하모니 프로젝트의 목표는 이미 TCK가 통과되서 그 기반이 되는 코드에 대해 기능상의 인증을 받은 오픈소스를 확보하고 이를 다른 곳에 가져다 포팅해도 거의 완전한 포팅이 가능한 기반을 확보하자 입니다.
여기에 HOT-SPOT등의 퍼포먼스 엔진을 넣는건 아파치에서 할수 도 있고 다른 곳에서 할수도 있겠지요.
썬이 주장하는 건 간단합니다. TCK를 통과하지 못한 VM을 JVM이라고 부르지마라...
그래서 Kaffe등이 JVM이라고 말하지 못하고 자바를 지원하는 VM이라고 부릅니다. 그러면 당연히 오픈소스를 가져다 사용하는 입장에서는 불안하죠.
그런데 만약 TCK 비용이 무료나 부담없는 수준이 된다면, 당장 Kaffe나 GCJ가 TCK 통과를 시도 할 것이고 이과정에서 엄청난 호환성 향상이 이뤄지게 됩니다.
문제는 썬이 이 비용을 낮출 계획이 없기 때문에 8만달라나 되는 비용을 일반적인 오픈소스 진영에서는 낼수가 없죠. 또 TCK를 받기 위해서는 JCP에 가입해야 하는 것도 있습니다.
그래서 아파치가 총대를 매겠다고 나온겁니다. 아파치는 오픈 소스 진영중에서도 상당한 정치력을 가진 곳이고 최근에 JCP에도 가입한 걸로 알고 있습니다. 아마 썬에서도 오픈소스 진영이기 때문에 TCK 비용을 일정수준 내릴겁니다. 오픈소스 지원이라는 명목에 말입니다.
이미 오픈 소스 JVM이 한두개도 아닌데 난데없이 또 하나 새로 만들겠다
이미 오픈 소스 JVM이 한두개도 아닌데 난데없이 또 하나 새로 만들겠다는 발상은...대략 신선해보이지 않습니다.
그 많은 오픈 소스 VM이 '''모조리''' JVM이 아닙니다.
Kaffe나 GCJ, Wonka 등의 많은 수의 VM들이 모두 JVM이 아닙니다.
TCK를 통과하지 못했기 때문이죠.
따라서 자바 언어와 자바 바이트 코드를 지원하기는 하지만 자바와 완전히 호환되는 JVM은 아닌겁니다.
이런 VM으로 뭘 할수 있을까요? 기껏해야 다른 오픈소스제작용이나 연구용으로 밖에 사용할수 없습니다. 사실 그것도 어렵죠. "내가 만든 코드가 제대로 된 JVM에서 돌아갈까?"라는 의문을 가지게 될 겁니다. 이걸 가지고 J2EE Container등을 돌릴수 있을까요?
그런데 TCK를 통과하게 되면 JVM이라고 할수 있습니다. 상호 호환성이 보장되었다는 의미입니다.
아파치에서 어떤 식으로 VM을 만들지는 모릅니다. 뭐 Kaffe를 가져와서 만들수도 있고 GCJ를 발전 시키는 형태가 될수도 있고..
하지만 어떻게 되던지 간에 그 결과물이 TCK를 통과해서 호환성을 보장받는다고 하면, 이제부터는 이야기가 달라집니다.
뭐 예상컨데 하모니 프로젝트는 x86에 linux 기반으로 TCK를 통과할겁니다. 어찌되었든 통과하게 될거고, 아파치에서는 이 JVM을 제작할때 Portability를 극대화 하는 방향으로 제작하게 될겁니다. 아마 posix기반에 makefile만 수정해주면 어디든지 포팅되는 형태가 되겠죠.
그때는 이 JVM을 다른 곳으로 포팅하고 이렇게 말할수 있습니다.
"이 JVM은 Linux에서 TCK를 통과한 코드이고, 하드웨어 의존성이 없기 때문에 이 CPU와 이 OS에서도 사실상 TCK를 통과한 것으로 간주해도 됩니다. 뭐 나중에 돈 되면 TCK를 신청하죠"라고 말이죠.
그리고 시간이 지나면 아파치에서는 대표적인 아키텍쳐와 OS들에 대해 TCK를 통과할겁니다.
그렇게 되면 이 VM은 "신뢰할수 있는" JVM이 되는 겁니다.
오픈소스용이나 연구용이 아닌 상업적으로 선택될수 있는 JVM이 되는 거죠.
(물론 Hotspot이나 jit등의 퍼포먼스 엔진은 어떻게 될지 모르겠습니만..)
신뢰할수 있는 Open source JVM을 가지게 되면 이것을 다양한 목적으로 사용할수 있게 됩니다. Openoffice에 아예 포함시킬수도 있을것이고, 다양한 프로젝트에서 java를 사용할수 있게 될겁니다.
ps. 개인적으로는 하모니 프로젝트에서 CVM도 같이 진행되었으면 하는 바램이 있습니다. TCK를 받은 프리소프트웨어인 CVM이 있다면 할수 있는게 대단히 많아지거든요.
Re: 그 많은 오픈 소스 VM이 '''모조리''' JVM이 아닙니다.
못한 게 아니라 안한 것 뿐입니다. 사실은 바로 압시다.
이미 만들어진 오픈소스 VM들은 앞으로도 TCK를 통과못할 것이고 아직 만들어지지도 않은 가상의 VM은 TCK를 통과할 것이라고 가정하는 근거는 뭐지요? 아무리 생각해도 희한하게 들립니다.
아파치 하모니 VM은 아파치 라이센스를 따를 것이기 때문에 Kaffe나 GCJ로는 단한줄도 따올 수 없습니다.
상당히 생뚱맞은 이상한 가정이네요. 하모니가 TCK를 통과할 것이란 근거없는 낙관은 대체 어디에 기반을 한 것인지...?
Re: 그 많은 오픈 소스 VM이 '''모조리''' JVM이 아닙니다.
못했단 안 했든 TCK 인증이 없습니다.
통과못할 거라는 근거는 또 뭔가요 ?
아파치 재단에서 후원한다 하여 아파치 라이센스를 꼭 따라야 하나요 ?
무지막지하게 생뚱맞은데, 하모니가 TCK 를 통과하지 못할 것이라는 근거없는 비관은 대체 어디에 기반을 한 것인지... ?
Re: 그 많은 오픈 소스 VM이 '''모조리''' JVM이 아닙니다.
하모니란 프로그램은 이제 겨우 맨땅에 헤딩한 상태거든요?? 혹시 하모니 팀 개발자나 관계자세요?? 있지도 않은 프로그램이 나중에 TCK를 통과할지 말지 어떻게 그렇게 잘아시나...
이런 쌩뚱맞은....아파치 재단과 하모니 개발팀에다 왜 꼭 아파치 라이센스를 따라야 하냐고 직접 물어보시져???
Re: 그 많은 오픈 소스 VM이 '''모조리''' JVM이 아닙니다.
맨땅에 헤딩하고 있든 허공에 삽질을 하든 나온다음에나 통과 여부가 결정되는 거지 나오지도 않았는데, 통과 못할 것이라는 망상은 머리세요. 통과한다고 말하는 것도 우습지만, 못할 거라는 것도 우습습니다.
그리고 역시나 나오지도 않은 놈을 아파치 라이센스일 거라고 단정하는 오류는 범하지 마세요.
Re: 그 많은 오픈 소스 VM이 '''모조리''' JVM이 아닙니다.
아 이론...어이를 옥션에 팔아넘긴 것 같은 말씀이...아파치 재단에서 하모니를 아파치 라이센스로 개발할 거라고 프로젝트 시작하면서 명확하게 못박은바 있는데 그것도 모르시면서 하모니가 TCK를 통과할거라는 등등 말씀하시는 거는 증말 문제가 있다고 밖에는 볼 수가 없네요. 괜히 남들이 TCK 어쩌고 JVM 어쩌고 떠든다고 덩달아 끼어들어 아는 척은 삼가해 주세요.
[quote]이 얘기 벌써 몇달전에 KLDP에서도 끝난 얘긴데...non
끝나긴 뭐가 끝난 얘깁니까. 얼마 전 있었던 MySQL 토론에서도 갑론 을박이 난무했었는데.. 그리고 MySQL 사이트의 라이센스 정책은 이미 충분히 읽어봤습니다. 하지만 그건 라이센스에 대한 MySQL 측의 "입장"인 것이지 그것이 GPL에 대한 해석은 아니죠. GPL 위반 여부를 가리려면 GPL 조항이 우선인 것은 당연하지 않습니까?
[quote="creativeidler"][quote]이 얘기 벌써 몇달
그렇게 의심스러우시면 MySQL의 국내 총판인 바인테크던가 하는 회사에 전화걸어서 물어보세요. 바인테크가 뭐라고 떠들든 난 내맘대로 쓰겠다고 하시면 할말 없지만...
음. 뭔가 잘못 아시는듯..
하모니 프로젝트의 목표 자체가 썬의 TCK를 완전히 통과한 오픈소스 JVM의 제작입니다.
"Harmony has stated a clear goal of full compatibility with Java standards, to be tested by the official Technology Compatibility Kit (TCK) from Sun."
Hamony FAQ 입니다.
http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/%3cE3603144-2C26-4C31-896D-6CC7445A63EB@apache.org%3e
기존의 오픈소스들이 TCK를 통과하지 못한/않한 이유는 돈입니다.
TCK 비용 8만달라를 1 CPU/OS 마다 내야 합니다. 같은 CPU인데 Win 98, W2k, XP에서 각각 8만 달라씩 내야 하죠. 같은 리눅스인데 레드헷 7, 레드햇 8, 레드헷 9, FC 마다 8만달라씩 내야하죠.
(참고로 2002년엔가 IBM은 100만달라 가까운 돈을 J9의 TCK 통과 비용으로 사용했습니다. )
그러니 못한 겁니다. 오픈소스진영에 그나마 풍족한 자원은 개발자이지 돈이 아니거든요.
[quote]아랫분이 대답하셨지만 제 주위에서도 단지 소스가 있으면
개인적인 경험일 뿐입니다.
마찬가지로 개인적인 경험일 뿐이죠.
개인적인 경험을 말한다면 제가 경험했던 개발자들은 대부분 소스만 공개되어 있으면 오픈소스라고 인식했었다고 대답할 수 있습니다. 실제 SI 하는 개발자들은 오픈소스 공동체가 뭐하는 건지 잘 모릅니다. 그냥 단어의 의미를 그대로 받아들일 뿐이죠. 개발자 커뮤니티라는 것은 이미 오픈소스 공동체의 영향을 많이 받는 상태니까 그들의 정의로 사용할 수도 있겠지만 현업에서 당장 학원 6개월 다니고 들어온 개발자들이 그런 정의를 알 꺼라고 생각하십니까? 그렇다고 그들이 지식이 모자라서 착각한다고 쉽사리 말할 수 없는 것이 원래 오픈소스의 말뜻이 소스 공개의 의미이기 때문입니다.
물론 점차적으로 OSI 식 오픈소스의 정의가 확산되고 있으니 앞으로 1~2년 후는 그렇게 말할 수 있을지도 모릅니다. 하지만 최소한 지금은 자바가 오픈소스라고 인식하는 사람이 많고 오픈소스의 조건으로 소스공개만 생각하는 사람이 많기 때문에 당장 언어의 의미를 획일적으로 바꿔서 사용하는 것은 오히려 더 위험해보입니다.
그리고 이것은 오픈소스라는 용어의 위험성이라기보다 라이센스에 대한 부주의에서 오는 위험이겠지요. 오픈소스의 OSI식 정의를 알더라도 GPL에 대해 잘 모르면 위험한 일은 얼마든지 발생할 수 있습니다. 기본적으로 개발자가 라이센스에 얼마나 신경을 쓰느냐의 문제지 용어에 대한 혼동의 문제는 아니라고 봅니다.
오픈소스 진영에서 자바를 경계한다는 것은 성급한 일반화입니다. RSM을 위시한 일부 세력에서만 경계할 뿐이죠. 최근 소스포지에서 자바 프로젝트의 수가 C를 넘어서서 C++ 다음으로 2위, freshmeat에서는 C 다음으로 2위입니다. 아파치 프로젝트에는 자바 전문인 자카르타 프로젝트에서 많은 프로젝트들이 아파치 메인으로 올라올 정도로 영향력을 발휘하고 있고 그 외에도 현업과 연계되어 돌아가는 오픈소스 공동체가 많습니다.
솔직히 전 RSM의 문제 제기 자체도 지나치게 독선적이라고 봅니다. 오픈소스는 비오픈소스와의 공존에도 오픈되어 있어야합니다. 실제 JVM의 이용에 별 문제가 없는 상태에서 굳이 오픈소스 JVM을 찾아야할 필요가 있을까요.
[quote]그렇게 의심스러우시면 MySQL의 국내 총판인 바인테크던가
바인테크가 뭐라고 하는지는 잘 알고 있소이다. 그래서, 님은 바인테크에서 시키는대로 네네 하고 따라가시렵니까?
[quote="creativeidler"][quote]그렇게 의심스러우시
저작권자가 자기 프로그램을 자기맘대로 하겠다는데 웬 제3자가 나서서 딴지를..?
[quote]저작권자가 자기 프로그램을 자기맘대로 하겠다는데 웬 제3
저작권자가 GPL을 따르겠다고 했으니 당연히 우리는 GPL을 지킬 수 있는 상황이라면 저작권자가 뭐라고 하든 상관 없습니다. 아무래도 GPL을 제대로 읽어보지도 않은 것 같군요.
[quote="Anonymous"]저작권자가 자기 프로그램을 자기맘대
저작권을 맘대로 정할 수 있겠지만, 한번 정한후에 마음대로 바꾸는 것은 문제가 있겠죠.
아마 그점이 문제가 되었던 것이 아니었나 생각되네요.
어떤면에서는 약관위반 이라고 볼 수 있지 않을까요?
사용자가 바꾸어 나가자!!
= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com
전혀 문제없습니다.
새로 바꾸는 것은 전혀 문제없습니다. 쉽게 말하면 "이제부턴 이렇게 할꺼야"라고 말하는 것이고 과거의 것이 소급 적용되지는 않습니다.
과거의 것에 소급적용하려고 하면 문제가 있습니다만..
[quote="creativeidler"][quote]이 얘기 벌써 몇달
저도 당시 토론에 관심이 많았었고 또다른 MySQL총판인 IT브리지에서 제가 다니는 회사에 lisence fee를 요구하기도 했었기때문에 솔깃해지네요.
당시에도 제가 궁금했던것은 MySQL측의 라이센싱 조항을 읽어보면 다들 아시다시피 듀얼 라이센스이기는 한데 commercial lisence조항이 상당히 애매합니다. 그리고 "GPL이 적용될지 commercial lisence가 적용될지에 대한 해석 권한은 MySQL AB가 가진다"라는 내용이 있어서 더더욱 헷갈리게 만들더군요. 결국 자기들 맘대로 하겠다고 만들어놓은 조항이라는 생각도 들고요.
GPL을 위반한 경우 상업 라이센스인지, 상업용도가 아닌 경우 GPL인지 이런 문제가 명확하지가 않습니다. 결국은 법정에서만 판단될 수 있는것일까요?
[quote="creativeidler"]마찬가지로 개인적인 경험일 뿐이
일반명사와 혼동할 여지가 많은 고유명사의 맥락적 의미를 결정하는 것은 매우 지루한 일입니다. 하지만 이곳은 개발자 커뮤니티고, 지금 이 쓰레드는 적어도 '오픈소스' 세계에서 일어나는 어떤 사건에 대한 의견들이 주를 이루고 있습니다. 여기서 굳이 학원 6개월 마친 사람을 비하하는 듯한 어조로, 새삼스럽게 오픈소스가 다 뭐냐, 그냥 소스 오픈되면 오픈소스 아니냐는 식으로 말하는 건 좀 당황스럽군요. SCSL도 오픈소스고, 마이크로소프트 Shared License도 오픈소스고, 제로보드도 오픈소스군요. 이렇게 '오픈소스'를 남발하는 것이 좀더 주의 깊게 사용할 필요가 있다는 것과 비교해 어떤 점이 좋나요?
라이센스가 가진 특유의 제한사항을 완전히 숙지하지 못함으로 인해 발생하는 미묘한 위반사항들도 분명히 있을 겁니다. 아니, 이런 일이 굉장히 많을 겁니다. '오픈소스'라는 말을 주의 깊게 사용하는 것이 이런 위험을 구하지는 못할 것입니다. 하지만 '몰상식'한 위반사항들은 구제할 수 있을 겁니다. 사실 OSI의 오픈소스 정의가 주는 이점은, 기존에 있던 다양한 종류의 라이센스들에서 공통 분모를 추출하여, 혼란을 덜어주었다는 점입니다. OSI가 말하는 '오픈소스' 정의를 알고 어떤 라이센스가 OSI와 호환되는지 여부를 알면, 그 라이센스가 갖는 기본적인 제한사항들을 몰라도 사용하는 데 별 지장이 없다는 것이 주는 이점은, '오픈소스'의 일반적 용법을 제한하는 것과 비교했을 때 충분히 이롭다고 생각합니다.
----
http://nohmad.tumblr.com/
[quote="creativeidler"][quote]저작권자가 자기
대체 님의 주장의 요지는 뭡니까? MySQL GPL 버전을 비공개 프로그램과 링크해도 된단 얘깁니까 안된단 얘깁니까? MySQL측은 GPL 버전을 비공개 프로그램과 링크하지 말라고 요구하는데 대체 뭐가 잘못됐습니까?
근데 대놓고 GPL 위반하는 업체한테도 뭐라 못하면서, MySQL 같이 잘 드러나지 않는 부분에 대해서 "우리"라는 주어까지 써가면서 뭐라 말할 수 있다니 박자가 좀 안맞는 느낌이 듭니다.
[quote="bs0048"][quote="creativeidler"][
법적으로 애매하다 싶으면 저작권자한테 직접 물어보고 판단하면 될 일이겠지요? 근데 보니까 저작권자가 뭐라하든 상관없고 제맘대로 하겠다고 억지를 부리는 분이 간혹 있더군요. 억지를 부리다 고소를 당하던 벌금을 물던 저두 상관은 없지만요.
[quote="creativeidler"]솔직히 전 RSM의 문제 제
MS OS/개발 환경 ,여러 상용 UNIX 환경에서 오픈소스를 만들수 있고 많이 나오죠. 대부분의 GNU 프로그램들도 그런 환경을 지원하구요. 그런데 굳이 GPL/LGPL 또는 BSD를 따르는 개발환경 및 OS가 나오는 거하고 같다고 생각합니다.
---
Licensing Free Software를 참고하세요.
위에 보면 FSF와 GPL 사용자에게 MySQL이나 QT같은 듀얼 라이센
위에 보면 FSF와 GPL 사용자에게 MySQL이나 QT같은 듀얼 라이센싱 업체가 무슨 기여를 했느냐라는 의견이 있는데, 듀얼 라이센싱은 MySQL이나 QT를 GPL 프로그램에 사용할 때 그냥 사용할 수 있으므로 물론 기여한 것이 확실하고 GPL 개발자에게도 도움이 됩니다. 이건 인정하실테니 여기에 대해서는 더 이야기하지 말지요.
듀얼 라이센싱 프로그램을 독점 프로그램과 연결해서 사용할 때의 문제는 이 쓰레드에서는 이번에 새로 나온 별도의 논의지 위에서 나온 '자유 소프트웨어 진영과 GPL 사용자에게 기여한 바가 없다' 라는 논의와는 연관이 없다는 것을 한 번 짚고 넘어갑니다.
----------------------------
May the F/OSS be with you..
[quote]대체 님의 주장의 요지는 뭡니까? MySQL GPL 버전을
네, 잘못되었습니다. 자기네 라이센스가 GPL이라고 주장하면서 GPL 위반이 아닌 걸 두고 GPL 위반이라고 한다면 말이죠. 링크가 뭘 의도하고 한 말인지는 모르겠으나 앞서 나왔던 MySQL을 같이 배포하는 행위는 분명 GPL 위반이 아닙니다.
헐, GPL 위반이 아닌 걸 보고 아니라고 주장하는 거랑 GPL 위반 업체 지적하는 거랑 대체 무슨 상관이 있나요? 제가 GPL을 지키자고 한 것도 아니고 말이죠.
저작권자가 GPL로 하겠다고 해서 GPL 지키겠다는데 그것도 문제란 건가요? GPL만 잘 모르는 게 아니라 법도 잘 모르는 것 같군요.
[quote="creativeidler"][quote]대체 님의 주장의
비공개 프로그램을 프론트엔드로 쓰고 백엔드로 MySQL GPL 버전을 쓰면 위반이란 얘깁니다. 이게 그렇게 이해가 안됩니까?
님같은 분이 엉뚱하게 딴지를 걸어오니까 MySQL에서 원래 LGPL이었던 걸 GPL로 바꿔버리고 일부러 토까지 달아놨는데도 그건 싹 무시하고 "저작권자가 GPL로 하겠다"고 했으니 나도 그렇게 하겠다고요? 아주 좋아요. 그렇게 해서 열심히 써보세요. MySQL 국내 총판에서 연락오면 걍 씹어버리면 되겠군요. 그담엔 거액의 벌금과 사장 구속... :P
[quote]비공개 프로그램을 프론트엔드로 쓰고 백엔드로 MySQL GP
풉, 언제 그렇게 얘기했었는데요? 그걸 보통 링크라고 표현하나요-_-? 그리고 그래도 여전히 GPL 위반이라는 증거는 안되는데요.
머, 무식해서 손해보고 살겠다는 사람은 말릴 생각이 없습니다. 그렇게 꼬박꼬박 안내도 되는 돈 갖다 바치면서 사세요. GPL도 모르고 법도 모르는데다 상식까지 부족하니 손해보면서 살 수 밖에..
하여간 손님들의 강짜는 어쩔 수가 없는가보군요. 뭐가 무서워서 저렇게 익명으로 할까나.. ㅋㅋ
[quote="creativeidler"][quote]비공개 프로그램을
ㅋㅋㅋ 전세계 수만개 기업들이 전부 무식해서 일부러 MySQL에다 돈내고 라이선스 사서 쓰겠습니까?? 제발 좀 상식적으로 생각을 해보세요 네?? 그건 그렇고 MySQL 회사도 님같이 억지부리는 사람들때문에 정말 피곤하겠군요. 왜 LGPL에서 GPL로 바껐는지 이해가 됩니다.
글구 손님 모드는 여기 관리자이신 권순선님의 정책에 따라 운영되는 건데 왜케 딴지 거는 사람이 많은 건지 모르겠네여?? 정 불편하면 손님이라고 이름써진 사람은 전부 한사람이다~ 이렇게 생각하세요 네??
[quote]ㅋㅋㅋ 전세계 수만개 기업들이 전부 무식해서 일부러 MySQ
그리고 또 전세계 수만 개의 기업이 돈 안 내고 잘 쓰고 있죠.
정말 모릅니까? 손님들은 대체로 님처럼 글을 쓰기 때문이죠. 정말 몰랐다니-_-
GPL에 대해
GPL 소프트웨어를 독점 시스템 안에 통합시키고 싶습니다. 가능합니까?
GPL 소프트웨어는 독점 시스템 안에 통합될 수 없습니다. GPL의 목적은 모든 사람들에게 프로그램에 대한 학습과 개작, 복제와 재배포의 자유를 부여하기 위한 것입니다. 만약 GPL 프로그램을 자유 소프트웨어 시스템이 아닌 곳에 통합시킨다면, 그것은 GPL 소프트웨어를 자유 소프트웨어가 아닌 것으로 만드는 결과가 됩니다.
GPL 프로그램이 통합된 시스템은, GPL 프로그램이 확장된 것이라고 할 수 있습니다. GPL은 GPL 프로그램을 확장한 버전을 공표할 때 그 라이선스로 GPL을 사용해야 한다고 규정하고 있습니다. 여기에는 두가지 이유가 있습니다. 첫번째는 소프트웨어를 취득한 사용자로 하여금 그들이 가질 수 있는 자유를 알게 하려는 것이고, 두번째는 그들이 만든 개선점들을 공동체로 환원하도록 격려하기 위한 것입니다.
GPL 소프트웨어가 독점 시스템에 통합된 형태인지 아니면 서로 독립적으로 작동하는 형태인지에 대한 구별은 실제적인 측면과 형식적인 측면으로 구분해서 생각해 볼 수 있습니다. 실제적인 측면에서 볼 때, 두개의 프로그램이 하나의 프로그램을 구성하는 두개의 부분으로 기능하면서 결합되는 경우에는, 두개의 프로그램을 별도의 프로그램으로 취급할 수 없기 때문에 프로그램 모두가 GPL로 취급되어야 합니다. 만약 두개의 프로그램이 커널과 컴파일러(또는 쉘, 에디터)의 경우과 같이 분리된 상태를 유지하면서 원래의 기능을 충분히 수행할 수 있다면 각각의 프로그램들을 별도의 프로그램으로 취급할 수 있습니다.
간단히 정리해드리면..
쉽게 말하자면 MySQL Driver를 독자적으로 개발해서 사용한다면 상용 제품이 MySQL을 Back-End로 사용하는 것도 가능합니다.
다시말하면 Comercial Product -> MySQL Driver -> MySQL DB 로 의존성을 가지는데, 이중에 MySQL DB는 앞서 올린 GPL에 따라 사용하는 방법에 따라 상업제품에도 포함시킬수 있습니다. 그러나 문제는 MySQL Driver 역시 GPL로 라이센스 되고 있으며 만약 이 MySQL Driver를 사용한다면 Comercial Product 역시 GPL이 되어야 합니다.
그런데 대부분의 상용 제품은 코드 공개를 원하지 않기 때문에 GPL을 따르지 않으려 하고 그러기 위해서는 MySQL 회사에게 상용으로 공개하지 않아도 되는 MySQL Driver를 라이센스 해서 사용해야 합니다.
아니라면 MySQL Driver를 완전히 독자적으로 구현 하면 MySQL DB를 상용제품에 포함시킬수도 있지요.
만약 제작하시는 제품이 오픈소스이고 GPL로 라이센스 하시려면 얼마든지 MySQL 사용하셔도 좋습니다.
그러나 그이외의 경우라면 MySQL 사에 돈을 지불하는게 맞겠지요.
윈 분 말씀에 거의 동의하는데 한 가지 추가해야할 것은 웹 솔루션 계약이
윈 분 말씀에 거의 동의하는데 한 가지 추가해야할 것은 웹 솔루션 계약이 대체로 소스까지를 포함한다는 것입니다. 특히 MySQL이 들어가는 것은 PHP가 많은데 이건 소스가 그냥 다 포함되죠. 그래서 GPL 하에서 얼마든지 판매 가능합니다. 자바도 SI의 경우는 소스 포함 계약이 대다수입니다.
그리고 MySQL JDBC 드라이버를 자체 제작해서 쓰는 곳도 있답니다. 3.23대 버전까지가 LGPL이기 때문에 그걸 기반으로 4.0대에 맞게 수정해서 쓰고 있죠. 그 회사에서 그 버전을 공개도 하려고 했는데 MySQL과의 마찰을 우려해서 공개하지 않았다고 하더군요.
페이지