프로그램 소스 공개 않하기
글쓴이: babbab / 작성시간: 수, 2019/09/18 - 12:06오전
리눅스에서 프로그램잉을 할때, readline 라이브러리를 않쓰면 input이 잘 이뤄지지 않는데, readline이 gpl이기 때문에 readline을 프로그램 소스에 포함하면 프로그램 전체 소스를 gpl로 만들어 공개해야 되는걸로 알고 있습니다. 그래서 아이디어가 떠올랐는데 readline만 input 프로그램으로 컴파일해서 만들고 프로그램의 다른 부분들 객체의 프로그램으로 만들어 다른부분은 공개않하고 script으로 readline 프로그램이랑 다른 객체의 프로그램이랑 서로 이어줘 컴파일 할필요 없이 하면 어떨까 하며 생각합니다.
프로그램도 지적 재산이기 때문에 공개하고 싶지 않은 부분은 공개 않하고 객체로 떨어뜨리고 readline의 input만 해결하는 프로그램을 따로 만들어 scripting 으로 연결만 할 뿐이죠.
이렇면 readline은 따로의 input 프로그램이기 때문에 다른 부분도 따로의 프로그램이고 다른부분은 다른 라이센스로 낼수있고 공개를 않해도 될것같다고 생각합니다.
그니까 readline을 라이브러리로 사용않하고 객체의 input프로그램만 따로 만들어 다른 컴파일된 부분의 프로그램과 script으로 연결만 해준다 이거죠.
Forums:
않하고? 안 하고?
않하고? 안 하고?
세벌 https://sebuls.blogspot.kr/
license 가 그렇게 문제라면 그냥 libedit
license 가 그렇게 문제라면 그냥 libedit 를 사용하시는 것이 좋을 듯 싶습니다.
프로젝트 자체를 분리 하지 않는 한은 제시하신 방법은 하나의 프로그램으로 여겨질 듯 싶습니다. (즉 논란의 여지가 있을 수 있다는 얘기죠.) 그리고 readline part 없이 해당 프로그램이 동작하도록 구현을 해야 하는 문제도 있고요.
그러므로, 그렇게 해결을 하는 것 보다는 readline 기능 없이 동작하도록 한 후에, readline 기능은 plugin 이 가능 하도록 만들어 놓으시면 될 것 같습니다. 그러면 readline 기능은 plugin 으로 별도로 배포를 하면 될 거고요. (이것도 제가 볍률가가 아니기 때문에 완벽한 방법이라고 제시하기는 힘듭니다.)
그러니 이런저런 상황 따져 보았을 때는 readline 보다는 좀 모자르지만 license가 자유로운 libedit 를 선택하는 것도 한 방법 입니다. 꽁수는 항상 탈이 날 수 있습니다. 그러니 꽁수 보다는 대안이나 직접 구현하는 것을 택하는 것이 좋을 것 같습니다.
문서가 잘되있어야..
라이센스보단 어느 라이브러리의 문서가 더 잘되있냐에 따라 readline이나 libedit 쓰는걸 결정할걸 같네요. 어떻게 보면 gnu가 이런 꼼수를 쓴거같다고 생각이 들기도 하네요. 한글 한줄 읽는데 라이센스에 관계없는 fgetws같은 표준 루틴을 제대로 만들지 않았고 readline같은 gpl을 쓰게 만들게 한단 소리를 들을수도 있겠네요. 영문 프로그램은 fgets로 되겠지만.
하기야 프로그램만드는것도 자기가 필요에 의해, 자신이 쓸려고 만드는 사례가 많을것 같네요. 그리고 남이 필요하다고 생각되면 공개를 하되 소스도 공개할수 있고요. 프로그램을 완성도가 아주 높게 만들기는 힘들지만 범용 프로그램밍이라는 것도 있어 작동만 되면 BUGS 섹션에 문구로 예를 들어 이러이러 한 문자가 섞여있으면 정상 작동이 않됩니다 라고 써놓는것도 한방법이라 생각이 되네요. 문구를 않읽은 사람은 한소리 하겠지만..
문서화는 제작 시의 효율을 위한 거고, 발의하신
문서화는 제작 시의 효율을 위한 거고, 발의하신 주제는 라이센스 문제 아니었나요?
그리고, fgetws(fgets) 와 readline 은 엄연히 다른 목적을 가지고 만들어 진 것입니다. 비교를 하려면 readline 과 libedit 를 비교하셔야죠. 비교 대상이 잘못된 것 같습니다. readline 을 사용하게 하려고 fgetws 를 이렇게 만들었다는 너무 나가신 것 같아요.
fgets, readline
>문서화는 제작 시의 효율을 위한 거고, 발의하신 주제는 라이센스 문제 아니었나요?
라이센스도 고려해봐야 하지만 문서가 거의 전부라 생각합니다. 프로그램밍은 일종의 코드라 암호같은 성질이 있다고 전 생각합니다. 변수와 루틴 뜻을 다 해석하는것도 일이니와 하나라도 이해 못하면 부품이 빠진, 나사 빠진것 같죠. 문서도 너무길면 문서읽는 시간도 걸리고. 그리고 0과 1들을 무엇으로 표현한건데 무엇이라고 기록되어 있지 않으면 정말 코드나 0과 1밖으로 밖에 않보일 겁니다. 만들사람도 코드에 설명을 않적으면 몇달후에 뭘 쓴건지 모르는 코드소스입니다.
>그리고, fgetws(fgets) 와 readline 은 엄연히 다른 목적을 가지고 만들어 진 것입니다.
전 같은 문자 input을 위해 만들어 졌는데 fgets은 기초이고 (그것도 gets에서 발전된 것이지만), readline은 많이 발전된 버젼이라 생각됩니다. 저의 비교는 발단은 윈도우의 fgetws와 리눅스의 fgetws였습니다. 윈도우는 한문자를 백스페이스로 지우면 하나씩 한글이 잘 지워지는데, 리눅스에서 한글글자를 잘 지우려면 readline까지 사용해야 된다고 느낀바였습니다.
>readline 을 사용하게 하려고 fgetws 를 이렇게 만들었다는 너무 나가신 것 같아요.
너무 나갔던건 맞는것 같습니다. 영문에는 fgetws 또는 gets를 사용해도 아무문제가 없으니깐요. 영문엔 꼭 readline을 쓰지 않아도 됩니다. 영문사용자에겐 readline을 꼭 쓰게 만들의도는 아니였을 겁니다. 하지만 문자열 input같은건 너무 기초 아닙니까? 너무 기초라 표준 c 라이브러리에 포함되 있는 루틴인데. 기초를 readline이나 libedit를 써야 된다니.. 라이센스 선택도 같이 딸려오고.
흠. readline 을 사용하기 위한 용도가
흠. readline 을 사용하기 위한 용도가 말씀하신 대로라면 libedit 는 지원하지 못할 수도 있겠군요. 왜 그런 비교를 했는지 이해했습니다.
코드라는게 재밌는게
코드라는게 재밌는게 같은걸 다르게 얘기하면 못알아 들을수 있다입니다.
간단히 "해일이 온다"를 -> "새들이 날아 도망가고 바다가 갑자기 잠잠하고 동물들이나 곤충들이 동요한다라고 증조만 말하면" "해일이 온다"로 못알아 들을수 있죠. 같은거지만 한글을 영어로만 표현해도 못알아 들을수 있구요. 하지만 같은걸 다른표현으로 계속 반복해 둘러 말하면 결국은 알아들을 수도 있지요.
어떤 실제의 물체를 0과 1로 표현한것과 십진수만 0과 1로 표현해도 이게 무엇을 표현하는지 못알아 들을수 있지요 코드로서는. 어셈블리도 0과 1을 더 쉽게 알아듣게 하려고 한 언어라 봅니다. 여전히 어려워요 하지만.
그래서 문서화나 문서가 아주 중요하다고 생각됩니다. 컴퓨터가 정보기계이기도 하고 정보인 문서가 중요하고 프로그램자체는 가상머신이고 프로그램없이는 컴퓨터는 0011밖에없는 아무것도 없는 빈공간이라 봅니다.
공식문서에는 https://www.gnu.org
공식문서에는
https://www.gnu.org/licenses/gpl-faq.ko.html#GPLAndPlugins
라고 되어 있네요.
https://www.oss.kr/oss_guide/show/044d96fd-413d-4ab3-ad72-4776d2b7e002
도 참고해볼만한 문서입니다.
또는 걍 사용한 후 개인적이나 내부적으로만 사용하고, 배포를 안하면 될겁니다.
제가 만약 이해를 했다면 제생각엔..
"그것은 프로그램이 플러그인을 어떤 방식으로 실행시키는 지에 달려있습니다."
따로 프로그램을 만들어 script으로 연결하는건 첫번째 아니면 세번째에 해당되는것 같군요.
다이나믹 링크가 elf아니면 dll같기도 한데..
gpl을 쓸지않쓸지 선택이 있다고 하는데 문자열 input같은 기초루틴을 한글은 gpl인 readline을 써야 한다는게..
"두개의 모듈을 결합한다는 것은 이들이 보다 큰 하나의 프로그램을 구성하기 위해서 함께 연결된다는 뜻입니다. 이 경우 어느 한쪽이라도 GPL 프로그램이면, 결합된 전체 프로그램 또한 GPL로 공표되어야 합니다. 그렇게 하기 싫다면 프로그램들을 결합하지 않으면 됩니다."
이문구도 있는데 결국 gpl로 하란 얘기 같습니다. 자유 소프트웨어가 소스를 공개하도록 라이센스가 제작되 있다고 생각되는데 공개를 하란 얘기겠죠.
뭐 독점을 멀리하고 자유를 지키는 일이니..개방적으로 가는것에 동의는 하다만 gnu리눅스에서 gpl을 피해가긴 어려울것 같네요. 하나는 포기해야 하는 일이니
해당 부분은 linux kernel 모델을 가지고
해당 부분은 linux kernel 모델을 가지고 이해해 보세요.
linux kernel은 gpl2 입니다. 하지만 kernel module 은 gpl2 가 아닐 수 있습니다. 즉 반대도 가능 하다는 얘기입니다. licence 를 잘 이해를 하시면 가능하다고 생각 됩니다.
다만, 법률적으로 제가 보장은 못합니다. (오픈 소스 라이센스에도 대부분 이런 회피책이 있죠 ^^)