애플 Perian, capriPerian 라이선스에 대해서 좀 의문이 생겨요.

병맛의 이미지

퀵타임은 아직까지 DivX & 자막 지원이 안 되는 재생기입니다. 그런데 Perian 프로젝트가 시작되면서 그게 가능해졌고
여기다가 .smi 자막 지원을 추가한 capriPerian 프로젝트가 우리나라에서도 시작되었습니다.

참고 링크입니다 : http://www.appleforum.com/application/53473-perian-plugin-sami.html

일종의 Fork 프로젝트인 셈이죠. 개발자가 밝힌 바, .smi 자막 관련 및 기타 기능들을 Perian에 포함시키고 싶었지만
Perian은 "Zero Configuration"을 표방한다면서 거부했다고 합니다. 그래서 따로 프로젝트를 열었다고 하네요.
Fork인 셈이겠죠. 그런데 좀 특이했던 게, Perian과의 라이선스 문제를 언급하면서 재배포를 자제해달라는
부탁을 한 점입니다. 일단 그렇다고 하고요.

그러던 중 오늘 뭔가가 터졌더군요.

http://www.appleforum.com/436585-post241.html

전에 해킨토시로 유명한 모 사이트에서 capriPerian의 파일 또는 링크가 한번 올라간 적이 있었습니다. 그 이후
그 모 사이트의 운영자가 공지로 capriPerian 파일 또는 링크글을 게시하지 말라는 글을 띄웠구요.

그리고 그 이후 두 번 정도 capriPerian의 업데이트 소식을 링크과 파일을 제외한 인용 문구를 사용하여 단순히
'소식'만을 올렸습니다. 그런데 이번에 문제가 됐던 건 그 단순한 '소식'을 알렸던 글 아래 비난성 댓글이었습니다.
(불펌이 아닙니다. 불펌이라고 한 건 저의 오류입니다)

덧글이 꽤 까칠하게 달렸습니다. 그래서 화가 난 개발자가 개발 중단 선언을 했군요.

http://www.appleforum.com/399578-post250.html

또한 개발자가 밝힌 Perian 프로젝트의 상황입니다. LGPL이긴 한데 여기 저기다 올려놔서 자꾸 질문 러시 들어오고,
혹은 변경한 소스에 대한 불평까지 자기들한테 오고 있는 상황에 대해 불만을 표하고 있네요. 뭐 예상치 못한 반응이었으면
당황할 만했겠습니다.

질문 들어갑니다.

1) Fork 프로젝트 개발자가 원 프로젝트의 사정을 보고선 자기 프로젝트의 배포에 제한을 거는 것을 어떻게 보십니까

참고로 Perian 프로젝트는 LGPL입니다.

2) 이미 capriPerian이라는 다른 프로젝트 이름을 사용하며, 원래의 Perian 프로젝트도 LGPL을 표방하는 이상, 둘 사이에
어떤 라이선스 문제가 있는 걸까요?

제 생각에 capriPerian은 원래의 프로젝트를 건드리지 않는 일종의 비공식 패치 적용판 정도의 위치인 것 같은데요.
이것까지 Perian이 트집을 잡거나 불만을 표하려고 할까요?

P.S. 모 포럼의 덧글 가운데

"차라리 유료화를 해버려서 불펌 행위를 막자"

같은 글을 보고 있으면 참... 재밌더군요.

소타의 이미지

이유야 어떻든 개인적으로 잘 쓰고 있는데 아쉽네요.. =_=

linlin의 이미지

개발자분이 라이센스에 대한 이해가 부족한 것 같네요....

LGPL 프로젝트는 원칙적으로 복사해서 수정 뒤 재배포가 "자유"입니다. 이것 못 막습니다.

다만 소위 이런식으로 프로젝트 코드 fork를 가능한한 삼가해야 한다는 것은 오픈소스 동네의 "불문율"입니다. 이것을 지키지 않아도 법적 처벌이나 책임은 전혀 없습니다. 다만, 이 동네에서 비난을 받을 것은 각오해야 합니다. project forking은 거의 금기시되기 때문에 fork를 하면 욕을 바가지로 먹을 각오를 하는 것이 정상입니다.

하나 잘 이해가 되지 않는 것은 Perian 원 프로젝트의 개발자들의 의사를 존중하는 것은 좋지만 (제출된 패치를 넣을지 말지는 그네들 맘대로 아니겠습니까...) 그것을 이유로 capriPerian인가요? derivative source code의 자유로운 이용을 제한하려는 것은 불가능합니다. 즉 해킨토시 포럼인가요? 제 3자가 capriPerian의 소스코드를 재배포하고 있는 것 자체는 비난해 봐야 소용없습니다.

한국 개발자들의 상당수가 내 코드는 배포를 내 마음대로 할 수 있다고 생각하는 경향이 있는데... 배포에 대한 제어권을 가지고 싶으면 절대 오픈소스 관련 라이센스를 쓰면 안됩니다. 오픈소스 라이센스는 예외없이 배포는 무조건 자유입니다.

어쨌든 여타저타한 이유로 capriPerian의 개발자분이 더이상의 개발을 중단하는 것은 당연히 문제가 없습니다. 하지만 라이센스가 LGPL인 관계로 제 3자분이 현재 capriPerian의 소스코드를 가져다 고쳐 개발을 계속하거나 혹은 재배포를 하는 것 역시 막을 수 없습니다. 다만, 비난은 할 수 있습니다.

Perian이 LGPL인 관계로 capriPerian이 만약 독립적으로 Perian과의 dynamic link만을 통해 작동할 수 있다면 capriPerian에 어떤 라이센스를 가져다 붙여도 상관은 없고 배포도 맘대로 제한해도 되겠지요. 이건 자세히 살펴보진 않았는데... 전개되는 상황으로 봐서는 capriPerian을 Perian 원본을 고치지 않은 독립적인 어플로 보기는 어렵지 않나 싶네요.

솔직히, 라이센스에 대한 이해가 조금만 더 있었더라면 애초부터 큰 분란이 일어나지 않았을 일일텐데요... 상황 돌아가는 모습이 좀 답답하네요.

김일영의 이미지

LGPL 라이센스가 걸렸다고 해서 그것만이 계약이 아니라고 생각합니다.
신의성실의 원칙이 지켜져야겠지요. 라이센스에 대한 이해와는 좀 다른 문제라고 생각되네요.

strongberry의 이미지

project fork가 금기시 된다니 금시초문입니다.

compiz를 fork 하여 beryl이 나왔을때 비난이 심했나요?
============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

linlin의 이미지

그럼 개발자 각각이 compiz를 fork하여 beryl, ceryl, deryl 식으로 프로젝트를 계속 만들면 오픈소스 프로젝트가 진행될 수 있나요? derivative project의 가능성을 오픈하기 위해 오픈소스 라이센스는 일단 project forking의 자유를 법적으로는 인정합니다. 하지만 실질적으로 forking을 하는 것은 필수불가결할 때가 아니면 하지 않는 것이 불문율입니다. compiz가 프로젝트 진행이 지지부진하고 있었으면 beryl을 forking하는 데 비난이 덜할수도 있었겠지만 forking은 일반적으로 오픈소스 커뮤너티에서 바람직하게 생각하지 않습니다.

김일영의 이미지

그런건 잘 모르겠지만
그 프로젝트를 끌어가시는 개발자에 대한 신의가 더 우선이라고 생각되는군요.
"오픈소스 커뮤니티란게 이런거야. 따라 해" 이런 건 아니잖아요.
리누스가 맨 처음에 리눅스를 오픈했을때 사람들이 리누스를 PM으로 인정 안하고 자기 멋대로 했으면 지금같이 됐을지요.

strongberry의 이미지

음. 제가 capriPerian을 잘 쓰고 있어서 옹호하는 경향이 없지는 않습니다만..-_-

Perian 쪽에서 SMI 자막 파일 형식에 대한 지원을 하지 않으려 하는 분위기에서 이를 지원하기 위해 프로젝트를 fork한 것도 바람직 하지 않은 것일까요?

capriPerian 개발자 분이 Perian 쪽에 관련 소스 일체를 전달 하시기로 했다니 일이 잘 진행되면 Perian 공식 빌드로 SMI가 지원될 것 같긴 하지만 말이죠. Compiz 에서 Beryl이 갈라져나왔다가 결국 Compiz-Fusion으로 합쳐진 예도 있어서 (물론 그 진행과정은 차이가 있습니다만..) 비난까지 받아야 할 일인지 저로선 좀 의문입니다.
============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

linlin의 이미지

이걸 이해를 잘 못하는 분들이 많네요.... 다시한번 밑줄 쳐 봅니다. "불문율"이라구요. 다른 말로 관습 혹은 관행입니다.

Perian에서 SMI 자막 파일 형식에 대한 지원을 안하겠다면 capriPerian이라는 프로젝트를 forking하는 것은 원칙적으로 carpiPerian 개발자의 자유입니다.

다만 forking을 하면 Perian 개발 커뮤너티쪽에서는 당연히 이것을 싫어할테니 forking을 하려면 원 프로젝트 쪽 개발자들이 싫어하는 부분은 감수해라 그겁니다.

이부분을 forking을 생각하는 개발자 쪽에서는 좀 요령껏 이용할 필요가 있죠. 어떤 패치를 기능상 필요하다고 보는데도 저쪽 프로젝트 진행자측에서 계속 받아들여주지 않는다면 그렇다면 나는 할 수 있는 옵션이 forking밖에 없다... 그래도 괜찮겠느냐? 같은 방식으로 패치 반영을 좀 더 강력하게 추진할 수 있습니다.

그래도 Perian쪽에서 반대라면요? forking의 명분도 섰으니 당연히 눈치 안보고 capriPerian 프로젝트를 forking하면 됩니다. 정리해보면 (1) perian에서 패치를 받아들이면 그쪽 프로젝트에 계속 참가하면 되고 (2) Perian에서 거부한다면 내 프로젝트를 새로 forking하면 되니 어떤 상황이 벌어지더라도 프로그램 개발은 진행되는 것이죠. 게다가 이렇게되면 해킨토시 동호회에서 패치된 Perian이든 capriPerian이든 맘대로 재배포를 하는 것도 신경 쓸 필요가 없어집니다.

참고로 지금 많이 쓰이는 xorg가 이런 식으로 forking해서 소위 사이비가 원조를 잡아먹기까지(?) 한 경우가 됩니다. XFree86의 느린 개발속도와 기능상 부족함에 불편을 느낀 개발자 몇몇이 코드를 통째 들어다 xorg 프로젝트로 완전히 forking을 했습니다.

하지만 일반적으로 forking은 바람직하지 않습니다. 예를들어, IBM이 리눅스 커널 소스를 가져다 IBMlnx같은 프로젝트를 새로 forking시키면 누구에게 바람직합니까? 따라서 가능하면 IBM역시 현재의 리눅스 커널 개발 프로젝트에 참여하는 쪽으로 방향을 잡는 것이 서로에게 유리합니다. 다만, IBM이 리눅스 커널 소스를 완전히 새 프로젝트로 forking하는 것 자체의 가능성은 완전히 자유로 열려 있습니다.

병맛의 이미지

세상은 라이선스가 다가 아니네요.

이번 경우처럼 재배포를 제한하고선 존중되지 않을 경우, 개발 자체를 손놓거나, 비공식적으로
제한된 이들에게만 몰래 제공하는 식으로 바꾼다면, 뭐라 할 수 없는 거였네요.

(물론 GPL이었으면 얄짤 없... ;ㅁ;)

cwryu의 이미지

오히려 capriPerian을 만드신 분이 라이센스를 위반하셨습니다. 이중적인 잣대를 사용하고 있는데요.

Perian을 가져다가 fork를 하던 말던 자기 마음이죠. 물론 내가 건드리지도 않은 수정사항때문에 자꾸 자기 포럼에서 귀찮게 하니 싫어하기는 하겠죠.

하지만 그 fork한 capriPerian도 LGPL로 배포해야 하며, 어디에 올리든 삭제 요청을 할 권리가 없습니다. 재배포를 제한할 수도 없고, 어디에 올리든 불펌도 아니고, 허락을 받을 필요도 없습니다. (지워져서 알 수가 없는데, 배포할 때 소스코드를 같이 배포하기는 했나요?)

linlin의 이미지

인용된 맥 포럼에 가 보니... 분위기가 좀 당혹스럽군요. capriPerian을 만드신 분의 라이센스 위반은 문제삼지 않고 오히려 타 동호회의 라이센스상으로는 전혀 문제가 없는 재배포를 라이센스 위반이라고 문제삼는 사용자들이 제법 되는데 솔직히 이래도 되나 싶네요. s모 아이디를 쓰시는 분이 홀로 외로이 정확한 상황인식을 하고 있는 게 눈에 뜨네요...

cwryu의 이미지

capiPerian을 만드신 분이 한가지 오해한 점이, 저작권법에 의한 배포/복제/개작의 권리는 배포하는 순간에 결정되고 낙장불입, 아무리 저작권자라고 해도 임의로 바꿀 수 없습니다.

예를 들어서 알집 프로그램의 최신 버전은 영리 단체에서 사용할 수 없지만, 그런 제한 없이 배포할 수 있었던 과거 버전의 배포와 사용을 임의로 막지는 못합니다.

가끔 보면 임의로 권리를 박탈할 수 있다고 주장하고 있는 라이센스가 있는데 실효력을 인정받지 못합니다. 과거에 다윈 코드를 맨 처음 배포했던 APSL 1.0이 그런 식으로 "애플이 원하면 언제든지 권리가 없어진다"는 식으로 되어 있지만 인정받지 못한다는 비아냥을 받았습니다.

그러므로 Perian이 한번 LGPL로 배포된 이상, Perian 프로젝트에서 fork를 싫어하고 capiPerian을 비난할 수는 있어도 법적으로 capriPerian에 대해 LGPL이 정하는 외의 어떤 책임도 요구할 수 없습니다. 즉 애초에 capriPerian의 배포를 제한해야 하는 이유가 틀렸습니다.

김일영의 이미지

개발 안하신다는데 무슨 상관입니까;;;
배포가 제한되어 있지 않으므로 불평하던 분들 중에 누군가 개발하시면 되는거죠;;;
말한놈이 개발한다 이게 법이잖아요;;;

cwryu의 이미지

더 이상 개발을 하든 안 하든 배포를 하든 말든 위반했다는 사실은 돌이킬 수 없습니다.

capriPerian을 다운로드한 분들은 LGPL에 따라 소스코드를 요구할 수 있고, Perian 저작권자들이 마음 먹으면 위반 행위에 대해 고소할 수 있습니다.

linlin의 이미지

개발을 안하는 것은 개인의 자유라서 뭐라고 언급 할 것이 없습니다. 다만, LGPL라이센스 때문에 capriPerian 소스 코드는 적어도 공개 요청이 들어오면 공개해야 할겁니다. 그런데 이 개발자분 현재 capriPerian 소스코드를 받아들일 리 없는 Perian 프로젝트에 제출하고 다른 곳으로는 공개하지 않을 생각인것 같은데... 일단 상황 전개까지 봐야겠습니다만.

저같으면 그냥 소스코드 공개하고 "너네들이 알아서 해라 난 안한다..."한 다음 발 빼버릴것 갈은데... 왜 저러는지 잘 모르겠습니다. 상대방 동호회의 누군가가 LGPL이니 소스 코드 공개해라고 요청이 들어오면 공개하면서도 별로 기분이 좋지 않을테고, 공개하지 않으면 공개 압박에 시달려야 할텐데 잘은 모르겠지만 뭔가 내부사정이 있지 않나 싶네요.

병맛의 이미지

시간이 좀 지나고 나니 capriPerian 개발자의 처지도 좀 이해할 수 있을 것 같습니다.

* 분명 Perian과 자신이 추구하는 바가 차이가 나고
* 하지만 Perian 프로젝트는 자신이 작업한 부분을 집어 넣어주지 않고
* 따로 가지를 치고 나가자니 시간도 부족하고 생업도 바쁘고 어쩌고 저쩌고...
* 비공식 수정판을 배포하고 싶은데 Perian측의 반응이 좋지 않았던 선례가 있으니

게을러서 링크를 달아드리진 못 하겠는데, capriPerian님이 Roadmap(?)을 밝힌 것이 있습니다.
그냥 Perian의 정식 릴리스에만 대응을 하고 앞으로의 기능 추가는 생각하지 않고 있다고요.

Fork는 원치 않지만 어쨌든 .smi는 쓰고 싶고... 그러니 "몰래 멀티"하는 거죠.

솔직히 폐쇄적인 한국 웹 환경, 그 중에서도 또한 소수인 몇몇 맥 커뮤니티를 다른 나라
사람들이 얼마나 알겠습니까. capriPerian이 배포된다 해도 그 Feedback이 Perian으로 깔까요?
capriPerian으로 오겠죠.

어쨌든 감당하지 버거운 측면이 있다 보니 배포와 소식 알림에 민감했던 것같습니다. 게다가
이번 경우엔 악플 문제까지 겹쳤죠.

linlin의 이미지

이 사건을 관심있게 보고 있는 이유가... 사실상 이 일은 capriPerian 개발자분이 LGPL에 대한 이해가 조금만 더 있었더라면 애초부터 발생하지 않았을 문제여서 그렇습니다.

이분의 사정은 이해가 됩니다. 엄마친구딸님이 바로 위에 잘 적어주셨고... 그런데 capriPerian을 Perian쪽에서 비난을 하든지 말든지 capriPerian 프로젝트를 fork하는 것은 애초부터 전혀 문제가 없었습니다. 몰래 멀티 안해도 되는 일을 몰래 멀티하다보니 재배포가 자유인 소프트웨어의 재배포를 제한하려고 이래저래 신경을 써야 했고... 감히 원저작자의 요구도 존중하지 않는 커뮤너티의 행동에 당연히 감정이 상할 것이고 그 결과가 애꿎은 프로젝트의 중단 아니겠습니까.

하지만 LGPL을 제대로 이해하고 있었다면 재배포가 완전 자유인 라이센스를 위반하면서까지 재배포 제한에 신경 쓸 일도 없었을 것이고 이렇게 되면 해킨토시 동호회에서 자신의 프로그램을 재배포하는 것은 오히려 바람직한 일로 받아들일 수 있었을 겁니다. 혹은 Perian 프로젝트에 fork 필요성을 적절히 잘 납득시켜서 forking 대신 원 Perian 프로젝트에 참여하는 가능성도 열려 있었거든요. 어느 경우든 LGPL의 의미와 실제 오픈소스 개발과정에 대한 개괄적인 이해만 있었어도 열려 있던 가능성이죠.

생각보다 LGPL 오픈소스 라이센스의 설계가 정교하네요. 조항만 따라가면 이런 바람직하지 않은 경우가 초래되는 것을 애초부터 막아줄 수 있으니까요.

김일영의 이미지

본질은 개발자와 사용자가 완전히 갈려 있는 상황에서 사용자측이 신의를 저버렸다는 겁니다.
일차적으로 그게 문제인거죠. 라이센스가 어떻든 그것은 개발자와 원 소스 주관 커뮤니티간의 문젭니다.
라이센스를 운운하기에 앞서 사용자들은 그럼 LGPL에 부합하는 방식으로 참여했습니까?

전 사실 쓰지도 않는 물건입니다만, 그간 내용 보니 GPL이란 말도 생소할 적에 스스로 뭐 만들어 배포하면 고마와하기는 커녕 욕질이나 해대던 그때 그시절 모습 그대로였던 것 같은데 (요즘도 사실 그닥 다르지는...), 그것이 문제의 핵심이지 개발자와 LGPL 문제가 핵심이겠습니까?

아마 그 개발자분이 GPL에 대해서 여기서 논하시는 분들보다 결코 모르지는 않았을거라 생각합니다.
개괄적인 이해도 없다고 깎아내리는 분들 과연 책임있는 말씀이신지 의심스럽습니다.
열길 물속은 알아도 한길 사람속을 모른다는데, 라이센스 찬양에 빠져 너무 무책임하게 단언하시는 듯하고, 제 3자인 저같은 사람조차 언짢습니다.

linlin의 이미지

라이센스를 위반하도 괜찮을 정도로 개발자의 개인적요구가 중요한 겁니까? 개발자의 개인적 요구도 당연히 라이센스 틀 안에서 이루어져야죠.

LGPL은 capriPerian을 가능하게 한 다른 Perian 개발자들의 요구입니다. capriPerian 개발자는 이것을 자기 맘대로 무시해도 되나보죠? 내 요구가 중요하다면 다른 개발자들의 요구도 중요하기 마련이고 Perian 개발자들은 LGPL을 준수해달라고 요청을 한 거에요.

병맛의 이미지

끝으로 제가 이번 일로 깨달은 것입니다:

1) 역시 오픈 소스 킹왕짱:

mplayer는 뭐 .smi 문제 같은 건 모르죠. 게다가 Totem은 통합 자막 같은
더 앞선 기능을 추가... ㄷㄷㄷ

게다가 capriPerian을 쓰면 이른바 윈도즈 미디어 센터의 선배격인
FrontRow와의 연동이 매우매우 깔끔하기 때문에 mplayer보다 선호하는 것도
크지만
(자막 & DivX 파일을 같은 디렉터리에 넣으면 따로 자막을 동영상에 입히지
않고도 일반 재생기들처럼 FrontRow에서 바로 자막을 볼 수 있습니다),

capriPerian + 퀵타임 플러스 + VisualHub 조합이면 자막을 동영상에
입힌 다음 AppleTV나 아이팟 터치용(.mov)으로 인코딩하기가 간편해지기 때문입니다.
AppleTV나 아이팟 터치는 아직까지 자막을 지원하지 않기 때문이죠.

하지만 역시 오픈소스였다면 상용인 VisualHub 대신에 dvdrip이나 mencoder를
쓰는 편이 나아 보입니다. 퀵타임과 VisualHub는 둘다 구입해서 써야 하죠.
또한 DVD을 리핑하는 deCSS 역시 오픈소스고요.

2) 역시 우리나라는 좀 따로 노는군.

.smi를 사용하는 나라는 우리나라밖에 없는 건 아닐까 하는 생각이 듭니다.
Perian 프로젝트도 .srt와 .ssa는 지원을 하죠. 사실상 표준은 .srt가 아닐까
싶습니다. .sub 파일로부터 약간의 수작업을 거쳐서 만들어내죠.

만약에 우리나라도 .srt가 널리 쓰였다면 capriPerian 자체가 필요없었을 수
있습니다. 저도 DVD를 리핑해서 보는데, 파일을 700M 단위로 뽀개기보단 좀 크더라도
깔끔하게 한 개 파일로 리핑하는 걸 선호합니다. 게다가 .mkv부턴 자막을 아예
포함시킬 수가 있죠. 파일 하나면 끝납니다.

그런데 정발이 안 된 일본 애니메이션이라면 리핑을 해도 한글 자막은 나오지 않죠.
.srt로 추출한 일어나 영어 자막을 복사하고선 시간에 맞게 .smi 자막의 내용을 갖다
붙이는 노가다가 필요합니다. -_-;;;

애초부터 .srt가 제공되었다면, 여러 개로 나뉘어진 DivX 파일용 자막도 하나로 합치는
방법도 더 수월했을텐데하는 아쉬움이 남습니다.

이번 사태의 배후에는 .smi 파일의 처리에 대한 OS X의 불편함이 자리잡고 있지 않나
싶습니다.

3) 맥이 인텔로 갈아탄 다음에 아직은 적응기구나

그래도 점유율이 5% 정도 되는 운영체제가 아직 자막 하나 제대로 처리하지 못 한다는 게
좀 어의가 없긴 하지만, 어쨌든 자막의 주 용도는 불법 자료인 DivX 용이었고 DivX는
인텔 시피유의 전유물이었죠.

좀 더 시간이 지난다면 capriPerian이 아니더라도 Perian의 기능에 아쉬워하고
Zero Configuration이 마음에 차지 않는 사람들이 Fork을 하고 나오지 않을까 하는
생각이 듭니다. 아직까진 과도기라는 거죠.

단, .smi 문제는 2)에서도 언급했듯이 한국 말고는 별로 아쉬워할 나라가 없어 보입니다.

그럼 Perian에서 안 해준다면 우리나라에서 직접 하거나, 새로 Fork되는 프로젝트에서는
지원이 되도록 어떤 식으로든 강구를 해야겠죠.

4) 3)과 맞물려서, PPC에서만 머물던 맥 유저들이어서 그런지 오픈소스에 대한 이해가 많이
부족하다는 걸 이번 일로 새삼 알게 되었습니다. 뭐 PPC 시절에도 오픈소스라든가 리눅스가
지원되지 않았던 건 아니지만 맥 유저들의 대다수는 오픈소스를 접한 일이 별로 없어 보이네요.

이제 결국 인텔의 세상이 왔고, 인텔은 GPU마저 코어로 흡수하여 VGA 카드 없는 세상을
꿈꾸고 있습니다. 일반 PC에서도 OS X가 깔리는 시대가 왔죠.

오픈소스와 OS X 역시 더 가까워진 겁니다. 갈등과 충돌보다는 이해와 협력으로 공동의 이익을
실현해가면 좋겠습니다.

kall의 이미지


불펌에서 웃으면 되는건가요 ㅋ

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

vamf12의 이미지

한군데 더 있습니다. ㅋ

Quote:
만약 영문 Perian 측에 알려져서 중단해달라는 요청이 들어오면 capriPerian은 그 즉시 접어야 함은 물론이고, 라이센스 위반에 따른 책임은 개발자인 제가 지게 됩니다.
- capriPerian의 성명서에서 발췌

domain808의 이미지

capriPerian 공개하고 개발한다면 문제가 될부분이 아닌것 같은데요.
fork와는 다른 개념같군요.
분명 한국사정에 맞게 smi기능을 추가하는것인데 Perian의 취향에 따라 거절을 당했다면.
독립적으로 smi지원 capriPerian을 개발한다면 Perian은 이에대해 뭐라고할 부분은 아닌것 같습니다.
모두 LGPL에 정의에 따라야 한다면.
굳이 Perian이 개발중단을 요청한다면 먼저 Perian이 오픈소스진영에서 빠지며 Perian에 쓰인 오픈소스를 삭제해야 하며.
그런후에야 순수개발자로써 저작권에 대한 권리를 주장하여 개발중지 요청을 할수 있을것 같네요.
다른님들 말씀대로.
GPL/LGPL 규약도 중요하지만 개발자의 권리도 존중해줘야 하지만.
오픈소스진영에 발을 들여놓는 자체가 그 코드를 썼다는 자체가 GPL/LGPL에 따른다는 책임따르는것 아닐까요?

JY의 이미지


안녕하세요. 전 x86osx 사이트의 한 회원입니다. 첫 글에 잘못 알고 계신 사항이 있어 글을 남깁니다.

Quote:
해킨토시로 유명한 모 사이트에서 자꾸 capriPerian을 불펌을 해가서 올리길래 삭제 요청을 했더니 덧글이 까칠하게
달렸습니다. 그래서 화가 난 개발자가 개발 중단 선언을 했군요.

상황은 capri 님의 파일이나 링크를 올렸던건 한번으로 알고 있습니다. 그 이후 운영자님이 공지로 capri 님의 파일이나 링크글 게시하지 말라는 글을 띄웠구요.

그리고 그 이후 두번정도 capriPerian 의 업데이트 소식을 링크과 파일을 제외한 인용문구를 사용하여 단순히 '소식'만을 올렸습니다. 문제가 됐던건 그 단순한 '소식' 을 알렸던 글 아래 비난성 댓글이 였습니다. 고로 해킨토시 사이트에 자꾸 불펌을 했다는 말씀은 잘못된 것입니다.

이제와서 원인이 무엇이였다라는게 왜 중요하냐 하실 수도 있지만, 해킨토시 사이트가 싸잡아 욕먹고 있는 시점에 마음대로 불펌을 하는 그런 범죄 소굴로 자꾸 인식이 되는게 안타까워서 입니다. 해킨토시 사이트를 아끼고 사랑하는 한 회원으로써 감히 말씀드리건데 그곳의 회원 모두 애플이라는 회사에서 나오는 정신이 깃들었다고 느껴지게 하는 물건과 소프트웨어를 사랑하는 사람들입니다. 해킨토시를 pc 에 깔아봄으로써 맥이라는 운영체제에 매력을 느껴 실제 맥을 사는 분들도 부지기수구요. 이글을 쓰는 저 또한 다음 업그레이드를 맥으로 고려하고 있습니다.

저는 개발자가 아닌 평범한 이용자여서 개발과 관련된 라이센스라든지 folk 라든지, 전문적인 지식은 전무합니다. 다만 현재 욕을 먹고 있는 사이트의 한 회원으로 안타까운 상황에 글을 남기게 됐습니다. 제가 남긴 이 댓글이 또다른 비난의 화살이 되어 돌아오지 않기만 을 바랄뿐입니다.

좋은 하루 되십시오.

onion의 이미지

1. 재배포에 대해서....
재배포를 제한한데는..이미 전례가 있습니다.
readme를 비롯한 파일 자체를 몇개 잘라버리고 배포를 한거죠.
readme에는 license등도 있을것인데...
해도 되는게 있고.. 해서는 안되는게 있는거죠.

2. 개발하시는분의 license 숙지 미흡에 대해
license를 숙지하지 않으신게 아닙니다.
다만 이번 사건으로 왜 재배포를 명확하게 막았는지에 대해 의견을 적어놓으셨지요.
왜 재배포를 제한하는가에 대한것까지 개발자가 미리미리 항상 설명해놓아야할 의무가 있었던가요?

3. bug report에 대해...
opensource 또한 LGPL은 개발자가 그것에 대해 항상 feedback을 해줘야 하나요?
source의 공개로 1차적인 의무는 다한게 아닙니까?
software개발이 생업이 아닌 취미로하는 개발자라면
그로인한 의견제출이 그리 반갑지 않을수도 있습니다.

4. 재수정에 대해.
간단합니다. capriPerian을 LGPL이라고 생각하고
배포정책이 맘에 들지 않는다면..
위에 다른분들이 적은것처럼 project자체를 또 fork해버리면 되지 않나요?
제가 봤을때는 이게 제일 간단한 부분 같습니다만....

상대방의 생각과 입장을 잘생각해야되는 부분이 아닌가 싶습니다.
license도 당연히 생각을 해야하지만 왜 이렇게 되었는가도 같이 생각할 필요가 있다고 봅니다.
GPL/LGPL도 물론 중요합니다만... 개발자의 생각이 source code의 공개를 동반하는 의견이 있다라고 생각한다면
그 의견 당연히 존중해야 하는거겠죠.
glibc잘못써서 그 PC날아가면 본인책임.
그때문에 beta나 alpha쓰지말라고 말렸는데 문제생겨도 본인책임...이런거 아니겠습니까.
개발자로서 공개의 의무는 가져가야하지만 그에 따른 걱정이 있어서

"야..이건 좀 아닌거같아.. 엔간하면 좀 지켜줘.. 노력해볼께. 아직 안정화가 덜됐고 이런저런 이유가 있다."

라고 생각하는 개발자가 나쁜건가요..-.-?
물론 어떤사람이 100% 잘했고 잘못했고를 따지자는게 아닙니다.
이미 일은 벌어졌고

"죄송합니다"
라고 한마디로 끝날 시기는 지났다는게 문제죠.

저도 license라는걸 잘 안지키는 편에 속합니다만...(그것이 법율이 된다면 엄청 안지키는 편이죠)
그래도 이건 좀 아닌거같습니다.(이유는 방금전에 설명했으니 괜찮겠죠?)

개인적으로 개발하신분과 약간의 친분이 있어 좀 심하게 휘어서 글을 적기는 했습니다만
오는 감정이 약간 보이길래 보내는 감정도 조금 실어봤습니다.

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

vamf12의 이미지

실상 문제는 위에도 한분이 언급 하셨지만, 해킨토시 사이트를 범죄자 소굴로 만들었다는 데있습니다.

재배포는 제한됩니다. - 만약 제포시에는 개발 중단하겠습니다.
또는
재배포를 제한 했지만, 이를 지키지 않기 때문에 개발 중단하겠습니다.

이런식의 자신의 입장을 밝혔으면 별 문제 없었을 겁니다. 그런데!

불펌으로 인해 개발 중단합니다.
또는
모든 법적책임이 저에게 오기 때문에 개발 중단합니다.
또는
개발자가 정한 라이센스를 지켜 주셔야 합니다.
무신.. -_- LGPL이 되어야 마땅한 프로그램을 불펌했다고 매도를 하고 있습니다.

도의적인 책임을 물론 해킨토시 싸이트측에 있습니다. 비난받아도 마땅합니다.
그렇지만, 라이센스를 위반하는 불법적인 행동은 한적이 없음애도, 매도를 당하기 때문에 반발이 거센겁니다.

cwryu의 이미지

개발자 분의 글들을 읽어보시면, 개발자 분이 부탁 차원에서 재배포를 제한하는 게 아니었습니다. "불펌", "출처도 밝히지 않으시고", "개발자가 배포했을 때 말했으니 지켜야지" 이런 말은 부탁이나 편의 차원에서 말하는 게 아니잖습니까? 이런 제한을 할 수 없게 되어 있는 LGPL을 이해하지 못하시고 이런 제한을 걸 수 있는 게 개발자 자신의 권리라고 생각한 거죠.

소스배포도 안 된 것 같지만, 만약에 누군가 fork해서 gapriPerian이라는 이름으로 fork해서 배포했다면 조용했을 것 같진 않군요.

병맛의 이미지

IF 놀이입니다. 질문 1번과도 연관 있습니다.

"간단합니다. capriPerian을 LGPL이라고 생각하고
배포정책이 맘에 들지 않는다면..
위에 다른분들이 적은것처럼 project자체를 또 fork해버리면 되지 않나요?
제가 봤을때는 이게 제일 간단한 부분 같습니다만...."

제작자가 배포 자제를 요구한 상황에서 Fork를 한다면, 역시나 마찬가지로
배포 자제를 요구한 취지를 거스르는 게 아닐까요?

물론 이번 사건은 배포가 아니라 악플이 문제였지만, 배포하기와 Fork하기
둘 다 결국 배포하는 건 마찬가지 아닌지요?

linlin의 이미지

아니에요. 이건 소스코드 배포보다 소스코드 수정의 측면에서 보는게 좋습니다. 그래서 forking이라는 단어 자체를 LGPL에서는 아예 거론조차 안하는 겁니다. 소스코드 수정의 자유가 어쩌고저쩌고 하는 것이죠. 즉, 프로젝트 내에서 소스코드를 수정할 것인지, 프로젝트를 forking해서 소스코드를 수정할 것인지는 상황의 필요성에 따라 판단해야 할 문제거든요. 다만 어느 경우든 소스 코드 수정의 자유를 보장하고 있는 것이 (L)GPL의 포인트입니다.

즉, 제작자가 forking 자제를 요구한 상황에서라도 이것이 존중할 필요성이 없다면 무시해도 되는 겁니다. 그래서 제 경우에는 예로 원 Perian 제작자들에게 "너네들이 내 패치를 안받아 주면 난 forking 밖에 선택권이 없어진다... 그래도 괜찮니?" 식으로 원제작자들에게 물어볼 필요가 있었다고 하는 겁니다. 그냥 가뿐히 원제작자들의 요구를 무시하면 저쪽에서 원성이 자자할텐데 어차피 forking할 것이면 비난을 좀 덜 받고 forking하는게 바람직하지 않냐 이겁니다.

forking을 자제해달라는 Perian 원 제작자들의 요구는 "존중"할 필요는 있되 "따를" 의무는 없습니다. 라이센스가 LGPL이기 때문입니다.

김일영의 이미지

일단 제가 맥을 안 쓰는 관계로 Perian이라는 프로젝트도 라이센스가 과연 어떤건지 잘 모르겠습니다.
하지만 분위기를 보아하니 Perian 역시 GPL이나 LGPL을 그대로 따르지는 않는 것 같습니다.
그대로 따른다면 capriPerian 같은 가지가 나온다고 해도, 역시 라이센스의 준수 여부만이 문제지 Perian측에서 개발과 배포에 이러쿵 저러쿵 할 이유가 없지 않습니까.
보아하니 GPL 라이센스를 가지고 문제삼는다면, capriPerian의 문제가 아니라 Perian부터 문제가 되는 것 같습니다. (아니면 아예 GPL과 무관한 프로젝트였든지요) 그리고 이 문제가 어쨌거나 capriPerian의 개발이 중단된 상황의 원인은 아니므로, 별도로 논의되어야 할 부분입니다. 개발자의 라이센스에 대한 이해 운운은 논점을 이탈한 것으로밖에 보이지 않습니다.

그간의 글로 봐서 capriPerian는 Perian의 기능을 그대로 쓰고 싶어하는 사람들 입장에서 .smi를 쓰고 싶은 요구를 추가로 구현해주는 것에만 국한된 프로젝트였던 것 같습니다.
그래서 개발자는 Perian 자체에 .smi에 대한 지원이 추가될 수 있도록 희망을 했나 본데, Perian 쪽에서 강력하게 반발을 한 것으로 보입니다.
그래서 개발자분은 Perian에 불필요한 피드백이나 심기를 거슬리는 일이 없도록 .smi 지원만을 희망하는 사용자만을 대상으로 묵시적으로 운용되기를 희망한 것 같습니다.

그런데 소위 '악플'을 보니 한마디로 '너 잘났다. 내가 니 말 왜 듣냐' 이런 식인듯 합니다.
이건 라이센스에 대한 문의나 항의가 아니라, 사용자 대 개발자의 문제입니다.
만약 사용자측에서 "Perian의 라이센스가 GPL인데 너 소스 공개해라" 이런 것이었다면 라이센스가 문제의 핵심이라고 보아야 하겠습니다만(ipTime 건 같은...) 현 상황은 그런 것하고는 상관이 없는 문제인 것 같습니다.
혹은, Perian의 라이센스가 GPL과 상관이 없더라도, 사용자측에서 개발자에게 Perian의 라이센스 체계를 따르지 않는 것을 문제 삼았다면 그건 또 다른 문제가 될 것입니다.
하지만, 역시 그런 것도 아니므로, 여하간에 현 상황은 라이센스에 대한 이해와는 상관이 없는 문제라고밖에 보이지 않습니다.

따라서 현 상황은 '자기가 개발하지도 않은 기능에 대한 질타'를 포함한 '악플'에 짜증난 개발자가 개발을 중단한다는 전형적인 스토리로 보입니다. 여하튼 아쉬운 일입니다.

vamf12의 이미지

전형적인 물타기 라면 물타기 일수도 있겠습니다만...

1. 문제의 시작은 개발자의 부탁을 무시한 해킨토시 사이트에 있습니다. (동시에 인신공격성 악플까지.. -_-)
2. 개발 중단을 선언함과 동시에 해킨토시 사이트를 범죄자 집단으로 만들었습니다.

1번 문제는 역시나 100%해킨토시 사이트가 잘못했고, 도의적인 책임을 져야 합니다.
2번 문제에서 라이센스 문제가 나오는 겁니다. (기존에 소스를 공개 했건 말았건이 중요 한게 아니라... 역시 포인트는 불펌이지요 ㅎㅎ)

그리고 아쉽게도 이쓰레드는 GPL/LGPL에 관한 이야기로 시작했기 때문에 1번을 문제삼는게 논점을 회피하는 것 같습니다.

karoora7의 이미지

그전에 주변의 사용자들이 더 문제로 보이는군요.
이번 문제는 원칙의 문제 보다는 그 주위를 둘러싼 자기 식구 감싸기 식의 사용자들의 의식이 문제로 보입니다.

커지지 않을 문제를 어쩌면 개발자분께서 일루러 의도한 듯한 것으로도 보이네요.

아무튼 사용자 의식은 좀 생각해 볼 문제 같습니다.

domain808의 이미지

모유저가 불펌을 해서 올렸습니다. 개발자가 배포한 사이트에서 공지내용을 봤는데도 불펌을 했을 정황은 아닌 상황으로 판단됩니다. 왜냐면 그 전에 이미 해킨토시 사이트에선 불법자료만이라도 없애자는 취지로 몸살을 앓았고 대부분의 회원들이 동의를 했던 상황이기 때문입니다. 그리고 대부분 다른쪽에서 퍼오거나 아님. 개발자의 배포제한이나 라이센스 개념을 이해못하는 상황에서 많이 벌어집니다.

많은 회원들이 그져 공개자료가 올라왔다고 생각했었지. 특별히 제한적인 자료라고 생각하진 않았습니다.
capriPerian을 특별히 사용하는 사람들이 많지 않았던것 같습니다. 저도 최근에야 알았죠.
하지만 해킨토시 유저중 배포제한에 대해 알고 있는 사람이 개발자에게 이사실을 전한것 같고.
개발자는 글을 공지했던것으로 압니다.
일단 시작부터 마찰이 있었죠.

한마디로 뜬금없이 개발자가 나타나. 마치 해킨토시 사이트에서 알면서도 방관했다는듯이. -.-
그러려니 했습니다.

분명 예전에도 몇번 그런적이 있었고. 저도 한번 그런 실수를 했었죠. 배포처에서 받은 자료가 아니라 다른 사이트에서 받은 자료를 무심코 올려서. 또한 그것을 수정해서.,.-.-
알고있는 유저가 바로 댓글을 다셨고. 바로 지웠던것으로 압니다.
충분히 그렇게 해결될수 있는 문젠데.
1차적으로 그렇게 사건은 전개가 되었습니다.
그 부분은 운영자에게까지 방관을 했다는 심증으로 쪽지를 보냈던것 같고. 운영자는 공지를 하셨죠 바로. (아마 짜증나셨을껍니다)

중간 중간에 또 일이 있었는지는 모릅니다.
-.- 그정도로 보여지는 부분이 아니었고 많은 회원들이 관심을 갖지 않았던 사안이었죠,
분명 운영자는 불펌을 금지했고.
회원들은 이해를 했습니다.
개발자가 원하니..-.-

그리고 언젠가 그냥 새로운 소식을 전하는 글이 간단하게 올라왔더군요.
그리고 잊고 있었습니다.

분명 저도 개발자가 조금은 민감하다 생각했지만. 한때 본인도 개발자였고 그편에서 생각해서는 고생해서 만드는데 그정도 배포제한은 개발자의 몫이 아닐까 생각을 했죠.
그렇다면 일반 회원들의 생각은 어떻다고 생각하실지.
그런 생각까지 운영자나..상위회원들이 컨트롤할수는 없는겁니다.

추후에 운영자에게 삭제를 요구하는 쪽지가 전해졌고. 이런 저런 사실이 알려지면서. 악플성 댓글이 달리게 되었던거죠.
-.- 전혀 모르고 있던 사실이라.

어찌되었건 그런 사실로 악플성 댓글이 달리게 된것이고.
개발자는 그것을 캡쳐하여 배포처인 애포에 글타레에 개제를 하며 개발중지를 공지했던 겁니다.
모 해킨토시 사이트에서..어쩌구..저쩌구..모 해킨토시 사이트가 얼마나 있을꺼라 생각하시는지..

저는 그때서야..
운영자의 "너무들 하십니다.."라는 타이틀의 게시글을 읽으며 알게 되었고.
그때는 이미 블러그나 다른 사이트에 해킨토시 사이트의 무분별한 불펌으로 인해..어쩌구 저쩌구 사태가 벌어진것이죠.

라이센스 문제는 그 이후에 제가 거론한겁니다.

불펌으로 공방이 있어 악플로 맘상한 개발자가 개발중지 이유를 공지한 사이트가 배포처겸 맥커뮤니티에서 인지도가 높은 곳이라는 점.

문제는 해킨토시 사이트는 역시 불펌이 난무하고 그곳의 유저들 조차 그 수준이라는 평가를 받았고. 운영을 위한 기부제 형식의 불법자료실은 .. 해킨토시 사이트를 깡패소굴로 전력시켰죠.

저 또한 활동은 활발하게 하진 않지만. 대부분의 맥커뮤니티의 회원이고.
그나마 해킨토시 한대를 사용하기 때문에 해킨토시 사이트에 애착을 가지고 활동을 하고 있는 입장에서 가만이 있을수가 없다고 판단했습니다.

애포에서 편견의 시선으로 해킨토시가 불펌과 불공유의 온상이라는 식의 글들과 회원들의 수준을 논한다면. 누구 하나라도 그중의 댓글쓴이의 실수로인한것이지 사이트의 회원들을 매도하는것은 옳지 않다고 옹호를 글이라도 올라왔으면 그나마 불쾌하지는 않았겠지요.
그리고 그렇게 따진다면 라이센스의 규약에 위반되는 capriPerian을 공식 배포하고 글타레를 유지하는 애포또한 피해갈수 없는 상황입니다.
하지만 그런 저런 글도 없었고.

모든일은 벌어진다음. 라이센스 문제가 거론된겁니다.
불펌의 문제였다면 라이센스 이야기 당연히 나와하는 순서는 지당한것이고.

이 순간 악플성댓글을 쓴 회원은 조연에 지나지 않고.
전체적인 상황으로 봐선 감독과 주연을 개발자가 맡고 있기때문입니다.

개발자의 공지로 일단락 되었지만. 결국에는 개발중지와 소스를 넘긴다는. ^^
하지만 의도를 알수 없군요.
분명 Perian의 까칠한 배포에 대한 반응과..예전에 reject당한 소스를 그쪽으로 넘겨 공개를 한다는것이..
Fork가 되더라도 그냥 애포에 공개하면 마무리가 되는것이 아닐까 생각을 했는데.
Perian이 reject한 소스를 Perian에게 공개한다는것은 공개를 안하다는것과 별반 차이가 없지않나 생각됩니다.
-.- 이건 저만의 생각입니다.
전반적인 상황을 봐서 공명심으로 개발을 유지하는것이 아닐까란 편견을 가졌고. 현재 개발중지와 소스에 대한 내용을 봐서도 그 마음은 좀처럼 사라지지 않고 있습니다.

어떻게 해석할지는 모르지만.
제가 여지껏 알던 오픈소스에 대한 생각은.
복잡하지 않다고 알고 있습니다.

굉장히 복잡하게 생각하시는분들이 많아서.
해당되는 LGPL은 그냥 공개하면 됩니다.
만약에 Perian이 뭐라고 한다면..그냥 알았다~하면 됩니다.
그들도 오픈소스를 사용하여 만들기 때문입니다.
만약에 순수한 자신들만의 소스였다면..그리고 예전의 Fork당한맘이 아직까지 담고있다면..오픈소스진영에서 탈퇴를 하면 되겠죠.
오픈소스 진영에서 부지기수인..그런일에 대한 민감한 반응을 보이며 재개발자에게 까지 영향을 준다면..Perian개발자가 문제가 있는겁니다.
..
그냥 공개하고..capriPerian이든..budPerian이든..뭐든 재개발되어지면..그들도 LGPL에 따르면 되는것이고.
오픈소스가 이런 번거러움이 있다면..
그냥 돈주고 소스를 사지~ 무슨 오픈소스를 쓰겠습니까?

특별히 지금 상황에선 개발자의 공명심도..악플성댓글도.. 문제가 아닌것 같군요.

한국의 폐쇄적인 개발환경.
그것도 더 열악한 OSX의 개발환경의 오픈소스 진영의 단면을 보여주는것이 아닐까? 합니다.

저도 한국내의 개발자가 소스까지 공개하며 만들었던 저작물에 대해..그다지 기억이 나지 않습니다.

병맛의 이미지

해당 커뮤니티간의 관계가 흥미로운 일이긴 하나, 제가 원했던 토의의 범위 안에 들어와
있지는 않는 것 같습니다.

그리고 capriPerian 개발자가 마지막으로 남긴 글을 제가 이해한 바는,
capriPerian의 존재를 지우고, 다만 소스의 형태로 Perian 측에 제공하면서 마무리를
지으시려는 것 같습니다. 이렇게 되면 capriPerian의 공개 문제도 모두 무(Zero)로 돌아가는
셈이겠죠.

그러므로 LGPL와 관련시켜서 여러 분들 사이에 더 이야기가 오가는 것은 이제 적당하게
보이지 않는 것 같습니다.

그건 그렇고요. 이 토의에서도 특정 프로젝트에 묶이지 않고, 객관적인 시각에서 LGPL 또는
Fork / 재배포에 관련하여 이야기가 오갔으면 좋겠습니다.

병맛의 이미지

네, 맞습니다.

그런데 "공식적인" 면들만 보면, 이제 더 이상 capriPerian은 존재하지 않습니다. 그리고
이전의 존재에 대해서도 부정되고 있는 셈입니다. 게시판에 올라온 릴리스 글까지 지우면
완벽하죠.

그야말로 Perian만이 존재하고 있고, 어떤 분께서 .smi와 기타 유용한 기능들을 지원하는
소스를 Perian 측에 전달한 것입니다.

이 소스마저 공개해야할 이유는 없지 않겠습니까?

바로 현재도 누군가의 하드 디스크에는 capriPerian이 엄연히 깔려 있겠지만, 제3 자가 1년 쯤
뒤에 와서 이 글을 읽는다면 "대체 뭐가 문제입니까?"라고 생각할지 모르겠습니다.

조금 속된 표현을 쓰자면 "한강에 배 지나갔다고 뭐 남는 게 아닌 거죠"

참고로 개발자분이 남긴 글입니다. Perian과의 일들과 배포 제한 이유를 말하고 있습니다.

http://nextcube.org/board/bbs.php3?board=board&line=rdate&fld=&mode=view&id=3484&nws=&page=1&keyword=&flag=&a_o=

cwryu의 이미지

복제CD 불법배포하다가 걸렸다고 판매 중지하고 간판 내리면 모든 책임이 없어질까요? 이미 위반한 건 돌이킬 수 없습니다.

이미 위반한 사항에 대해서 저작권자가 문제를 크게 가져가자고 마음 먹으면 고소를 하고 권리침해에 대해 배상을 요구할 수 있습니다. 하지만 보통 저작권고지 및 소스코드공개로 마무리하죠. 손해배상금 받아내는 게 목적이 아니라 공개를 하는 거니까요.

linlin의 이미지

Quote:

그런데 "공식적인" 면들만 보면, 이제 더 이상 capriPerian은 존재하지 않습니다. 그리고
이전의 존재에 대해서도 부정되고 있는 셈입니다. 게시판에 올라온 릴리스 글까지 지우면
완벽하죠.

네. 그렇게 생각할 수도 있을 겁니다. "공식적"인 배포를 하지 않았으니 굳이 capriPerian의 소스를 공개할 필요도 없을 수 있겠지요. 소스코드 공개 의무는 배포시점에 발생하니까요. 달리 말해 배포안하면 소스코드를 공개하지 않아도 아무런 문제가 없습니다. 하지만 capriPerian은 웹에서 아무나 다운받을 수 있도록 배포되고 있었거든요. 다운로드 링크가 있던 애플포럼이라는 곳이 비회원은 글을 읽지도 못하는 곳도 아니고... 뭐 그래도 모른 척 해 주는 것도 방법이라면 방법이지 않을까 싶네요.

그런데 전개된 상황을 보면 이것이 참 코미디에요... capriPerian을 돌려 보지는 않았지만 capriPerian 개발자가 배포한 그 동호회에서도 capriPerian의 인기가 좋았고 해킨토시 동호회에 여러번 업로드 삭제 요청을 걸 만큼 여타 맥 사용자들 사이에서 인기가 높았는데 이런 좋은 프로그램이 사장된다는 얘기이거든요. 인기가 높으면 자연히 널리 쓰이고 이것이 개발자에게 즐거운 일이 되도록 디자인 되어 있는게 오픈소스 소프트웨어와 라이센스인데 이걸 이렇게 뒤집어버리는 사례가 나올수도 있군요.

domain808의 이미지

되돌리면 다 해결된다.,
Zero로..
거듭 강조하지만 매듭은 계속적인 개발을 위해 소스공개로 이어져야 한다고 봅니다.
이미 오픈소스에 참여를 했으면. 또한 그 소스로 인해 새로운 창조물이 만들어졌으면.
기본적인 의무를 지켜야 한다고 봅니다.
이런식이면 오픈소스의 의미가 상실되는겁니다.

분명 다른글에 이야기 했다시피 Perian은 capriPerian소스에 대해 reject을 했다고 개발자가 말을했었습니다.
그런데..지금와서 소스를 Perian에게 제공한다는것은 개발중지를 넘어 사장을 시킨다는 이야기나 다를바 없습니다.

그냥 Fork 취급을 받더라도 애포에 오픈소스를 명시하고 오픈을 하는것이 좋은 마무리라 생각됩니다.
당연히 Perian이 받아준다면 상관이 없겠지만.
잠정적으로 다음 개발자가 나설때까지는..

그리고..Perian의 소스를 건드렸기 때문에 불량과 상관없이 공개되어야 하는것이 원칙입니다.
이미 공개가 되었기 때문입니다. 개발자 개인의 손에서는 어떤것이든 상관없이 개발자의 마음이지만.
그리고 DLL개념으로 독립적인 부분이라면 개발자의 재량에 따라 공개할 의무는 없지만..
^^ 사실 오픈소스와 더불어 작품을 만들어놓고 자신의 부분을 공개 안한다는것은..
좀 거시기 하죠.

linlin의 이미지

Quote:

사실 오픈소스와 더불어 작품을 만들어놓고 자신의 부분을 공개 안한다는것은..
좀 거시기 하죠.

저도 이 부분은 좀 이해가 안갑니다... 이게 싫었으면 처음부터 오픈소스를 가져다 쓰지 않을 일입니다. 그리고 지금 전개된 상황에서는 그냥 소스를 공개해버리는게 이 개발자분 책임을 벗어버리는 일입니다.

corba의 이미지

domain808님이 의무와 원칙을 중요시 하시는 분 같아 개인적으로 궁금한 것이 있습니다.

domain808님이 모 커뮤니티에서 스스로 언급하신 "아무리 해킨토시 사이트라 지만..상당한 유저를 보유하고 맥 스위칭에 한몫을 하는 사이트"에서 올리고 계신 상용OS의 "의무와 원칙"에 대해서 혹시 알고 계신가요?

오픈소스의 기준에 엄격한 만큼 상용S/W의 기준에도 엄격하셨으면 하는 바램입니다만...

적어도 다른 개발자의 결과물을 불법으로 사용하고 올리고 계신 분께서
"일반적인 관점에서 개발자가 자기가 만든 저작물을 마음대로 하겠다는 생각으로 판단을 않하셨으면 합니다. "
라고 말씀하시기 전에 그런 말씀을 하실 수 있는 자격을 먼저 갖추셨으면 합니다.

cwryu의 이미지

해킨토시 사용자들의 맥오에스 라이센스 위반과는 상관없이, Perian 라이센스의 위반은 그거대로 바로잡아야 되는 문제입니다.

이런 식으로 "너희도 위반한거 있는데 나한테 뭐라고 할 수 없어"라는 식의 비꼬는 주장은 아무 도움이 안 됩니다.

linlin의 이미지

해킨토시 포럼인가요? 도메인 네임이 x86osx.com이던데 왜 애플포럼에서는 다들 해킨토시 포럼이라고 부르는지 별로 보기 좋아보이지는 않습니다.

안그래도 이 "해킨토시"포럼에서는 오에스텐을 불법적으로 구해서 쓸 수 밖에 없는 원죄(?)가 있다보니 capriPerian 개발자에 대해 정당한 라이센스 준수 요구도 못하고 있는 것 같더군요. 홈페이지 공지사항부터 납작 엎드려 비는 분위기고... 이것을 또 애플포럼 측 사용자들은 은근히 해킨토시 쓰는 사람들 저작권 인식 수준이 그렇지... 식으로 깔보는 경향도 보이구요. 애플포럼 내에서 capriPerian 개발자의 LGPL 위반을 지적하는 사람들은 거의 왕따분위기더군요. 솔직히 LGPL은 가뿐히 무시해도 되고 "리얼맥, 정품 OSX" 구매는 칼같이 지켜줘야 하는 것인지 의문의 생기지 않을 수 없네요.

capriPerian의 재배포 허용 문제와 오에스 텐 사용의 합법 여부는 엄연히 분리해서 생각할 일입니다. 특히, 맥 커뮤너티쪽의 오픈소스 라이센스에 대한 몰이해 문제는 리눅스 진영의 입장에서도 바람직하지 않습니다. 맥오에스텐은 BSD 계열이기 때문에 사실상 리눅스쪽 오픈소스 활동의 혜택을 가장 많이 보는 플랫폼 중의 하나인데 이런 식으로 맥 사용자들의 오픈소스에 대한 기본이해가 일천하다면 문제가 있습니다.

domain808의 이미지

^^
아시다시피 일이 이미 벌어진 다음 제가 개입한겁니다.
해킨토시 사이트에서 어쩌구 저쩌구..불법사용자들이..뻔하지..<-이런식이라 거론했습니다.
나중에 애포에 대해 LGPL를 위반한 저작물을 버젓이 배포처로 또한 동조하는 회원들이 그를 이용한 영상물(거짐90%이상이 불법영상이겠죠)을 보고.
^^ 괜히 라이센스 이야기를 꺼낸것이 아닙니다.
그전에도..라이센스 위반이기 때문에 배포에 제한 둔다는 짐작은 했습니다.
어떻게보면..
라이센스문제는 저의 방패겸 무기가 되었겠죠.

그리고 Capri님이 개발을 업으로 하시는지 알수는 없지만..
저 또한 처음PC가 생긴 80년초부터(초딩) 프로그래밍(-.- 직접하지 않으면 CRT에 보이는것이 없던 시절)을 시작해서..전공을하고(-.- 나름배울게없다고 중태를 했지만, 변명이라면 학비를 제가 벌어서 다녔기때문에) 생업을 가졌던 보수적개발자입니다.
보수와진보의 차이는 알수없지만..
초창기때의 사람이니..그냥 보수적?
없었을때 어려울때 컴퓨터를 접해서인지 나름대로 철학적의미를 많이두게되고 오픈소스에 예민한겁니다.
-.-
저도 이런 굴래에선 벗어날수가 없는것 같군요.

onion의 이미지

예전에는 그러셨엇더라도...
지금은 전혀 다른일로 생업을 이어가고 계시지요.
그리고 철학과 license등을 이야기 하는것은 좋지만
이 모든것의 중심에는 사람이 있는겁니다.
license를 지키지 말자는 뜻이 아닙니다.
왜 사람이 기분이 상했으며
왜 이러한 조치를 진행하며
왜 어떠한 행동을 하고
그것이 결정나지도 않았는데
license를 참고삼아 의견을 제시하는것이 아니라
당사자에게 license를 무기로 그사람을 license를 무시한 범법자 취급을 하며
"기분따위는 상관없는 무조건적 즉시집행"을 요구하는것이
제 생각적으로는 방법에 문제가 있다고 생각되기 때문입니다.
FSF가 GPL등을 어겼을때 아무런 조치없이 바로 집행에 들어가나요?
"권고" 라는것을 합니다.
왜 "권고"를 할까요?
문제를 제대로 인식하지 못한채 일이 벌어졌을수도 있기 때문입니다.
마찬가지입니다. 귀하의 의견에 이러한 license적 문제가 있으니
이런 방향도 좋을것 같습니다....라는 접근방법도 좋을거 같다는 생각을 합니다.
그렇다면 서로 긁어먹는게 아니라 좀 더 좋은 의견도 나오지 않을까 하네요.

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

병맛의 이미지

"거듭 강조하지만 매듭은 계속적인 개발을 위해 소스공개로 이어져야 한다고 봅니다"

지금으로선 capriPerian은 공식적으로 배포된 적이 없고 다만 Perian에 추가할 수 있는
부분을 누군가(개발자)가 개인적으로 코드를 짜서 Perian에 보낸 것이 다입니다.

라이선스가 적용되는 단계가 아니니(그야말로 혼자서 만들다가 한번 제출해본 셈이죠)
"도의적"인 공개 요구는 가능하겠지만 선택권은 개발자의 몫인 것 같습니다.

이 시점에서 한번 다른 토의를 해보는 것도 의미가 있을 것 같은데요.

한국의 개발자분들의 입장은, 이렇게 자신이 만들어 놓은 GPL 관련 소스의 공개에 대해
어떤 입장을 가지고 계시는 편입니까?

대체로 여러 프로젝트들이 지난 세월간 계속해서 진행이 되온 걸로 알고 있는데요.

또 한편으로는 자신이 짠 코드의 공개를 그다지 선호하지 않는 것도 같아 보입니다.

cwryu의 이미지

틀렸습니다. capriPerian은 이미 배포되었고, 지금 와서 배포를 중단한다고 해서 이미 한 라이센스 위반 행위가 없어지는 게 아닙니다.

이 상황에서 전형적인 시나리오는 저작권자인 Perian 개발자들이 연락을 해 와서 공개하는 경우입니다. 이보다 심하면 최근 몇몇 소송처럼 실제 법적인 조치에 들어갈 수도 있죠.

지금이라도 과거의 capriPerian의 배포조건이 잘못된 것임을 시인하고 자발적으로 LGPL의 조건을 준수해 소스코드를 공개하는 게 좋은 시나리오라고 생각합니다.

김일영의 이미지

애당초 사용자들이 capriPerian에 대해 라이센스를 문제삼은게 아닌 이상
제 3자의 입장에서는 왜 Perian이 capriPerian에 대해 GPL 라이센스 외적인 것을 요구했는지부터 살피는게
순서가 아니겠습니까?

지금이라도 과거의 Perian의 capriPerian에 대한 거부가 잘못된 것임을 시인하고
자발적으로 LGPL의 조건을 준수하여 capriPerian의 개발과 배포에 지장이 없도록 하는게
좋은 시나리오라고 생각합니다.

cwryu의 이미지

위의 링크에 나온 Perian 소식을 인용해 보면,

Quote:
어떤 사용자에 의해서 Mac Update 사이트로 베타 버전이 공식 버전인양 둔갑하여 출시된 후, 그야말로 거의 쌍욕이 오가는 거친 상황 속에서, 1.0은 건너뛰고 1.1을 연말에 출시하겠다, 개발 코드 및 베타버전은 앞으로 closed group으로 유지하겠다는 개발자들의 협박과 탄식 속에 결국은 1.0이 출시되었습니다.

여기서부터 시작해서 확대해석을 하셨는데요. Perian은 LGPL 조건에 따라 배포되고 있습니다. 개발자들이 포럼에서 쌍욕을 하든, 외부 비공식 버전에 대해 어떤 시선을 보내든, fork된 프로젝트들을 보고 무슨 말을 하든, 배포되는 라이센스는 바뀌지 않았다는 말입니다. 이런 것들이 라이센스 외적인 요구가 아니냐구요? 그냥 말일 뿐이지 지킬 의무는 없는 겁니다. 배포되는 곳에 LGPL이라고 적혀 있으면, LGPL인 겁니다.

그런데 capriPerian의 경우는 어떻게 했습니까? 소스코드도 배포하지 않았고, 배포 방법에 대한 고지도 없었습니다. 재배포를 "불펌"이라고 말하거나, "재배포 금지는 그 이유가 마음에 들던 안들던 지켜주셔야만 하는 부분입니다"라는 말을 사용하면서 재배포금지라는 추가적인 조건을 내걸었습니다. 왜 Perian의 내부 프로젝트의 분위기를 따지면서 이 명백한 위반을 정당화하려 하는지 모르겠군요.

소타의 이미지

SMI 지원에 대한 요청(패치가 포함되어 있었는지 여부 포함)의 속사정은 모르겠지만요..
메인스트림에 반영되지 못했다고? 여튼.. 이유가 어떻든 fork하는 것까지도 ok입니다.
LGPL 기반 소프트웨어를 수정해서 배포를 했다면 그 소프트웨어도 LGPL이어야 합니다. 이 부분에 대해 이견은 없으시리라 봅니다.
Perian이 배포에 대해 까칠하게 굴건말건 LGPL 소프트웨어로서 의무를 이행하는 것도 중요합니다.

물론 좋은 프로젝트의 지속도 중요합니다. 저도 잘 쓰고 있고요.

김일영의 이미지

그럼 왜 Perian한테 따지지 않냐는 겁니다.
알고 보면 capriPerian 개발자가 가장 소수이지 틈에 낀 약자 아닙니까.
Perian한테 따지는 것은 capriPerian 개발자가 알아서 할 일로 넘겨놓고, capriPerian의 LGPL 준수만 외치면 된다는건 비겁한 것 아닌가요?
지금 보면 Perian부터가 "LGPL이고 뭐고 니가 따로 놀겠다면 우리끼리 closed시켜놓고 놀겠어" 뭐 이런 상황인가 본데, capriPerian 개발자 혼자 무슨 죄가 있다고 "그래 어디 법대로 해 봅시다" 그럴 수 있을 것 같습니까?
현실적으로 우리 법에서부터 - 물론 우리 법이 적용될 문젠 아니지만 - 이런 제 3자의 법적 문제 제기가 성립이 안되는 상황입니다.
현실적으로 만약 그렇게 꼿꼿하게 굴어서 정말 closed 돼 보세요... GPL 준수를 위해 몸소 나선 선구자라고 칭송할 것 같습니까? X나 욕이나 바가지로 해 대겠지... 그러지 않더라도 궁금한거, 문제 생기는거 있으면 이제 이 개발자한테 피드백이 쇄도하겠지... 나 더 이상 그거 안합니다라고 말은 할 수 있다곤 하지만, 여하튼 그런걸 다 감당하라고 해야 옳은 겁니까?
그러니까 개발자분이 나름 Trade off를 추구한거 아니겠습니까... 상황이 딱 그런거지 이 분이 정말 GPL이 뭔 말인지 몰라서 그랬겠습니까?
우리도 개발자인데 - 저는 비록 허접이긴 하지만 - 팔이 좀 안으로 굽읍시다.

cwryu의 이미지

앞에서 설명을 해 드렸는데요. Perian은 LGPL에 맞게 배포되고 있다니깐요?

"LGPL이고 뭐고 니가 따로 놀겠다면 우리끼리 closed시켜놓고 놀겠어"라고 하신 말은 "개발 코드 및 베타버전은 앞으로 closed group으로 유지하겠다는 개발자들의 협박과 탄식 속에 결국은 1.0이 출시되었습니다" 이걸 갖고 하신 말씀같은데요. 어떤 말을 하던 라이센스가 바뀌는 건 아닙니다. 실제로 개발을 close하지도 않았고, 또 설령 close하더라도 LGPL은 배포하는 상대에게만 의무를 다 하면 되기 때문에 배포하지 않은 "개발 코드 및 베타버전"이라면 closed라도 상관이 없습니다. 지금까지 배포한 버전은 당연히 계속 LGPL이고 앞으로도 바뀔 일이 없습니다. Perian도 ffmpeg 코드를 포함하기 때문에 라이센스를 바꾸지 못합니다.

제가 보기에는 정말로 LGPL이 뭔지 몰라서 그러셨던 것 같습니다. 알고도 그러셨다면 모 인터넷 공유기 업체와 같은 수준이 되는 거죠.

김일영의 이미지

현실적으로 그 개발자분께만 부담이 간다는 말씀이죠.
라이센스를 바꾸지 않더라도, 업그레이드를 했는데 폐쇄적인 커뮤니티에서만 배포를 해버린다든지 하면 폐쇄적인 라이센스로 바꿔진 것 같은 결과가 되지 않겠습니까? 물론 영구적이진 못하더라도 말입니다.
closed라고 표현한 부분은 그런 걸 말씀드린 거고요. 지금보니까 제가 closed라고 쓴 부분에 대해 설명이 없었던거 같아서 부연했습니다.
여하간 그 경우 이 개발자분에게 질타가 쏟아지거나 적어도 문의 메일이 쇄도하겠죠...
저로서는 그 분이 라이센스를 몰라서 그러신거라고는 생각되지가 않네요.

cwryu의 이미지

그러니까, 어쨌거나 Perian은 LGPL을 지키고 있지 않습니까. capriPerian은 명백히 위반하고 있구요.

고작 질타를 듣는 게 싫어서, 문의 메일 더 올게 무서워서 고의로 라이센스를 위반합니까?

김일영의 이미지

현재까지 상황 공유와 의견 교류는 충분히 된 것 같고요...
더 이상은 그냥 각자의 가치관의 차이일 뿐 논의로 결론을 내릴 성격은 아닌 듯 합니다.
다만 그 분 입장에서는 '고작'이 '고작'은 아니었을거라 생각해봅니다.
라이센스는 라이센스일뿐 개발자 한 사람에게 책임을 전가할 수 있는 절대가치도 아니라고 생각하고요.
Perian의 것은 Perian에게, capriPerian의 것은 capriPerian에게.

cwryu의 이미지

유나바머도 나름대로 가치관이 있어서 폭탄 테러를 했고, 유영철도 나름대로는 이유가 있어서 살인을 했다더군요. 하지만 어쩝니까. 법은 법대로 처벌을 내리더군요.

제가 "고작"이라는 말을 쓰면서, 분명히 여기에 말꼬리를 잡고 늘어질거라고 생각해서 잠시 고민했지만 역시 예상대로군요. 이후에는 지금까지 그래왔던 것처럼 마이너스로 대신하겠습니다.

김일영의 이미지

"고작"을 인용한걸 "말꼬리"라고 표현할거라 예상했더니 그대로시군요...
저도 마이너스로 대신하겠습니다.

semmal의 이미지

역시 이해를 잘 못하시는 분이군요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

병맛의 이미지

그런가요? 뭐 전 잘 모르니 고수분들이 하시는 말씀이 아무래도 옳겠네요.

그럼요,

Perian의 소스 공개 요구와 저 같은 제3 자의 소스 공개 요구는 LGPL상
어느 쪽이 더 우위에 서는 건지요.

한쪽에서 소스 공개에 대해서 반대하는 반응을 보이는 이유도

"왜 잘 얻어다 쓰던 처지에 소스를 내놓으라니마니하는 거냐"

바로 이건데요.

linlin의 이미지

소스공개 요구는 아무나 할 수 있습니다. Peiran 축이나 제 3자나 차이가 없습니다. 뭐... 소스코드 가져다 그걸로 코딩할 관심도 없는 사람이 소스코드 공개 운운하면 주는 쪽 기분은 별로 안좋죠. GPL 코드 가져다 제품 만드는 회사들이 이것 때문에 GPL을 싫어하는 경향도 있죠. 밀려오는 소스코드 공개 요청 전담 부서를 따로 만들어야 한다는 우스개가 자주 나옵니다.

kall의 이미지

약간 오해하시는것 같은데..생뚱맞은 제3자가 소스를 요구할수는 없습니다.

해당 프로그램을 사용(소유)하는 사람에게 공개하는게 원칙이죠(프로그램을 전달받은).
이번경우엔 capriPerian의 바이너리 파일을 받아서 사용하는 사람이 소스를 요구할 수 있는거구요.
그 외에는 소스코드를 요구할 권리가 없다고 알고있습니다.

원칙적으로는 그렇지만 보통은 소스코드 요구를 하나하나 처리하기 귀찮으니 웹에 올려서 완전공개 해버리거나..아니면 소스를 받은 누군가가 재배포를 하죠.

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

linlin의 이미지

아... GPL에 그런 조항이 있었던가요? 즉 사용하는 사람, 혹은 배포를 받은 사람이 소스 요구 권리가 있다는 것이죠? 답변 감사합니다.

linlin의 이미지

물론 GPL 소스에 추가 작업을 했더라도 공개하고 싶지 않은 경우가 있어요. 제 경우도 프로젝트 일하는게 하나 있는데 소스코드 공개 안하고 있습니다. 워낙 버그도 많고 스파게티코드에 학교 이름도 걸려 있으니 배포안하고 in-house로 쓰고 있죠. 그러다 다른 학교 팀에서 우리 코드를 돌리고 싶다고 해서 그쪽 웹페이지에 바이너리를 업로드 해 줬는데 이것 역시도 엄격히 따지면 배포일겁니다. 하지만 뭐 소스코드 달라고 요청 들어오면 그 때 줘도 안늦으니 그렇게 놓아두고 있어요.

그런데 capriPerian의 경우 원저작자가 소스코드를 공개하면 사실 원저작자한테 유리한 점이 여러가지가 나옵니다. 첫째로, capriPerian에 대한 이런저런 요청이 들어오면 난 이제 더이상 일 안한다 답 하나로 복잡한 요청들을 다 빠져 나올 수 있어요. 일 안하니까 남들이 알아서 할 수 있게 소스코드 공개했으니 여러분들이 알아서 해 주세요... 한마디면 충분합니다.

Perian 원 프로젝트에도 마찬가지입니다. 뭐하러 힘들게 코딩해서 제출한 소스 reject당해 기분나쁜데 또 code submission하고 있습니까? LGPL에 따라 공개했으니 Perian 너네가 패치 넣든 말든 알아서 해라가 제일 편한 답변입니다. 더더군다나 더이상 capriPerian 프로젝트 진행도 안하는데 Perian쪽 눈치 볼 필요도 없구요.

또 솔직히 개발자 본인의 기분은 나쁘지만 코드가 무슨 죄가 있습니까. 내 기분 나쁘다고 코드까지 죽이느니 코드 너는 네 갈길 알아서 가라고 공개해버리면 혹 압니까... 좋은 개발자 만나서 계속 살아나갈지요.

그리고 확 공개해서 풀어버리면 애플포럼에서도 x86osx 동호회에서도 필요한 프로그램을 다시 쓸 수 있게 되니 맥 커뮤너티쪽에도 또 좋은 일입니다.

이런 여러가지가 그냥 LGPL 을 따라 그냥 무조건 공개해버리면 가능해집니다. 그래서 capriPerian 개발자분이 그냥 공개하시라고 얘기를 하는 겁니다. LGPL의 의무조건 운운은 그 다음의 일입니다. 왜 불편한 길을 사서 가려고 합니까....

maidaro의 이미지

안녕하세요. 막 가입한 상태에서 분위기 파악도 안된 상태에서 글을 남기게 되어 조금 걱정이 앞섭니다만..

그간 오픈 소스의 forking(여기 와서야 forking이라 부른다는 사실을 알게되었습니다) 문제에 대해서 꽤 오랫동안 고민을 해왔습니다만, 이번 capriPerian이 제게는 forking에 대해서 좀 더 깊게 생각해보게된 계기가 되었습니다.

capriPerian이 Perian에 패치로 제공했다가 reject이 되는 과정을 거친 결과물인지는 모르겠습니다만, KorPerian이란 capriPerian과는 별개의 변종을 제작하신 분의 패치는 Perian 팀으로부터 reject 되었고, 그 결과로 KorPerian이란 변종을 릴리즈한 일이 있습니다. KorPerian은 capriPerian이 공개되자 제작을 중단했습니다. forking 버전이 보일 수 있는 대표적인 약점이 바로 이와같은 점이 아닐까 싶습니다.

간밤에 Perian의 메일링 리스트를 통해서 개발진의 얘기를 들어봐도 여전히 그들은 capriPerian이나 KorPerian에서 구현한 기능에 대해서는 회의적입니다 - Perian 개발진은 SMI에 대한 기능 지원 불가를 원칙으로 하지는 않습니다만, 자막에 관해서 on/off 이외에는 어떤한 설정, 예를 들면 SMI의 경우 반드시 필요하다고 생각할 수 있는 자막의 기본 인코딩 셋팅 등을 절대 허용하지 않고 있습니다. 동시에 forking 버전에 대해서도 경계적입니다.

그럼에도 불구하고, 저는 역시 capriPerian이나 KorPerian같은 제3의 변종의 출현은 바람직하지 않다는 결론을 내리게 되었습니다만, 이들 기능을 위해 Perian 개발진을 설득하는 일은 단기간에 끝날 수 있어 보이지는 않습니다. 어쩌면, Perian 개발진은 끝끝내 받아들이지 않을 수도 있습니다.

제가 고민하는 바는 Perian과 관련된 개발자로써 forking 버전의 유혹은 자제하고 Perian 개발진을 끈질기게 설득하는 과정동안 일반 유저들에 대한 배려 문제입니다. forking을 하지 않는다면, 결국 일반 유저들은 Perian의 정식 릴리즈에서는 해당 기능들을 접할 수 없고, 오직 Perian 소스와 비공식 패치를 적용하여 직접 빌드하는 방법밖에 없는 것 같습니다. 소프트웨어를 사용하는 유저 모두가 직접 코드를 다운 받고, 빌드하고 사용하는 그야말로 환상적인 것 같은 세상이라면 모를까, 저는 개발에 관심없는 사용자들에게도 이러한 과정을 요구하는 것은 말 그대로 너무 이른 환상이 아닌가 생각합니다.

제 짧은 소견으로는 일반 유저들을 배려할 수 있으면서 forking으로부터 자유로울 수 있는 마땅한 해결책이 떠오르지 않습니다.
이런 경우 forking이 불가피함에도 불구하고 제가 불필요한 고민을 하고 있는 것일까요?

제가 오픈 소스, 리눅스 등에는 조예가 깊지 못해서 단어 사용이라든가 이해에 부족한 점이 있습니다.
실수가 있었다면 너그럽게 봐주시면 감사하겠습니다.

소타의 이미지

새로운 가치를 위해서는 fork가 남발되어도 상관없다고 생각하는건 저 뿐만은 아니겠죠? ㄷㄷㄷ
메인스트림과 추구하는 가치가 다르면 언제라도 fork해도 관계없다고 생각합니다.

linlin의 이미지

아뇨. 사실 forking이 중요한 개념입니다. 적어도 제가 보기에 forking을 가능한한 자제한다는 현재의 오픈소스계의 관행은 충분히 바람직하다고 생각합니다.

forking을 한 개발자도 사실은 그에 따른 피해를 감수해야 합니다. 원래 프로젝트가 새 버전이 나오면 이전 forking을 한 버전에 추가한 패치들은 제대로 작동하지 않기 마련이며 또 부가적인 패치의 패치작업이 또 필요할겁니다. 이런 중복 투자로 인한 손실이 크다면 forking을 불편하더라도 애초에 하지 않는 것이 나을 수도 있죠.

하나 신경쓰이는 것은 한국 개발자들은 대체적으로 forking이 왜 바람직하지 못한지에 대해 별다른 생각을 안하는 경우가 많은 것 같네요. 오픈소스 라이센스가 자유에 중점을 두고 또 한국만의 현상인지는 모르겠지만 오픈소스 라이센스에 의외로 이데올로기적 측면에서 매력을 느끼는 개발자들이 많습니다. 그러다보니 소스코드 수정의 자유가 있는데 왜 forking을 마음대로 해서는 안되는지, 혹은 오픈소스코드는 공공이 공유하는 것인데 어떤 개발자는 왜 사적 소유로 공개를 하지 않으려 하는지 이해를 잘 못하는 경우가 나오는 것 같습니다. 이 글타래도 예외가 아니구요...

저도 사실 궁금한 부분이 그렇습니다. Perian 측에서 zero-configuration을 이유로 capriPerian 패치를 받아들이지 않았다고 하는데 그렇다면 zero-configuration이 되도록 해 주면 capriPerian 패치를 받아주겠다는 의미인지, 혹은 아예 smi를 지원하지 않겠다는 의미인지 궁금합니다. 전 또 개인적으로 일본 애니메이션을 많이 보다 보니 전세계적으로 smi를 자막 파일로 쓰나 했는데 그것이 아니었다는 걸 이번 기회에 알게 되네요. 어쨌거나 forking 여부는 참 어려운 선택입니다.

ganadist의 이미지

smi같은 요상한 포맷의 데이터를 처리하기에 zero-configuration은 먼나라의 일 같군요. (gstreamer에 포함된 자막 처리 플러그인 중 smi 파서가 제일 workaround코드가 많이 들어있습니다;; )

게다가 간단하면서도 많은 기능을 요구하는 한국 사용자의 특성상 더욱 힘들것 같습니다. :)

개인 적으로는 smi는 없어져야 할 악의 축이라고 생각합니다만 마땅한 대안이 없는 것도 사실이네요.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

병맛의 이미지

1) .smi = 악의 축 동감

2) Forking은 부담이 적잖지 않겠습니까? 그저 예전 프로젝트의 릴리스를 구해와서
패치 먹여서 재배포하는 식의 프로젝트는 좀 곤란할텐데요. 새 프로젝트도 나름
Roadmap이 있을 터인데 매번 부모 프로젝트에 매여 사는 건 좀 처량한 신세잖아요.

3) "Perian 측에서 zero-configuration을 이유로 capriPerian 패치를 받아들이지 않았다고 하는데 그렇다면 zero-configuration이 되도록 해 주면 capriPerian 패치를 받아주겠다는 의미인지, 혹은 아예 smi를 지원하지 않겠다는 의미인지 궁금합니다."

-> 저도 궁금합니다. 그런데 Perian 채널에 들어가서 질문을 직접 할 만큼 궁금하진 않군요.
.smi 지원은 개인적으로 바람직하지 않다고 생각하거든요.

4) "간밤에 Perian의 메일링 리스트를 통해서 개발진의 얘기를 들어봐도 여전히 그들은 capriPerian이나 KorPerian에서 구현한 기능에 대해서는 회의적입니다 - Perian 개발진은 SMI에 대한 기능 지원 불가를 원칙으로 하지는 않습니다만, 자막에 관해서 on/off 이외에는 어떤한 설정, 예를 들면 SMI의 경우 반드시 필요하다고 생각할 수 있는 자막의 기본 인코딩 셋팅 등을 절대 허용하지 않고 있습니다."

-> 이 바닥에서 우스개 소리로 하는 말이,

"먼저 말 꺼낸 놈이 한다"
"아쉬운 놈이 만든다"

죠. 우리나라에서 퀵타임에다 DivX & .smi 및 기타 등등 기능을 부여해주는 프로젝트가 나오지
않는 한, 아쉬운 건 한국의 맥 유저들뿐입니다. Perian의 입장이 저러하다면, 독자 프로젝트에
참가하는 한국인 한 명이 아니라 둘 셋, 혹은 더 많은 사람들이 나서는 길밖엔 없습니다.

그리고 라이선스에 의하면 Perian이 Fork를 경계한다해도 그것을 막을 권리는 없습니다.

처음엔 Perian을 기반으로 시작해서 점점 독자적인 방향으로 나가면 됩니다.

밑에서 예로 든 것처럼 Xorg처럼 더 좋아지고 더 활발해지면 굴어들어온 돌이 박힌 돌을 처내는
일이 생길 수도 있겠네요.

maidaro님은 Perian 프로젝트를 계속 설득하는 편이 좋다고 하시는데, 물론 그것도 한 가지
길이 될 수 있습니다.

5) Perian 개발팀은 좀 까칠하군요. 뭐 사람 사는 세상이다 보니 프로그래머 가운데서도 별난
성격을 가진 사람이 있기도 하고 그러죠. 누구나 이런 저런 일로 욕 좀 제대로 들어본 기억이
한번씩은 있지 않나 싶습니다.

병맛의 이미지

흑... 주옥같은 토론을 나누다가 어째서 이렇게 냉냉한 분위기로 흐르려고
하는 건가요. ㅠㅠ 조금씩만 릴렉스... ㅠㅠ)

http://www.appleforum.com/437243-post314.html

개발자가 앞으로의 계획을 적어 올렸습니다. 제 예상대로 capriPerian은
파토내고 Perian에 어쨌든 열과 성의를 하시려고 하는군요. 뭐 아무튼
행운을 빕니다.

cwryu의 이미지

이 말은 결국 지금까지 배포한 게 어둠의 경로였다는 얘기인데요. 이런 선택을 했다는 이유가 잘 이해가 되지 않습니다. Perian의 비공식 버전에 대한 반감을 확대해석하고 걸리면 안 된다라고 과민반응한 것 같군요. LGPL만 지키면 되고 원개발자 무서워할 걱정은 별로 할 필요가 없는데, LGPL을 위반하는 바람에 오히려 진짜 무서운 상황이 됐습니다..

Quote:
첫번째는 영문 Perian 1.0 버젼 릴리즈 당시의 불미스러운 사태로 인해, 영문 Perian 프로젝트 팀이 수정본이나 별도 프로젝트 가지치기에 대해 심한 반감을 가지고 있기 때문입니다. LGPL 라이센스만 준수한다면 무슨 상관이겠느냐 하시는 분도 계시겠지만, 별도 프로젝트를 오픈하려면 원 개발자의 동의나 허락을 얻는 것이 관례입니다.

이건 개발자 분께서 만들어낸 말같습니다. 지금까지 fork했던 프로젝트중에 원 개발자가 무려 fork하는데 동의까지 한 프로젝트가 있으면 알고 싶습니다. 당연히 원 개발자와 의견이 달라서 분가하는 건데, 의견 충돌은 기본이고 거친 말이 오고가지 않았으면 다행이죠.

소타의 이미지

음.. 전에 이런 생각을 한 적이 있었는데요..

제발 fork 좀 해줘.. 하는 김에 TODO 리스트 요만큼 떼줄께.. 웅??

어쨋든 SMI 지원에 대해 백포트는 좋네요...

linlin의 이미지

Quote:

저 또한 9개월 동안 공들인 소스를 그냥 사장시키고 싶은 마음은 전혀 없습니다. 문제가 불거져서 더이상의 몰래 멀티가 불가능해진 지금으로서는 정공법으로 나가려고 생각하고 있습니다.

이 부분이 개발자분 입장을 잘 대변하고 있지 않나 싶네요. 소스를 사장시킬 생각이 없다면 LGPL 준수가 소스를 살리는데 가장 효과적인 방법중의 하나일테고 따라서 정공법(?)으로 나가는 것이 맞을 겁니다. 처음부터 좀 이랬으면 좋지 않았을까 하는 생각이 개인적으로 드는군요...

Quote:

첫번째는 영문 Perian 1.0 버젼 릴리즈 당시의 불미스러운 사태로 인해, 영문 Perian 프로젝트 팀이 수정본이나 별도 프로젝트 가지치기에 대해 심한 반감을 가지고 있기 때문입니다. LGPL 라이센스만 준수한다면 무슨 상관이겠느냐 하시는 분도 계시겠지만, 별도 프로젝트를 오픈하려면 원 개발자의 동의나 허락을 얻는 것이 관례입니다.

관례는 아니죠. cwryu님 얘기대로 forking할 때 싸움 안나고 fork가 되면 정말 예외적인 케이스인데... 제가 보기에는 이건 관례보다는 capriPerian 개발자님의 평소 생각이 투영된 것이라고 봅니다. 실제 그동안 보여준 행동도 내 코드는 내 맘대로 배포한다는 틀에서 벗어나지 않구요. 이번 기회를 계기로 내코드에 대한 배포 제어권을 확실히 확보하려면 절대 오픈소스 라이센스를 쓰면 안된다는 점을 잘 알아 주셨으면 하는 바램이 있네요. GPL이나 LGPL은 공개하면 별 일 없는데 공개안하면 이래저래 까다로운 일이 많이 터집니다. LGPL에 비공개 코드를 연동하는 것도 생각보다 많이 복잡합니다. 여기 말고 다른 글타래에서 한창 논의 중이죠. 저도 LGPL이 이렇게 복잡할 수도 있다는 점은 이번에 처음 알았습니다.

그리고... Perian에서 또 까칠하게 굴면 두말안하고 fork 해버리세요. smi는 악의 축인지는 모르겠지만 어차피 한국 아니면 쓰는 곳도 없는 것 같은데요.

onion의 이미지

현실적으로 개발자에게.. 다음버전이 나왔는데 버전업해주세요..라는 문의가 오면 짜증나기 시작할듯하네요..
(아 태클이 아닙니다.. 말그대로 현실적이라는거죠)

어디가도 공지사항에 적어놓는다해도
그거 안읽고 꼭 게시판에 뻘소리 하는사람있는데
배포할때 README에 추가로 넣는다고해서...
읽을사람 얼마나 될까 하는 생각도 듭니다.

사실 안귀찮은건 Perian쪽에서 smi받아주는게 가장 나이스하죠...-.-;

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

domain808의 이미지

^^
이곳이 그나마 애포보단 LGPL에 관한 이야기가 통하는것 같군요.
지금 현재 처음 개발을 하신 KorPerian 개발자님이 이번 사태를 계기로 다시 재개하시겠다고 공지를 하셌습니다.
-.- 상당히 복잡하게 생각하는 분들이 많으신데
그냥..공개하면 모든문제가 없는 부분입니다.

저~위에 글에 이야기 했듯이
라이센스 거론은 제가 먼저 시작을 했습니다.
이미 상황이 벌어진 다음이었죠.
마지막의 대사는..
해킨토시 사이트..불법..그런 사이트니..회원들도..그 수준?
솔직히 간간히 capriPerian에 대한 자료(불펌은 한번뿐이 없었죠)에 소식은 알고 있었죠.
개발자가 직접 "불펌을 하였고 그러지 말라달는..운영자에게 이야기를 하였고" 바로 운영자가 공지를 했죠.
이런 상황에서 몇몇 유저들은 당연히 심기가 불편했을껍니다.
조용히 끝내도 될문제를..^^ 해킨토시의 공인이 되었죠~ 어떤 연유던간..
그후에 크게 벌어진 발단은 그냥 새버젼 소식만 전했는데 꼽깝게 생각했던 유저들이 한두말을 했죠. 그냥 평이한..
그와중에 한번이 강하게 "후지다..줘도 안쓴다"라는 악플성댓글..
이글을 캡쳐해서 애포에 공지했습니다. 모 해킨토시사이트의서 이런 악플때문에 개발을 중지하겠다고.
바로 여러 블러그나 사이트에 소식이 퍼지고.
해킨토시 사이트는 깡패집단이 되었죠.

그 상황에서 저는 소식을 접했고.
그때 필요한 무기는 라이센스였습니다.
방패겸..무기..

분명 그런것으로 따지면 애포역시 라이센스위반의 자료를 버젓이 배포하고 글타래를 이어갔던 부분이고.
더 면밀히 따지자면. smi 자막이 필요로 쓰여지는 온상은 불법영상물이라는 것이죠.

따져봤자 피차 좋을것은 없지만.

라이센스문젠..그냥 공개하면 해결되는겁니다.
원제작자의 허락요? Perian도 LGPL 오픈소스로 만들어진겁니다.
허락이라뇨..유럽지역의 환경조건때문에 smi자막이 필요없어 reject를 한다면 Fork를 해도 명분이 있고 LGPL에서 위반되는 사항이 아닙니다.
아마도 KorPerian 개발자님도 이부분을 묵고할수 없어. 다시 개발을 재개하는것으로 알고있습니다.

다른것을 다 떠나..

결론은 오픈소스가 왜? 오픈소스인가라는..
철학적사고를 이해하고..
집적 참여하게 된다면 그 철학적사고와 신념을 이어가야 한다고 봅니다.

linlin의 이미지

다른건 잘 모르겠고... 개인적으로 보기에 이번 해킨토시 동호회 운영하는 분이 상당히 처신을 잘 하신 것 같습니다. 솔직히 너네는 뭐 잘났다고 LGPL 준수도 안하면서 우리보고 라이센스 위반으로 매도하느냐... 치고 나갈 수도 있는 상황이었죠. 좀 더 살펴보니 실제 카피가 올라가지 않고 링크만 올라간 게시물도 삭제요청이 들어갔더군요. 이런 상화에서 거의 납작 엎드려 비는 모습이 제 3자인 제 입장에서 봐도 좀 뭐하긴 했습니다만 오히려 일을 잘 풀어나갈 수 있는 원동력을 만들지 않았나... 그렇게 생각해요. 물론 이건 개인적인 사견이구요.

그리고 "리얼 맥" 동호회 분위기가 좀 더 오픈했으면 해요. 몇몇분들 해킨토시 쓰는 사람들이 그렇지 식으로 매도하는 분위기... 좀 황당했습니다. 오픈소스까지 갈 필요도 없이 공개 소프트웨어는 누구나 맘대로 쓸 자유가 있는 겁니다.

마지막으로 이건 잡설이지만 웬만하면 그냥 속편하게 리눅스 쓰세요. 해킨토시 셋업 잡는 것을 보니까 차라리 리눅스가 훨씬 쉽겠더군요. 이 동네는 소스가 공개이다보니 과정이 어려워도 자료보고 잘 따라하면 되는데 해킨토시는 이거 정말 랜덤하게 설정 잡아야 하는 것 같네요. 솔직히 리눅스나 오에스텐 모두 유닉스 계열이고 오에스텐의 상당수 공짜 소프트웨어들이 리눅스에서 도는 오픈소스 프로그램들 포팅한 것 아니겠어요.

strongberry의 이미지

좀 이해가 안가는게, capri91님이 x86osx.com의 댓글로 인해 개발 중단 선언했을때 x86osx.com을 비난했나요? 특정 덧글을 비난했었죠? 사람들의 반응은 어떻던가요? 악플 단 사람 비난했었죠? domain808님이

http://www.appleforum.com/application/54146-front-row-plugin-capriperian-5.html

에 글 올리기 전까지 해당 글타래에 x86osx.com을 비난 하는 사람은 (자진 삭제했는지는 몰라도) 없었습니다. "일부의 물 흐리는 자들"을 비난하는 글 뿐이었습니다. 그런데 난데 없이 domain808님께서

Quote:
아무리 해킨토시 사이트라 지만..상당한 유저를 보유하고 맥 스위칭에 한몫을 하는 사이트에 대한 악평은..
애포에 대해..그다지 좋을것 같지 않군요.

라며 저작권 문제 제기를 시작하셨습니다. 해킨토시 쓰는 사람들에 대한 인식과 관련된 글타래가 이번 사건 이전부터 애플 포럼에 있었지만 내용을 보면 첫글이 작년 3월에 쓰여진 글타래이고 이번 사건과 관련한 글이 domain808님이 처음 글 남긴 시각 이후입니다. 적어도 x86osx.com을 이번 사건과 결부지어 비난한 글은 애플 포럼에 존재하지 않았습니다. x86osx.com을 깡패집단으로 만들었다는 인식은 적어도 지금 남아있는 증거로는 domain808님의 머릿속에만 존재하는 것입니다.

제가 아래의 주소의 글에서 왜 라이센스를 걸고 넘어지는가에 대해 얘기했지만 domain808님은 이부분에 대해선 언급 안하시고 계속 말돌리는 글을 올려서 애플 포럼 회원들에게 비판을 받았죠.(제 글을 무시했다고 애플 포럼 회원들에게 비판을 받았다는 의미는 아닙니다. domain808님이 왜 capri91님을 대상으로 하는지 중언부언하는 글을 계속 올려서 애플포럼 회원들의 비판을 받았다는 의미입니다.)

http://www.appleforum.com/436946-post122.html

네, capri91님이 LGPL에 대해 이해를 잘 하고 있었든 그렇지 않든 위반 소지가 있는 행동을 한게 사실이고 방금 확인해보니 다행히도 소스 공개를 하시겠다 밝히셨습니다. KLDP야 오픈소스 라이센스에 민감한 곳이니 domain808님의 라이센스 관련 의혹제기에 수긍하는 분위기가 많을 수 밖에 없죠. 당연한겁니다.

애플포럼에선가 x86osx.com에선가 capri91님에 대한 "공명심" 운운하는 글도 본기억이 나는데, 제가 보기엔 "뭐눈엔 뭐만 보인다"라는 생각이 드는것은 제가 팔이 안으로만 굽기 때문이겠죠?

x86osx.com에 애플포럼 회원이 원정가서 해킨토시 유저를 비난했었다면(지금 글이 다 삭제되서 제가 확인 할수는 없네요.) 회원이 아니면 덧글조차 남길 수 없는 x86osx.com이니 만치 내부 문제입니다.
다시 한번 말하지만 domain808님이 애플포럼에서 "x86osx.com 비난하지 말라"며 "라이센스 문제있다"는 얘기 하기 전까지 적어도 지금 확인한 바로는 이번 사건을 결부지어서 x86osx.com 을 비난한 글이 없었습니다.

철학도 좋고 신념도 좋습니다만, domain808님께서

Quote:
-.- 윗분이 지적한대로 저의 표현방식 남달리 주관적이고 불쾌감을 줍니다. 그런면에 항상 뱉어놓고 후회를 하죠. 그렇게하지 말아야지 하면서도 집중을 하며 흥분을 하면 주체를 할수 없는것 같습니다.
라고 자백하셨듯 참 무례하다는 생각을 떨칠수가 없네요.

추가: 이 글은 애플포럼에도 동일하게 올리도록 하겠습니다.
http://www.appleforum.com/mac-life/50864-%ED%95%B5%ED%82%A8%ED%86%A0%EC%8B%9C-%EC%82%AC%EC%9A%A9%EC%9E%90%EB%93%A4%EC%97%90-%EB%8C%80%ED%95%B4-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%83%9D%EA%B0%81%ED%95%98%EC%8B%9C%EB%82%98%EC%9A%94.html

추가2: 이제 상황 정리되가는 마당에 굳이 이런 글을 올리는 것은 제 오해일지도 모르겠지만, 한사람의 낚시질로 두 커뮤니티를 이간질하고, 또 다른 커뮤니티에서도 분란을 일으킨 것. 그 중 두 커뮤니티가 제가 즐겨 찾는 공간이기 때문입니다. 두 공간을 지키기 위해 저도 "방패"와 "무기"를 한번 들어볼랍니다. -_-+ (아래의 시그니쳐가 무색해지는 건가요?)

============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

cwryu의 이미지

Quote:
네, capri91님이 LGPL에 대해 이해를 잘 하고 있었든 그렇지 않든 위반 소지가 있는 행동을 한게 사실이고 방금 확인해보니 다행히도 소스 공개를 하시겠다 밝히셨습니다. KLDP야 오픈소스 라이센스에 민감한 곳이니 domain808님의 라이센스 관련 의혹제기에 수긍하는 분위기가 많을 수 밖에 없죠. 당연한겁니다.

이렇게 사실 관계의 문제를 사람들의 의견 정도로 희석시키면 곤란합니다.

위반소지가 아니라, 명백한 위반이었습니다. 어떤 이유가 있어서 위반을 했든 위반 여부와는 상관없는 얘기입니다. 라이센스에 맞냐 아니냐 알아보려면 라이센스 문구와 당사자의 사실 관계를 종합해보면 되는 겁니다. 커뮤니티 분위기가 어떻고, 개발자 분이 노력을 하셨고, 사용자들이 혜택을 입었고, 문제를 제기한 사람들의 맥오에스 라이센스 위반, 오픈소스 철학이 좋고 나쁘고 그런 건 생각할 필요가 없습니다. (별개의 문제라는 겁니다.)

strongberry의 이미지

배포 포인트의 제한시도란 점에서 LGPL 위반 소지 정도가 아니라 위반이라는 cwryu님의 말씀에 동의하고 제가 위에서 적은 글이 물타기가 되었다는 것을 인정합니다. domain808 님은 소스 공개 여부로 집중해서 개발자분을 비난했었으므로 저도 그쪽으로만 집중하느라 배포 포인트에 대해선 가볍게 생각했습니다. 이점 제 잘못 인정하구요.

소스 공개의 관점에선 시간이 걸렸을 지언정 소스 공개 여부를 결정하셨기에 그 전까진 위반여부가 확정되지 않았다고 생각해서 저렇게 적었다는 점 부연설명합니다.
============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

============================================
자나깨나 트롤 조심. 나간 트롤 다시보자.
"저는 앞으로 troll을 만나더라도 먹이를 주지 않도록 노력하겠습니다." :)

cwryu의 이미지

소스공개 부분도 위반한 게 맞습니다. 공개를 결정한 건 지금 바로잡겠다고 계획을 발표하신 거구요.

LGPL을 읽어보시면 (버전 2 기준) 소스 코드는 세가지 방법 중의 하나로 배포되어야 합니다. (1) 같이 배포하거나 (2) 소스를 주겠다고 3년간 보장해 주거나 (3) 2번을 통해 받은 바이너리를 재배포할 때 보장한 사실을 그대로 전달하는 방법. 개발자 분이 바이너리만 배포하면서 소스에 대해 언급을 안 한 그 순간에 이미 소스공개 부분도 위반했습니다.

병맛의 이미지

메일링 릴레이 수천 개 넘기고선 크게 한판 치른 다음에 찢어졌으면
/.이나 OSnews 같은 곳에 대문짝만한 게 나올 수도 있었을까요? ㅎㅎㅎ

아마 capriPerian 개발자가 본인 이름을 세계적으로 알릴 수 있었을지도
모릅니다.

domain808의 이미지

^^
오래전 리눅스도 무지 삽질하던 시절이 있었죠.
제가 처음으로 접한 Unix시스템?은 Xenix였죠. 이거 Microsoft것 아니었나요? 아마도..
^^
5.25인치 디스켓으로 설치하고..^^
많은 분들이 그시절 Xenix로 BBS Host를 구축을 했었습니다.

Linux는 정말 삽질을 무지..ㅠㅜ 했던기억이..

지금 해킨토시는 Original Kernel의 사용이 가능하게 되었습니다.
일단 TPM(Apple 하드락)칩을 커널로딩부분에서 애뮬에 성공했죠.
조만간 일반보드도 EFI BIOS로 바뀐다고들 하지만 결론적으로 그 기준이 Apple 메인보드의 EFI BIOS와 같냐는 문제죠 ^^
그래서 따로 확장파일로 인식을 하게 만듭니다.
이 모든 종합적인 기능을 현재의 EFI 부트로더에 첨가를 한다면~
완벽하게 정품시디로 설치가 가능할지도~ ^^
USB메모리로 부팅하여 설치CD로 스위칭하고 인식을 한후..설치..그리고 부트로더를 설치..
한다면..일반 설치CD로 설치할수 있다는 간단한 이론이 성립이 되지만~
지금 한창 개발중일껍니다.
현재 EFI 부트로더가 성공적인 사례고요.

그정도 수준으로 가면 Apple의 설치시디는 불티나게 팔리지만 ^^ 정말 제동이 걸릴수도~
여하튼..
해킨토시는 설치가 잘되는 하드웨어 조합을 하면~ 또한 리눅스보단 쉽게 설치가 되죠~
대부분 기존에 보유했던 PC에 설치하는것 때문에 삽질을 많이하지만~

linlin의 이미지

잡설입니다만 애플은 MS처럼 일반 피씨에 설치할 수 있는 운영체제는 안만들어 줄겁니다... 핵으로 그것이 쉽게 가능하기도 어려울테구요. 다만 애플이 공인 하드웨어 업체와 계약을 맺을 가능성은 항상 상존하죠. 예를들어 잡스가 어느날 델이나 HP에서 하드웨어 공급 계약을 맺는 쇼킹한 뉴스를 터뜨리기... 오에스텐의 시장점유율이 맥의 하드웨어 매출보다 중요해지는 시점이면 언제든지 터질 수 있는 사안입니다. 델 하드웨어 전용 오에스텐이야 언제든지 적당히 만들면 될테구요. 여전히 일반 조립 피씨들은 여기서 열외 대상이 될 가능성이 높죠.

이렇게 예측하는 이유는 애플은 우리네식으로 말하면 항상 갑의 위치를 놓으려 하지 않고 또 그럴만한 영향력을 플랫폼에 행사하고 있기 때문입니다. 델이나 HP도 을로 둘 수 있는게 애플의 파워입니다. 이번 iPhone도 사실상 AT&T가 애플의 을로 들어간 셈이지요. 이런 이유로 애플의 전략은 오히려 장기적으로는 MS보다 사용자들에게 더 해로울 수 있다고 전 보고 있습니다. 예쁘고 쓰기 편해 보인다고 너무 홀려서 좋을 일 없는 것이죠...

onion의 이미지

darwin기반의 bsd 시스템이라서 그렇지...
license도 apple의 license여서 그렇지 open이기는하고...
주시는거에 다들 "차라리 linux"라고 생각하는게 문제고
하드웨어 지원도 빈약하니깐 좀 거시기하기는 합니다만..
지금도 운영체제라면야...
다만 cocoa framework을 open할 생각이 전혀 없는게 안타깝달까요..
(뭐 마음에 안들면 gnustep을 쓰면 그만이지만.. 개발자만 만세부르는 환경이다보니..-.-)

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

linlin의 이미지

네 저도 그렇게 봅니다. cocoa 정도 오픈해버리면 (바이너리 형태 정도까지라도 말입니다.) 애플에 대해 이정도까지 경계하지는 않을 것 같네요.

domain808의 이미지

^^
처음에 개발버젼이 발표된후 기정사실화되는 시점에서 많은 생각을 해봤죠.
패쇄적?인 애플의 행보와는 달리.
미국 굴지의 유통업체와의 동거.
말씀처럼 Dell or HP의 파트너쉽으로 일반 PC용 OSX
TPM을 그대로 유지해도 괜찮고. 비용을 줄이기 위해 BIOS인증 방식도 괜찮고.
순정 Apple 제품과는 별개로 판매를 한다면.
^^ 당연히 매출에 영향은 주겠지만.
팔리는 만큼 라이센스비용이 충당하지 않을까? 생각이 들고.
기존에 맥매니아들보단 새로운 PC사용자들이 타겟을 삼을수 있으니.

지금의 방식을 고수하든.(^^ 현재도 성장하고 있으니)
개인적인 바램으론
적과의 동침이죠.
폭탄과 같은 이슈가 되지 않을까? 싶군요.
Dell or HP PC에 OS X and Office Bundle $ ETC ..

^^ 솔직한 배램이었는데..아직까지..아니 별 기미가 보이질 않군요.

linlin의 이미지

또 잡설입니다만... 이래서 맥 오에스 쓰는 분들이랑 얘기를 하다보면 좀 많이 갑갑합니다. 오에스텐이 좋은 오에스고 애플이 좋은 회사라는 생각에서 벗어나질 않아요.

델 이나 HP에서 출시하는 맥이 나오고 안나오고의 여부가 중요한 게 아닙니다. 애플과 오에스텐의 근본적인 문제를 지적하고 있는 거에요. 왜 애플은 애플에서 나온 소프트웨어 플랫폼을 애플 하드웨어에서만 돌려야 하는건가요? 해킨토시 쓰면서 많이 접하는 의문 아닌가요?

MS를 잠깐 볼까요. MS는 애플만큼 독점을 강요하지는 않아요. HP를 사든, 델을 사든 용산 조립피씨를 만들든 윈도우는 깔면 깔립니다. MS는 다양한 하드웨어 지원을 가능한한 하려고 노력하는 쪽이지 막는 쪽이 아닙니다.

리눅스나 다른 오픈소스 운영체제를 볼까요? 이동네는 하드웨어도 안가립니다. 일반 x86 하드웨어에 가장 잘 깔리고 갖가지 시피유를 지원하며 요즘은 embedded에도 잘 들어갑니다.

이것의 혜택은 누가 봅니까? 당연히 써드파티 개발자와 일반 사용자입니다.

그런데 맥에는 이런 혜택이 애초부터 없어요. MS는 윈도우에 대한 lock-in 전략을 고수하지만 애플은 맥오에스, 맥 하드웨어 양쪽 모두 lock-in 시키는 전략을 추구합니다. 오래전에 애플 2+, 2e 의 라이센스 정책을 아시는지 모르겠는데.... 미국 외의 나라에서는 애플 투 클론이 난립하고 있었지만 막상 미국에서는 애플 투 호환기기가 없었어요. 그 이유는? 하드웨어는 완전히 홈브루 출신의 공개 하드웨어에 확장슬롯까지 있었지만 바이오스는 저작권을 걸어 라이센스를 안줬기 때문이죠. 게다가 미국은 저작권이 연방법에 속하다보니 감히 이를 위반하고 하드웨어 사업을 벌일만한 업체가 나오지 않은 것은 당연한 전개입니다. 이런 전력이 있는 것이 애플입니다. 어쩌면, 애플 초기 워즈니악은 애플에 어울리는 사람이 아니었을 가능성이 높다고 봐요.

이런 얘기를 하면 맥은 소수고 MS의 독점때문에 항상 견제를 받고 있으니 나름대로 회사가 적절한 선택을 한 것으로 봐야 하지 않겠냐... 그렇게 얘기들을 많이 하죠. 그런데 요즘 애플이 벌이는 사업을 보세요. iPhone SDK는 역시나 iPhone 하드웨어 전용입니다. 애플 뮤직스토어는요? iPod 사지 않으면 사실상 못쓰죠. MS가 없어도 애플은 항상 플랫폼에 대한 완벽한 주도권을 놓지 않는 회사입니다.

그런 이유로 제가 HP나 델이 맥 전용 하드웨어 출시 가능성 운운.. 애플이 갑이고 다른 회사들은 을 운운... 하는 얘기를 한 겁니다. 애플은 어떤 형태로든 하드웨어에 대한 제어권도 놓지 않습니다. 또 애플의 이러한 속성을 감안한다면 사실 해킨토시와 같은 접근은 결국 사용자의 체감 비용만 증대시켜 결국은 소위 리얼 맥 스위처만 양산할 따름이라고 생각합니다. 애플은 아마도 이걸 알고 고도의 전략을 구사하고 있는 것일 테구요. 뭐 이런건 개인적인 의견으로 봐 주셨으면 합니다만...... 해킨토시는 그래서 전 솔직히 별로 추천하지 않습니다. 라이센스 문제가 있고 없고를 떠나서 애플의 시장 독점권만 키워주는 결과를 초래할테니까요. 게다가 이런 애플의 전략에 리얼맥 커뮤너티와 가짜맥(?) 커뮤너티가 갈리는 모습도 솔직히 보기가 뭣합니다.

어쨌거나... 독점이 애플에 좋지 않은면도 있습니다. 애플의 하드웨어 품질관리 문제는 이제 어느 정도 일반인들도 인식하는 분위기더군요. 독점 기업일수록 품질 관리에는 신경을 쓰지 않습니다. 대강 만들어서 팔아도 소비자들이 대체품이 없으니 그냥 쓰고 또 독점기업은 추가 a/s 플랜을 팔아서 돈을 벌 수 있으니까요. MS가 그토록 오랫동안 윈98의 블루 스크린을 고치지 않고 놓아두던 것과 비슷한 전개이죠.

semmal의 이미지

좋은 제품은 라이센스가 어떻든간에 사는 것일 뿐입니다. 맥이나 애플 제품이 좋아서 쓰는 것일뿐 다른 거창한 이유가 있을리가 없잖겠습니까? 살려고하는 냉장고를 구동하는 프로그램이 GPL을 따르지 않아서 냉장고를 안사겠다고 하시지는 않을거 아닙니까? 저도 개인적으로 맥을 소유하고 있습니다만, 애플을 소프트웨어 기업이아니라 거의 가전제품 기업으로 인식합니다.

그리고, 독점을 좋아하는 기업은 있어도 독점을 싫어하는 기업은 없습니다. 독점을 하지 않는 기업이 아니라 독점을 못하는 기업이 있겠지요. 기업이 독점을 하는게 뭐 어떤가요? 단지 MS가 독점을 하기만해서 사람들이 싫어할까요? 독점적 지위를 통해서 나쁜 짓(?)을 하기 때문이죠. 허나 애플은 그런 짓을 하기에는 아직은 파워가 모자랍니다. 전 맥을 좋아하지만 애플이 그런 짓을 한다면 당연히 싫어하게 될 겁니다. 하지만 그건 이후의 일이구요. 지금은 아닌 것 같군요.

또, 애플의 품질 관리가 제대로 되지 않은 것은 중국으로 공장을 이전하고서 부터입니다. 덕분에 많이 싸졌지만 불량률이 올라갔지요. 하지만 불량률이 나빠져도 제품에 대한 만족도가 더 좋기때문에 대체품을 안쓰는 것이지, 대체품이라 생각하는 제품은 늘 있었습니다.

애초에 "왜 애플은 애플에서 나온 소프트웨어 플랫폼을 애플 하드웨어에서만 돌려야 하는건가요?"라는 질문을 "왜 삼성은 삼성에서 나온 휴대폰 프로그램을 삼성 휴대폰에서만 돌려야 하는건가요?"라고 돌려묻고 싶습니다. 세상에 안 그런 경우가 얼마나 있겠습니까?
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

linlin의 이미지

삼성에서 나온 휴대폰 프로그램은 당연히 삼성 휴대폰에서 돌려야죠. 다만 삼성에서 휴대폰 프로그램 플랫폼이 나온다면요? 얘기가 달라지는 겁니다.

보기에는 개인차가 있겠지만 애플은 이미 독점적인 지위를 남용하고 있다고 봅니다. 하드웨어와 소프트웨어 플랫폼 양쪽의 제어권을 서로 leverage해서 시장 점유율을 확장해가고 있죠. 플랫폼에 신규 진입자를 들일 생각은 눈꼽만치도 없는 것 같고... 여기에도 양쪽 플랫폼의 제어권을 leverage해서 진입 장벽을 쳐 놓고 있죠. 진입 비용을 높이는 것뿐만이 아니고 아예 라이센스를 안주겠다는. ㅎㅎ

애플이 나중에 님이 얘기하는 나쁜 짓을 할 때 애플을 버려도 되겠지요. 하지만 MS의 경험을 돌이켜보면 이미 독점 업체가 시장을 critical mass 이상으로 점령하고 난 뒤에는 사용자가 플랫폼을 버리고 싶어도 버릴수가 없습니다. 그 땐 이미 늦어요. 그런 면에서 애플의 행보는 한 템포 먼저 위험경보를 발령할 필요가 있다고 봐요.

domain808의 이미지

^^
조금은 생각의 차이인것 같군요.
PC의 시초가 애플이었고 스티브와 워즈니악은 재미?로 창고에서 조립식 키트형식으로 주문 판매를 했을뿐이지.
원래 이런류의 하드웨어/시스템은 패쇄성을 유지했습니다.
IBM의 실수?로 인한 결과로 PC의 보급이 활발해지고 지금의 발전을 가져온것은 부정할수 없는 사실이지만.
수없는 많은 컴퓨터가 그전에 있었고 IBM PC류의 덕분에 그 경계선이 무너지며 경쟁력이 사라져 많이 사라졌습니다.
어떻게 보면 가격이 저렴해진 반면 다양한 시스템과 하드웨어를 경험의 기회를 잃어버리게 된것이죠.
어느것이 소비자의 입장에서 바로 코앞에 보이는 문제와 깊은 속내의 문제의 차이겠죠.
-.-
iTunes는 iPod을 위해 개발되고 운용하는 프로그램입니다.
이것들은 고유의 저작권을 기본으로 지키는 권리입니다.
독점이 아니라고 생각을 합니다.
자꾸만 MS을 비교하며 독점을 논하는 경우가 많은데..
MS의 독점은 시장전반에 영향력을 주기때문에 독점에 해당되는겁니다.
MS의 Windows와 Office때문에 보다 좋은 프로그램들..시스템인데 사장된 경우가 많습니다.
예전에 GeoWorks가 생각나는군요.
법적인 제재가 가해지지 않고 그냥 놔두면 사람들이 윈도우를 다 사용하게 되는 상태가 되기 때문에 법적인 제동을 거는것입니다.
^^ MS가 세상을 정복하기 위해 열라 나쁜행위를 하는것은 결코아니죠.
분명 MS는 그만큼의 독점이라는 죄명을 받을떄까지 소비자에게 만족을 주고 노력을 했습니다.
..
근대화발전의 큰목을 차지하는 컴퓨터..특히 상업적인 부흥으로 과학발전에 한목을 한 PC들..
그중에서 IBM PC 호환기종과 이 컴퓨터를 움직이게 했던 MS-DOS, Windows.
IBM의 실수로 인한 예기치않은 결과로..
PC는 기하급수적으로 보급이 진행되었고.
소프트웨어산업의 발전과 더불어 CPU의 진화등등..
하지만..
8bit때에 비해 다양한 컴퓨터를 접할 기회를 잃었죠.

물론 저는 Apple II때부터 Apple의 전기종을 사용해 보았고(^^ 예전회사가 맥관련회사라..)
NeXTSTEP, NeXT, Indigo등등 많은 컴퓨터를 사용해 보았습니다.
워낙 컴퓨터를 좋아하다보니.

해킨토시에 관심이 가는 이윤~ 유저들에게 다양성의 1%?를 부여했기 때문이죠.
하드웨어를 바꾸지 않아도 OSX를 쓸수있다는것..^^

지금 MS가 살아날수있는 방법은..
Apple의 점유률이 올라가는것 아닐까요?
독점이라는 따가운 시선을 나눌수도 있고~ ^^ 벌써 유럽은 Apple에게 많은 딴지를 걸고 있죠. 솔직히 유럽의 속내는 미국기업의 견제지만..
MS의 독점의 제동은 MS에서 문을 닫던가 DVD을 한달동안 찍지 말던가 ^^
좋은 방법은 Apple같은 회사의 시잠 점유률입니다.
그런 의미에서 점유률의 매개체가 되는 일반 PC에 OSX가 설치되는것을 바라는것이지..독점?이기때문에 설치가 되어야한다~는 아닙니다.
..
이런말은 어떨지 모르곘지만.
저도 개발자였던? 입장에서 MS가 계속 성장해주길 바랍니다.
개발자는 주기도문 외우듯이 MS에게 저주의 기도를 드리는 ^^ 관례가 있지만.
어찌되었건..
미래를 짊어지고 갈수있는 회사는 MS나 Apple 같은 회사 아니겠습니까?

생각의 차이겠죠.

linlin의 이미지

좀 자료를 찾아보시길... 홈브루 하드웨어 출신들이 만들던 하드웨어는 아예 저작권 개념 자체도 없는 public domain입니다. 애플 투에 확장슬룻이라는 기능이 들어가면서 왜 동시에 롬은 라이센스 불가라는 극과 극이 혼재하게 되었는지 좀 생각해 보시길.

MS는 Apple 과 조금 과장해 얘기하면 호혜적 협력 관계에요. 윈도우의 매출이 증가하면 매킨토시나 맥 오에스의 매출이 감소합니까? 매킨토시가 한 대 더팔리면 윈도우가 그만큼 안팔리는 건가요?

MS가 만약 윈도우 반독점 소송을 당하면 시장 독점이 아니라는 근거로 뭘 대겠습니까? 맥을 쓰시니 한때 애플이 주력하던 switch 광고를 기억할 겁니다. 이렇게 적극적으로 윈도우 사용자를 맥으로 뺏어가려는 기업이 있는데 MS가 오에스 시장에서 경쟁자가 없는 독점이라고 주장할 수 있냐... 이렇게 나올 수 있겠죠.

애플도 마찬가지입니다. 맥에서는 왜 맥오에스만 써야 합니까? 이거 시장 독점 아니냐고 시비를 걸 수 있을 겁니다. 여기에 애플이 bootcamp라는 묘안을 내놓고 있죠. 맥에서는 원한다면 윈도우 쓰는데도 아무런 문제가 없으니 우리는 시장 독점하는 것이 아니라고 주장할 수 있겠죠. 오히려 우리는 적극적으로 bootcamp같은 소프트웨어를 무료로 출시해 맥 하드웨어에서 다양한 오에스의 경쟁을 촉발하는 소위 친 시장적 정책을 펴고 있다고 주장할 겁니다.

그런데 여기에 MS가 일조를 해 주고 있습니다. Bootcamp의 실질적 지원 대상은 역시나 윈도우이니까요. 결국 MS와 애플은 각자의 시장 독점 영역을 유지하는데 서로가 서로를 암묵적으로 도와주고 있는 셈입니다. 기껏 두 회사가 경쟁하는 분야라 해봐야 mp3 player 밖에 없습니다만 이것 역시 MS와 애플이 배포 플랫폼을 갖고 있는 까닭에 하나가 팔리면 다른쪽에서 하나가 뺏기는 경쟁이 아니고 적당히 밀고 당기는 경쟁 밖에 되지 않습니다. 예전에 Netscape나 썬의 Java를 전력으로 죽이던 MS의 모습과는 사뭇 다르죠.

그런고로 애플같은 회사의 시장 점유율이 올라가봤자.... 독점 플랫폼 하나가 더 등장할 뿐이지 MS의 독점에는 하등영향이 없습니다. 오히려 MS는 윈도우의 시장독점을 위해 애플이 필요하고 애플은 맥 하드웨어/오에스 플랫폼의 독점을 위해 MS가 필요합니다. 이렇는데 어떻게 맥 사용자들 중에는 맥이 많이 쓰이면 MS의 윈도우 독점을 깨는 세상이 온다고 믿는 사람들이 그렇게 많은지 참 이해가 안되죠. 게다가 윈도우에서 되면 맥에서도 되는 경우가 많지만 맥에서 되는 것이 윈도우, 기술적으로 형제뻘이나 다름 없는 리눅스나 FreeBSD에서 되는 경우는 정말 가뭄에 콩나듯 하는데 말이죠.

뭐 그리고 유럽이 미국 회사에 견제를 건다? 유럽이 그럼 MS나 애플이 아니면 피씨용 오에스나 개인용 컴퓨터 하드웨어/오에스 번들을 공급해 줄만한 그런 유럽 회사가 있나요? MS나 애플을 견제해서 키워줄 필요가 있는 유럽 회사가 있으면 또 이런 얘기도 그런가 하겠지만 이건 근거 없는 얘기입니다. 유럽이 자꾸 MS나 애플까지 견제를 하는 것은 시장 독점의 비용 문제 때문이지 이네들이 미국 기업이라서 그런게 아닙니다.

맥오에스 텐을 일반 Pc 하드웨어에서 돌리는 것은 사실은 우둔한 짓이에요. 왜냐하면 피씨 하드웨어는 완전 개방형 플랫폼입니다. 여기에 왜 굳이 폐쇄형 오에스를 돌리며 개방형 하드웨어의 의미를 퇴색시켜 폐쇄형 하드웨어인 리얼맥의 유혹에 끊임없이 흔들리는 길을 가려는지 솔직히 좀 이해하고 싶지 않네요. 이건 다양성의 1%가 아니고 말 그래도 쓸데없는 짓입니다. 호기심에 기인한 유희이상의 기대를 안하는게 좋을 겁니다. 이러느니 차라리 그냥 윈도우 쓰시길. 맥은 소위 다양성에 일조하는 그런 플랫폼이 아니고 맥을 쓴다면 애플에 추가 세금을 납부한다는 점을 인지하고 쓰는게 필요해요.

iTunes와 iPod의 연동관계도 잘 생각해 보시길. 이게 놔둬도 되는 문제인지요. 뭐 이미 대다수의 메이저 레코드 레이블들은 애플 뮤직스토어에 납품하는 을의 신세로 전락했습니다만.

cwryu의 이미지

보통 GPL이나 LGPL의 뒤쪽 조건은 상관없는 일이 많아서 대충 넘어가게 되는데 이번 일과는 관련있는 문구가 있군요. 위에 개발자분이 남긴 글 링크를 보면 아래에 재배포가 가능한 것이냐고 물어보는 사람이 있어서 찾아봤습니다. LGPL 2.1 section 8을 보면,

Quote:
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.

이 라이센스에서 말한 아닌 방법으로 배포하면 권한이 자동으로 박탈된다. 하지만 배포받은 사람은 계속 완전한 권리를 가지고 있다.

이대로라면 capri Perian을 다운로드하셨던 분들은 거리낌없이 재배포하셔도 됩니다.

페이지