포럼
이번 사태의 마지막으로, 그리고 제안 부탁드립니다.
2015.07.20 14:57
이번 사태의 마지막으로,(또는 희망으로)
적극적으로 해명을 하고자 함이 이번 사태의 하나의 원인이라고 생각됩니다.
외부에서 보기에 이해 할 수 없다고 느낄 수도 있겠지만, 그래도 되도록이면 많은 정보와 상황으로 왜 그렇게 됬는지 설명을 하고자 했습니다.
물론 부족할 수 있고, 또 모든 사람을 이해 또는 만족시킬 수는 없겠지만, 거짓말, 행동과 말이 다른 말을 하고 싶지는 않았습니다.
다만, 여러가지 주제를 하나의 쓰레드로, 꼬리에 꼬리를 물고, 납득이 되든 안되든 하나하나 해명을 해도 쓰레드가 지나가면 또 같은 이슈로의 문의와
의견이 반대라 공격적인 자세와 반말, 그리고 이렇게 하라 저렇게 하라 지시섞인 말의 대화로는 상처만될 뿐 아무것도 해명되거나 이슈가 해결되지 않을 것 같습니다.
이 과정 속에 과장되게 말이 되고 또 와전되기도 하고, 이를 대응하는 모습을 다시보면서 정말 좋지않은 모습이였고, 잘못되가고 있다고 생각되었습니다.
그냥 죄송합니다 앞으로는 어떻게 하겠다 하는 것이 실천할 수 있는 해결점도 아니거니와, 그렇다고 미안하다고 해야할 일도 아니라고 생각됩니다.
또 지금 당장을 넘어가기 위해 실천할 수 없는 약속을 하고 싶지는 않습니다.
이 모든 것이 변명이라 생각하시는 분도 계실 것 같아, 문제였다라고 제기 한다면 대응이나 모든 것이 다 저의 부족이고 잘못이라고 말씀드리고 싶습니다.
공격적인 말을 하셔도 다 XE에 대한 애정이 있으시다고 생각됩니다만, 앞으로는 자제해 주시길 부탁드립니다.
비록 운영 등 마음에 안드셨더라도 XE에 대해 잘못되거나 부족한 것이 있다면, 참여하여 함께하는 해결하는 모습이였으면 합니다.
댓글로 제안만이 아닌 실천안과 함께 주시면, 모두 함께 같이 논의 했으면 합니다.
이번 사태를 단지 마무리 하려고 하는 것은 아닙니다. 하지만 자유게시판과 포럼에 대한 내용은 그만 논의 했으면 합니다.
PS. 궁금했던 것을 해소하는 100문 100답을 하고자 하는 것이 아닙니다. 또한 어떤 입장에 대해 답변을 달라고 이 글을 쓴 것이 아닙니다.
댓글 71
-
misol
2015.07.20 22:13
다 읽지 못해서 눈에 띄는것이 있었는지 모르겠지만.. 제 글이 그렇기 비쳤다면 죄송합니다. 저는 정말 바라는 점만 적었고.. 음... 제 생각에 이 상황 자체가 좀 안타깝습니다. 아무 일도 아닌데 서로 감정이 상하고 있는 것 같아서요.. -
wkp
2015.07.20 21:51
LGPL이라고 했으므로 별도의 저작권 기부/양도에 대한 명확한 해석이 없었다면, 일반적으로 저작권자는 기여자가 가진다고 해석할 수 있을 것입니다. 즉 해당 소스 기여분에 대한 원 출처가 기여자가 맞다면 Copyright을 기여자가 가질 것입니다.
그리고 네이버가 zero님을 고용한 것만으로는 저작권을 샀다고 할 수 없지만 소스를 완전히 구매했다면 (저작권에서 정의하는 복제권, 배포권, 대여권, 공연권 등등을 포함해서) 네이버가 저작권자가 될것이고요, copyright은 네이버측이 가집니다. 아마도 그래서 copyright을 싹 바꾼 것이라고 생각되고요. 그렇다 하더라도 원래의 저작권자를 주석에도 없이 싹 날린 것은 오픈소스의 전통과 회사 내규간의 일종의 문화 충돌로 보이고요.
네이버가 저작권자라 하더라도 1), 2)에 대해서 현재 명확히 하고있지 않으니, 여전히 새로이 추가된 소스는 기여자가 가질 것이며, 기존 소스를 바탕으로 재작성된 2차 저작물들의 저작권은 기여자와 네이버가 동시에 가지게 되겠지요.
1) 2)번이 명확히 정의된바 없다면 1)번의 해석이 타당하겠지요.
그리고 2)번으로 정확하게 저작권을 양도한다고 명시한 프로젝트가 있었던가요? 위키위키 같은 경우에는 있는 것 같습니다만
-
기진곰
2015.07.20 22:02
네이버에서 월급이나 그 밖의 지원을 받는 분들은 계약서에 저작권 관련 조항이 있을 것입니다. 대개 회사의 지원으로 개발한 프로그램은 회사에서 저작권을 갖게 되죠. 따라서 zero님이나 현재 xehub에 계신 분들의 저작권이나 주석 언급 문제는 제3자가 왈가왈부할 것이 못 됩니다. 그 밖의 기여자들만 신경쓰면 됩니다.
지금까지는 한국에서 오픈소스나 CCL 등의 저작권에 대한 인식이 별로 없었는데, 리그베다위키 사건을 계기로 전면에 부각된 것 같습니다. XE도 이번 기회에 저작권을 깔끔하게 정리해 두어야겠네요.
-
misol
2015.07.20 22:08
XE 도 기여자에 대해 정리해두고 있긴 합니다. https://www.xpressengine.com/contributors
라인별로 최근 수정자를 알 수 있다면 정리 할 수 있을거 같긴 한데, 양이 너무 방대한 것 같아요. -
기진곰
2015.07.20 22:10
누가 무엇을 수정했는지 git은 다 기억하고 있으니, 그걸 추출해내는 스크립트를 작성하는 것이 관건이겠네요.
지금도 github에서 각 파일의 blame을 클릭하면 아주 자세히 나와요 ^^
-
misol
2015.07.20 22:17
오!!!!!!.... 그런 기능이 있었다니!!! 오래 전에 기여한건 제대로 안나올 수도 있겠지만 위안이 됩니다!
파일마다 맨 마지막줄 주석에 이 파일이 대한 공헌자는 누구누구눅 누구 입니다 (영어로) 정도만 적어줘도 저는 정말 기쁠거 같아요!!! 이름 적히는 맛도 나고요!
저작권은 Naver and contributors 정도면 정말 좋겠지만, 아래 공헌자 목록만 적어줘도 저는 정말 행복감을 느낄거 같습니다.
파일 하단 주석이 안된다면, 디렉토리마다 CONTRIBUTIONS 라는 이름의 텍스트 파일을 자동 생성해서 목록을 적어주는 것도 괜찮을 것 같아요. -
wkp
2015.07.20 22:18
넵 바로 이맛에 개발하고 기여하려 노력하는거죠 ^^ 개발자가 참 단순하기는 합니다ㅎ
-
wkp
2015.07.20 22:16
그러고보니 XE는 그 흔한 AUTHORS 문서도 없었군요....
네이버의 또다른 프로젝트인 nFORGE의 AUTHORS 문서를 참고하시기 바랍니다. (제 이름도 있네요ㅎ)
http://dev.naver.com/scm/viewvc.php/trunk/nforge/AUTHORS?root=nforge
회사에서 오픈소스 프로젝트를 진행한다면 오픈소스의 문화를 먼저 친숙해져야 할것입니다. 바꿔야 하면 과감히 바꿔야겠죠. 내부적으로 못바꾼다면 외부에서라도 지적을 해야 할것입니다. 개발자 실명제를 할 것을 당시 제안하신 분이 이 프로젝트 PM이었던 KLDP의 운영자이기도 한 권XX님이셨고, 제가 적극 찬성했었지요.
http://dev.naver.com/scm/viewvc.php/trunk/nforge/install_util.php?view=markup&revision=5014&root=nforge
소스 상단에 다음 주석을 참고하세요. semtlnori님인 현재 yobi 개발자시기도 합니다.
Smart installation module by semtlnori
-
XE
2015.07.20 22:32
언젠가 한번 정리하고자 했던 내용들입니다. 여타 다른 이슈로 인해 멀어졌던 내용이기는 합니다.
단지 지적에서 그치지 않고 제안과 직접 참여를 해주시면 좋겠네요. -
misol
2015.07.20 22:37
위에 댓글 쓰신 분들이 참여를 안하시는 분들은 아닌 것 같아요. 적절한 지적은 아닌 것 같습니다.
문제점을 인식해야 그 문제점에서 출발해 제안을 할 수 있는 것이고, 제안이 있어야 그것을 바탕으로 실천할 수 있지 않을까요?.. XE님 상황을 긍정적으로 보실 필요도 있는 것 같습니다.
PS. 댓글이 바뀌었네요! 긍정적인 피드백 감사합니다.
-
wkp
2015.07.20 22:42
???
제가 낸 제안이 이 글타래만 봐도 여러가지네요. 대표적으로 1)커미터 외부 개발자 지정. 2) XE 소스에 개발자 실명제를 하면 좋겠다는 제안아닌 제안. (일반 개발자, XE 개발자 모두 포함)
이 토론에 이미 참여하고 있는게 참여라면 참여이며, 제 PR이 XE 소스에 반영되길 기대하는 한 개발자입니다. 제가 xe-core에 올린 PR은 현재 6개밖에 안됩니다만. 제가 처음 제안해서 현재 가장 신경쓰고 있는 PR입니다. https://github.com/xpressengine/xe-core/pull/1598 @기진곰 님도 함께 관련 PR을 보완하고 별도로 개발하고 계시지요. 포럼에 올라와 있는 https://www.xpressengine.com/forum/23040664 글 읽지 않으셨다면 시간되실때 읽어보시기 바랍니다.
-
misol
2015.07.20 22:26
사용자 참여를 많이 기다리시는거 같아서 생각을 더 그런 쪽을 해봤어요. 어떤 PR이 올라오면 사용자들끼리 테스트 해보고 테스트한 환경과 그 결과를 댓글로 적어두면 도움이 될것 같아요.
그러려면 원글 작성자가 PR의 의도를 자세히 작성해주면 도움이 되겠지요!
XE 팀은 정책에 위배되는 PR이 아니라면 사용자의 피드백을 통해서 테스트를 해도 빠질 수 있는 빈 구멍을 조금 더 피할 수 있는 장점이 있습니다.
이건 XE팀 허락이 필요한게 아니니 지금부터 저는 하겠습니다 :)PS. 댓글로 적다보니, 괜찮은 정보가 될 것 같긴 합니다. 적길 잘한 것 같습니다.
PS2. 여기엔 좋아요 말곤 아무도 반응이 없군요.. 그래요.. 실천방안까지 저 스스로 다 한다는 제안은 이렇게 별 반응이 있기 어렵습니다...
-
wkp
2015.07.20 23:46
이정도면 하고싶은 얘기 다 한 것 같고,
커미터 관련된 얘기는 개발자들만 관심을 가지고 있는 것 같고, XE개발자들 내에서도 의견조율이 필요할 듯 싶으니 당장에 실현되기도 힘들것 같고요.
오래된 PR 발굴작업이나 해봐야겠습니다. 현재 아직 닫혀있지 않은 Pull Request는 60여개나 됩니다. 오래된 PR중에 건질만한것이 한두개는 넘겠지요
-
기진곰
2015.07.21 00:15
테스트와 관련해서 한 가지 더 제안드립니다.
지금은 develop 브랜치에 PR을 merge한 후, 새 버전 릴리즈 때마다 일괄적으로 master 브랜치에 올려보내고 있습니다. 즉, develop 브랜치에 뭔가를 merge한다는 것은 곧 그것을 차기 버전에 적용하겠다는 뜻이 되어 버립니다. 가끔 revert되는 경우가 있긴 하지만, 어디까지나 예외이고요.
그래서 어떤 PR을 차기 버전에 적용하겠다고 결정하기 전까지는 develop 브랜치에도 감히 merge할 수가 없습니다. develop 브랜치에 뭔가를 merge하는 것이 상당히 부담스러워지는 것입니다. master 브랜치에 merge하는 것이 부담스러워야 하는 것은 당연하지만, 그 부담을 덜기 위해 develop 브랜치를 따로 두는 건데... 비슷한 상황이 되어버렸어요. PR이 오랫동안 방치되고, 나비효과 걱정에 밤잠을 설치시는(?) 것도 이것 때문이 아닌가 합니다.
게다가 테스트하는 입장에서도 모든 PR을 일일이 checkout하여 테스트하기는 쉽지 않습니다. 즉, 지금의 PR 처리 방식은 커미터 분들에게 부담을 드리는 것은 물론, 제대로 테스트하기에도 어려운 구조입니다. (대표적인 예로 #1461이 있었습니다. 몇몇 분들이라도 실제 상황에서 테스트해 보셨다면 유니코드 문제를 즉시 발견했을 텐데요.)
그래서 약간 다른 구조를 제안드릴까 합니다.
1.8.x 정식 릴리즈와 별도로, develop 브랜치에게 unstable version의 역할을 맡기는 것입니다.
당장 눈에 띄는 문제가 없는 PR은 가능한 빨리 (예: 1주일 이내에) develop 브랜치에 merge하고, 테스트에 관심이 있거나 최신 기능을 먼저 써보고 싶은 분들은 develop 브랜치를 사용해 보라고 권하는 것입니다. (매일 git pull 해주는 것은 필수!)
여기서 한동안 (예: 1개월간) 문제가 없으면 관련 커밋만 git cherry-pick해서 master 브랜치로 올려보내면 됩니다. develop 브랜치를 통째로 master에 올려보내는 게 아니고요. 안정화된 기능들만 올려보내고, 나머지는 안정화될 때까지 두 달이고 석달이고 그냥 놔두면 돼요. svn이라면 골치아프겠지만, git이라면 이런 것도 얼마든지 가능합니다.
이렇게 하면 PR도 빨리빨리 처리가 가능하고, 더 폭넓은 테스트가 가능하고, PR에 어떤 식으로든 반응을 보이기 전에 차기 버전 적용 여부부터 결정해야 한다는 부담 역시 덜 수 있지 않을까 합니다. 덜컥 merge했다가 문제가 생기면 master 브랜치로 올려보내지 않으면 그만이니까요.
꼭 develop이 아니라 다른 브랜치여도 상관없습니다. 더 큰 프로젝트들은 셋으로 나누기도 합니다. 파이어폭스 브라우저의 경우 안정화 버전은 stable, 다음 안정화 버전에 포함시킬 기능들만 골라서 심화테스트하는 곳은 beta, 그때그때 새 기능을 테스트하는 곳은 aurora 또는 developer edition으로 되어 있지요.
-
misol
2015.07.21 00:37
다른 브랜치로 하는 것도 나쁘지 않을 것 같고, 저는 그런 용도로 브랜치를 하나 시작했습니다. -
플레이캠핑
2015.08.18 10:56
자유게시판을 없앤것이 아주 좋은 결정이었다고 생각합니다.
자유게시판이 사라졌는데도 공격적인 자세에 반말이 이정도인데
소통을 부르짖는 몇몇 사람들 보면 자신의 뜻과 다르면 소통이 아닌 공격을 하던데
그런식의 공격적인 행동이 소통이라면 앞으로도 현 상태를 유지하는것이 좋다고생각합니다.
XE팀의 결정을 존중하며 소통의 공간이 필요하다면 그 소통이 필요하다는분들끼리 만들면 아주좋겠네요.
-
XESTUDIO
2015.08.18 22:19
논쟁을 떠나서 대화하는 상대방의 입장을 고려해 조금만 더 조심히 말할수있는 능력을 길러야할것같습니다.
의식하거나 의식하지 못했던지 간에, 사람들은 자신의 의견이 더 맞음을 강요하면서 자신의 의견을 정당화하며 토론이아닌 논쟁을 하고 있는 것 처럼 보입니다.
이는 '안타까움'이나 '관심'이 아닌 정신적으로 문제있는 사람들이 자신의 감정을 스스로 해결하지 못해 남에게 감정적인 교환을 요구함으로서 필요한 욕구를 채우는 부당한 정신적 행위일 뿐입니다.
XE 팀으로부터 반응을 바라지마시고, 스스로 문제가 무엇인지 생각하신다음에 자신의 표현이 정당한지, 그것이 올바른 방법으로 잘 전달되었는지를 고려하셨으면 좋겠습니다.
개발자와 디자이너들은 좀 더 높은 수준에서의 대화를 누릴 자격이있고, 충분히 적절한 논리적대화가 가능한 사람들입니다.
-
crebill
2015.08.20 02:05
좋은 말씀같아요.원래 논쟁이 논쟁을 낳고 그래요. 주고받다 보면 서로간에 감정이 상해지고 농도가 점점 올라가게되요. 역지사지로 생각해서 상대방을 배려하는 마음자세가 있는 분이면 얼마든지 절제력있게 자신의 생각을 전달할 수 있는데, 자기 의견에 토를 달면 성질나는게 사람의 심성이라, 상대방은 틀리고 자기는 옳다고 착각하게 되거든요.
그리고 자기가 상대방보다 조금이라도 유식하다 생각되면 자기도 모르게 상대방을 은근히 갑의 입장에서 건방지게 지적하는 듯한 자세로 바라보게 되고 그러거든요. 사람이니까..어느정도 이해 할 수 밖에 없는것 같아요. 상대방의 글이 좀 거슬린다고 해서 하나하나 꼬치꼬치 깨대고 깝죽대고 하면 그건 소통하자고 하는 자세가 아니라 생각합니다. 더러는 넘길수 도 있는 자비의 마음자세가 필요한 것 같습니다.
-
바람별
2015.08.21 10:51
사태 사태라
사태는 아롱사태인가
-
기진곰
2015.08.21 10:59
사태가 어쩌고저쩌고 무거운 말들을 쓰니까 오히려 더 무거워지는 것 같네요. 저도 반성합니다. 감정 상하신 분들도 언제 사태나 함께 구워먹으며 회포를 푸실 수 있으면 좋겠습니다 ^^
-
chansol
2015.08.23 14:18
오랜만에 와서 무슨 일이 생겼나 싶었는데.. 잠깐 훑어보니 저작권 관련 분쟁인 것 같네요.
다 끝난 와중에 다시 꺼내는 것은 저도 싫지만, XE 측에서도 기분 나쁜 이야기들로만 받아들이지 않으시고 참고하셔서 다음 버전에는 저작권 관련 부분은 확실히 해두시는 것이 어떨까요. 향후 이 문제로 법적인 문제도 생길 소지도 있고, 예부터 과전이하라고 사전에 미리 잘 가다듬어 놓으면 이번 일을 가장 잘 해결하는 모습이 될 것 같은 마음에 의견을 남깁니다. :-)