그누보드 라이센스가 LGPL 로 바뀐다면 > 설문게시판

설문게시판

그누보드 라이센스가 LGPL 로 바뀐다면 정보

그누보드 라이센스가 LGPL 로 바뀐다면

본문

나타날수 있는 문제점들에 대해 논의해 보았으면 합니다.

 

또는 LGPL 에 대한 질문도 괜찮습니다.

 

http://korea.gnu.org/people/chsong/copyleft/lgpl.ko.html 

 

 

라이센스를 바꾸려는 이유 : 

 

수익을 내야 운영이 되는 서드파티 개발사는 GPL 라이센스로는 아무것도 얻지 못하게 될지도 모릅니다.

그누보드에 서드파티 제품들이 없었다면 지금까지 SIR 힘만으로 운영을 해올수 있었을까요? ...

이 분들께서 수익을 얻을수 있는 길을 여는 것이 그누보드의 저작자인 저희 SIR에서 할일이라고 생각했기 때문입니다.

댓글 전체

아마도
(라이센스의 내용이 제가 얘기하는 것과 다를수 있기 때문에 아마도 라고 표현했습니다. 라이센스가 제 글 보다 우선합니다.)
LGPL V2.1 은 GPL V2 에서 파생된 것으로 알고 있습니다.
우리가 흔히 말하는 GPL 은 일반적으로 GPL v2 를 일컫는것 같습니다.
버전별 차이점은 검색으로 해결하셔야 할것 같네요.
GPLv1
GPL의 버전 1은 1989년 1월에 발표되었다(GPLv1 전문). 이것은 자유 소프트웨어에서의 두 가지 중요한 자유를 보장해 주었는데, 하나는 프로그램의 소스 코드를 공개하지 않은 채 바이너리 파일만 배포하는 것을 막는 경우로 이것을 막기 위해 GPLv1에는 프로그램을 GPLv1로 배포할 때는 사람이 이해하기 쉬운 소스 코드를 같이 배포해야 한다는 조건이 들어갔다.

두 번째 문제는 프로그램에 추가적인 제약을 걸 가능성이 있다는 점이었고, 이를 막기 위해 GPLv1 프로그램을 수정한 프로그램은 원래 프로그램과 마찬가지로 GPLv1을 따라야 한다는 조건이 들어갔다.


GPLv2
GPL 버전 2는 1991년 6월에 발표되었다(GPLv2 전문). 중요한 변경 사항은 "자유냐 죽음이냐"Section 7 에 자세히 명시되어 있다. 이 내용은 GPL 라이선스 프로그램을 배포하는 것을 막는 조건, 예컨대, 특허로 인하여 추가적으로 돈을 지불해야 한다거나 하는 일이 발생하여, 소스 코드의 공개가 불가능하고 실행 바이너리 프로그램만 배포하려고 한다면, 소스 코드 뿐만 아니라, 실행 바이너리 프로그램 조차 배포할 수 없도록 보완했다.

그리고 1990년대에 이르러서는 소프트웨어 라이브러리에 대해서는 좀 더 덜 강력한 GPL 라이선스가 전략적으로 유용하다는 것이 배포되었다. 이에 대한 내용을 LGPL(the Library General Public License)이라고 하여, 1991년 6월에 발표된 GPLv2와 동시에 같이 발표되었다. 이 두가지의 내용은 1999년 LGPL v2.1로 발전되었고 LGPL(GNU Lesser General Public License)로 명명되었다.

GPLv3
GPL 버전 3은 2007년 6월 29일에 발표되었다.

2005년 후반에 자유 소프트웨어 재단에서 GPL의 세 번째 판을 개발할 것이라고 발표했다. 2006년 1월 16일 첫 번째 초안이 발표되었다. 2판과 다른 점도 비공식적으로 나와 있다 [1].

2006년 2월 25일 벨기에 브뤼셀에서 열린 FOSDEM 발표에서 리처드 스톨만은 다음과 같이 말했다.

바뀐 점 중에서 가장 중요한 4가지를 말하자면, 소프트웨어 특허에 대처하는 것, 다른 라이선스와의 호환성, 어떤 부분의 원시 코드와 무엇이 GPL이 포함되어야 하는 원시 코드를 구성하는지와 디지털 제한 관리(Digital Restrictions Management)에 신경을 썼다.
2006년, 자유 소프트웨어 재단은 GPL의 바뀔 수 있는 부분에 대해서 열두달간의 공공자문회를 가졌다. 이 과정에서 자유 소프트웨어 재단, 소프트웨어 자유 법률 센터, 유럽 자유 소프트웨어 재단이 의견을 조정한다.

출처: http://ko.wikipedia.org/wiki/GNU_%EC%9D%BC%EB%B0%98_%EA%B3%B5%EC%A4%91_%EC%82%AC%EC%9A%A9_%ED%97%88%EA%B0%80%EC%84%9C











참조: http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
참조2: http://stackoverflow.com/questions/1394623/can-i-dynamically-call-a-lgpl-gpl-software-in-my-closed-source-application

참조3: http://darkpgmr.tistory.com/89
참조4: https://kldp.org/node/55660#comment-224847



ps. GPL의 종류및 어떤 라이센스인지 알아야 많은 분들이 참여 가능할것 같아서요 ㅎㅎ
ps2. 회원분들의 정확한 인지와 판단을 위해서 이댓글에 사설은 포함 되있지 않았습니다.
2차 저작물에 해당되지만 않으면 어떠한 조건으로든 배포할 수 있다라는 것이 판매자에게 좀 더 유리한 라이선스 같습니다. 근데 2차 저작물을 어디까지로 볼건가가 애매하네요. 아래 글에 따르면 레이아웃, 스킨, 플러그인 90% 이상이 그누보드의 함수나 그누보드에서 생성한 데이터베이스에 접근하기 때문에 2차 저작물에 해당할 것 같아서 말이죠. 그럼 결국 매한가진데 ㅠ

따지고 들면 2차 저작물에 해당되지 않는게 얼마나 될까 라는 생각에서....확실하려면 그누4나 워드프레스와 같이 예외 항목이 들어가는 것이 보다 안심(?)이 되겠네요.

어떤 프로그램이 라이브러리와 함께 링크되면, 그 라이브러리가 정적으로 링크되든지 공유 라이브러리로 사용되든지 간에, 이 두 개의 조합은 법적으로 볼 때 결합저작물, 즉 최초의 라이브러리로부터 파생된 2차적 저작물로 간주된다.
GPL은 이러한 형태의 링크가 일어날 경우에 결합된 전체 저작물이 GPL을 만족할 때에 한해서만 링크를 허용합니다. 그러나 LGPL은 보다 유연한 링크 조건을 허용하고 있습니다.

이 내용을 빠뜨리신것 같습니다.
XE가 몇 년 전부터 LGPL을 채택하고 있죠. XE는 라이센스 변경으로 무엇을 얻고 무엇을 잃었는지를 자세히 알아보고, 그걸 타산지석으로 삼되 XE와 그누보드의 차이를 감안하는 것이 좋겠다고 생각합니다.

GPL에 대한 인식의 부족으로 불필요한 오해와 걱정을 낳는 것이 아닌지도 한번 점검해 볼 필요가 있겠습니다.

예를 들면 워드프레스와 드루팔 등 해외 유명 CMS들이 스킨과 플러그인 제작자들에게 GPL 예외를 허용하고 있다는 썰이 널리 퍼져 있는데, 이건 거짓입니다. 워드프레스와 드루팔은 모든 스킨과 플러그인에 GPL을 따를 것을 강력하게 요구합니다. 2차저작물의 범위에 대한 해석이 다를 수 있다는 사실을 인정하면서도, 자기들은 최대한 넓은 범위로 해석하죠.

그런데도 유료 워드프레스 스킨 판매자들이 전세계에 널려있습니다. GPL에 따르면 해당 스킨이나 플러그인을 구입하는 고객에게만 소스를 주면 되거든요. 일반적인 오해와 달리, 불특정다수에게 공개할 필요가 전혀 없습니다. (물론 ionCube 등을 사용해서 소스를 암호화하여 판매한다면 불법이 되므로, 구입자가 소스를 제3자에게 마구 퍼뜨리는 것을 막기 위한 별도의 계약이 필요할 수도 있습니다.) 이렇게 폭넓은 자유를 보장하는데도 거기에 만족하지 못하는 스킨이나 플러그인 제작자가 있다면 GPL이 아니라 LGPL 라이센스를 쓰더라도 과연 만족할 수 있을지 의문입니다. LGPL도 싫으니 BSD 라이센스로 해달라고 요구하는 싸가지바가지도 가끔 있거든요.

같은 GPL이나 LGPL이라도 v2와 v3의 차이에 대해서는 거의 알려진 바가 없죠. GPLv3로 해놓으면 엄청나게 위험한 줄 알고 있는 사람들도 많습니다. 새로 나온 AGPLv3와 혼동하는 바람에 생기는 현상이죠. 오픈소스 라이센스에 대한 인식이 부족한 상황에서는 어쩔 수 없는 현상이기도 합니다. 따라서 그누보드의 라이센스를 무엇으로 결정하든, 단지 라이센스 한글 번역본을 포함하는 것으로는 부족할 것 같습니다. 무엇이 가능하고 무엇이 안되는지 알기 쉽게 설명해 주는 페이지가 필요해요.
"구입자가 소스를 제3자에게 마구 퍼뜨리는 것을 막기 위한 별도의 계약이 필요할 수도 있습니다."
이런 방식이 GPL 에서도 가능하다는 말씀이신지요?

GPL 보다 유연한 라이센스를 고려하게 된것은 빌더를 전문으로 개발하는 개발사들을 위한 것이기도 합니다.

빌더를 전문으로 개발하는 개발사의 빌더가 개인들이 개발한 빌더보다 반드시 더 낫다라고 얘기할수는 없지만 개발사의 빌더는 꾸준하게 버전업이 되는것을 확인하실수 있습니다.
http://sir.co.kr/bbs/board.php?bo_table=g4_builder

빌더가 꾸준하게 버전업이 되려면 일정 수익이 보장되어야 하는데 GPL 하에서는 소스를 반드시 노출해야 하므로 이래저래 개발사의 고민이 클수밖에 없습니다.

그누보드나 SIR 홈페이지의 활성화를 위해서는 개인적으로 서드파티 제품에 맞는 라이센스로 변경되는 것이 맞다고 생각합니다.
두 가지 서로 다른 의미를 전달하려고 했는데, 편집 과정에서 이상하게 표현된 것 같네요. 죄송합니다.

1) 빌더 개발사와 최종 사용자간의 계약

물론 2차저작물의 제작자가 원본 저작물의 라이센스에 어긋나는 조건을 추가하여 배포할 수는 없습니다. 따라서 최종 사용자가 소스를 공개하지 못하도록 "강제"할 수는 없지요.

그러나 고객지원이나 API 연동 등의 부가서비스가 필요하거나, 그 밖에도 조금이라도 클라우드/SaaS와 관련이 있는 프로그램이라면 소스만 갖고는 아무 것도 되질 않습니다. 따라서 GPL이 부여하는 권리를 구입자가 행사하지 않는 조건으로 고객지원이나 부가서비스를 제공하여 "회유"하는 방식의 별도 계약을 할 수 있죠.

실제로 많은 워드프레스 스킨 제작자들이 고객지원과 자동 업데이트 서비스 제공을 조건으로 돈을 받고 있어요. GPL이 부여하는 권리를 실제로 행사했다가는 부가서비스 이용에 필요한 라이센스 키를 박탈당하는 수가 있습니다 -_-

2) SIR과 빌더 개발사간의 계약

빌더를 전문적으로 제작하는 곳이 그렇게 많은 것도 아니니까, LGPL 적용을 받기 원한다면 별도로 협의하도록 요구할 수 있어요. 고객지원이나 부가서비스로 고객을 회유할 수 있는 형태의 빌더가 아니라면 이 방법이 유일합니다.

수익의 몇%를 조건으로 "허가제"를 실시할 것인지, 아니면 단지 "LGPL을 남용하기 전에 한 번 더 생각해 보시죠"라는 의미에서 "신고제"로만 할 것인지, 신고제로 하되 일정한 금액(예: 5만원)을 지불하도록 할 것인지는 저작권자 맘대로입니다.

심지어 무료로 허용하더라도 약간의 절차를 거치도록 함으로써, 수익성도 없는 단순한 스킨이나 플러그인들이 함부로 GPL의 정신을 훼손하는 것을 방지하고, 반면에 꼭 필요한 사람이나 회사에게는 융통성을 발휘할 수 있다는 면에서 이런 종류의 "별도 계약" 절차는 꽤 쓸모가 있을 거라고 생각합니다. 영카트 및 부가서비스 판매 경험이 있는 SIR의 입장에서도 딱히 새로운 사업 아이템은 아닐 테고요.
죄송하긴요. 괜찮습니다.

1) 빌더 개발사에서는 GPL 이 개발사의 소스 코드가 남발하는 형태로 변질되는 것을 우려하는것 같습니다.
수정이나 배포에 대한 제한을 하게 되지 못한다면 소스를 감추어 판매하는 형태가 되어야 하는데 GPL 은 걸림돌이 되기 때문입니다. 사실 고객지원이나 API 지원등으로 제한을 걸수 있는 부분이 있겠으나 이런 방식으로 운영해 보지 않은 개발사들은 걱정이 앞설수 있겠지요.

일전에 영카트4의 중요한 부분을 Zend Encoding 하여 판매를 하였는데 Zend Optimizer 가 설치되어 있지 않는 서버가 가끔씩 있어 귀찮기도 해서 소스코드를 완전히 오픈했습니다. 그 이후로 판매량이 줄어들지 알았는데 소스를 암호화 했을때와 별반 차이가 없었습니다.

영카트4 프로그램 구입시 도메인 등록을 해놓게 되어 있는데 질문을 하려면 도메인을 선택해서 질문을 해야 했습니다.
지금까지 구입하지 않고 질문을 하시는 분은 한분도 없었던 것으로 생각됩니다.

2) 사실 구분해서 제한을 두는것에는 익숙치가 못합니다.
아니면 게으른것도 이유가 될수 있습니다. ^^
영카트5의 오픈소스 공개는 고객지원의 최소화가 그 첫번째 이유이며, 고객지원 시간을 줄여 개발에만 전념하자는 것이 었습니다. 고객지원을 더 만들어 내는 일은 벌이고 싶지 않습니다.
네, 많은 분들이 소스를 오픈하면 무단복제가 난무할 것이라고 생각하지만 실제로는 그렇지 않은 경우가 대부분이죠. 누구나 사용할 수 있는 데스크탑용 프로그램이 아닌 이상, 99%는 괜한 걱정이라고 생각합니다. 그래서 만약 라이센스를 변경할 경우 실제 이득보다는 괜한 걱정만 부추기는 결과가 되지 아닐까 하는 생각도 들고요... 반면, 괜한 걱정이라도 사업에 영향을 미치는 것은 분명하니까 어떻게든 대책이 필요한 건 사실이죠.

어차피 오픈소스 라이센스는 저작권 소송이 두려워서라기보다는 양심에 따라 지키는 것이 일반적이죠. GPL/LGPL 듀얼 라이센스로 하면서 고객지원과 무관하게 LGPL 적용 셀프신고 게시판을 만드는 것도 괜찮겠습니다. 불필요한 LGPL 사용에 대한 자정작용이 일어나기를 기대해 보는 거죠.
GPL or LGPL 두 라이센스의 문제이기보다는
사용자의 인식이 바뀌지 않는 상태에서는 교체한다고해서 큰 의미는 없을것 같습니다.
GPL은 소스코드 공개의무와 라이센스의 상속이 아닐까 합니다.
LGPL은 소스코드 제공의무가 없고 결합저작물에 대한 별도의 라이센스를 허용하지만, 복제, 배포의 자유를 제한할경우에는 허용되지 않는다라고 명시된걸로 알고 있습니다.
따라서 라이센스로만 따지자면 복제, 배포의 자유를 제한할 조항이 없는 관계로 결합저작물에 관해서 적극적인 방어가 무의미해지므로 예외 조항을 주지 않으면 도긴개긴 상태를 벗어 날수 없는 관계로 2차 저작물의 적극적인 참여를 기대할수 없을 것으로 생각 되어집니다.

앞에서도 언급했다시피 법(라이센스) vs 문화(인식)로 풀수 밖에 없다고 생각되어집니다.
국내외 실정상 개발자들의 문화공감대는 있다고 믿지만, 일부 사용자들로 인해서 문화로는 풀기가 쉽지 않을것으로 예상됩니다.

라이센스 뭐가 문제?
GPL의 레드햇의 사례 - 유료지원 모델 사용 CentOS를 막지는 못했다...
GPL or MIT의 JQuery의 사례 - 웹개발한다면 모르면 간첩... 적극적인 참여의 공유 생태계 조성

그래서 어떻게 하면 좋을까?
리자님의 생각이 공유 생태계의 조성이라고 가정한다면,
GPL은 현행되로 유지 파생 결합 저작물에 대해서 GPL에 기반해서 몇가지 예외조항제시
1. 파생 2차저작물에 대해서는 저작권 및 복제, 배포의 권한을 별도로 설정할수 있다.
2. 소스코드의 암호화 및 난독화는 권장하지 않는다.
  단, 독립적으로 실행가능한 라이브러리(php 등)의 포팅시에는 해당 라이브러리에 대해서만 일부는 허용한다.(LGPL)

사례) 스킨을 제작시
사용자화면(UI)에서 실행되는 부분은 파생 2차저작권을 인정하며 별도의 라이센스 설정가능

사례) 플러그인 제작시
의존성이 약한 부가적인 기능 및 독립적인 라이러브리 결합시에는 별도의 라이센스 설정가능

결론은 파생 2차저작물의 권한을 보호 할수 있게 예외 조항을 둘지 아니면 완전한 자유(MIT)를 줄것인지 결정하시면 어느정도 답이 나오지 않을까요?
자바스크립트 소스로 배포하는 jQuery 와 완성된 애플리케이션 형태로 제공하는 그누보드는 차원이 틀리다고 할수 있겠습니다.
완전한 자유(MIT)에 대해 생각을 해보지 않은것은 아니나 아직은 저희 회사의 경쟁력이 그만큼 높지 않다고 생각하여 MIT 까지는 고려하지 않고 있습니다.
파생되는 2차 저작물의 권한을 보호할수 있게 하는 라이센스는 현재로서는 LGPL 이 최적이라고 봅니다.
전체 354
설문게시판 내용 검색

회원로그인

진행중 포인트경매

  1. 참여0 회 시작24.03.28 11:15 종료24.04.04 11:15
(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT