좀만 더 가자... 루비면 벌써 끝났을걸.. 한시간째 ㅠㅠ
자체 제작해서 GObject 교체할 거임!!! 진짜임!!!
c 언어로 인터페이스를 이렇게 만듦
typedef struct _Language Language;
struct _Language
{
char * (* get_id) (Language *lang);
int (* filter) (Language *lang, int a);
};
#include
#include
#include
#include "lang.h"
int language_filter (Language *lang, int a)
{
if (lang->filter)
return lang->filter (lang, a);
return 0;
}
int main (int argc, char **argv)
{
void *lib;
char *errstr;
Language *lang;
Language * (* language_new) ();
lib = dlopen ("./kor.so", RTLD_LAZY | RTLD_LOCAL);
if (!lib)
{
printf ("%s\n", dlerror ());
return 1;
}
language_new = dlsym (lib, "language_new");
if ((errstr = dlerror ()))
{
printf ("%s\n", errstr);
return 1;
}
lang = language_new ();
printf ("%s\n", lang->get_id (lang) );
printf ("%d\n", lang->filter (lang, 2));
printf ("%d\n", language_filter (lang, 2));
dlclose (lib);
return 0;
}
중간에 폰트가 바뀌는 느낌 ㅇㅅㅇ 코드는 깔끔한것 같아요. - dc App
다국어 지원 플러그인 만드는건가보네
예전에 glib로 만들었었는데 그거 재구현 중임. glib를 쓰다보니 c언어로 구현하는걸 다 까먹었음
어제 올렸던 사전에 쓰는 거면 어차피 gtk 쓰는데 왜 gmodule 안 씀?
인터페이스가 glib 에 종속되는 것을 방지하여 mac, ms, 리눅스, bsd 등에서 라이선스 문제없이 사용 가능하도록 하기 위함
glib은 lgpl이고 쓰고 있는 gtk가 이미 lgpl이잖음. 그리고 동적 링킹 걸면 되는데 굳이?
LGPL 로 glib 를 라이선스 받아서 쓰는건데, glib 의 함수(헤더파일)를 사용하여 소스코드를 작성하는데 작성한 코드를 퍼블릭 도메인으로 한다고 고려해보면
내 생각엔 그게 안 될거 같아.. 내가 작성한 코드는 내가 저작권을 가지겠지만, glib 함수(헤더파일)까지 퍼블릭도메인 선언되버리잖아.
LGPL 끌어다쓰면 BSD나 퍼블릭도메인으로 선언하는게 안 될 거 같음.
나랑 님 둘 중 한 명은 LGPL을 잘못 알고 있는 듯
LGPL-2.1 5장 "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
LGPL 을 사용(헤더파일, 링킹)하면 LGPL 라이선스 고지를 해야하는데, 그래서 퍼블릭도메인으로 선언하는 건 불가하다고 보는데..
LGPL은 GPL로 바꾸는 게 가능하고 GPL은 퍼블릭 도메인이랑 호환 쉽간웅인데숭 ㅇㅅㅇ
그건 자기가 원저자일 때 얘기구
lgpl 3조 말한 거임. 애초에 gtk를 쓰면서 glib은 걱정하는 이유가 뭐임? gtk도 lgpl이고 의존성으로 glib이 같이 딸려 오는데 ʕ·ᴥ· ʔ
ui 분리.사전 말구.. 다른게 있는데.. 사실은 미래에 퍼블릭 도메인으로 풀고 싶음. 퍼블릭 도메인이면 저작권이 없다는거 공공재. 근데 glib 썼으면 라이선스 고지해야되. 그런 퍼블릭도메인이 아니라는거지
실제 퍼블릭도메인 선언한 소프트웨어를 보면 라이브러리 안 쓰고 자체 구현한 것 같음. sqlite, 7z. 만약 LGPL DB 라이브러리로 DB 를 구현했다고 할 때, 그걸 퍼블릭도메인화 할 수 없지
글쎄, LGPL 라이브러리를 써도 BSD로 풀든 퍼블릭 도메인으로 풀든 님 마음일 것 같은데... GNU 홈페이지에도 퍼블릭 도메인은 GPL이랑 호환된다고 적혀 있음. 정 걱정되면 제대로 알아보고 하는 게 나을 것 같음.
https://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL
퍼블릭 도메인(저작권 없는) 코드 GPL 아니라도 어디라도 결합 가능. 결합되더라도 원래 퍼블릭 도메인 코드는 그 상태이겠지만, 결합시켜서 배포하면 배포하는 거는 GPL 되어야 함.
그러나까.. 내가 순수 작성한 코드에 LGPL, GPL, BSD 라이선스 받은 코드를 섞게 되면 내가 순수 작성한 코드는 내꺼 그 상태이겠지만, 배포하게 되면 최종 배포 라이선스에 영향을 줌. 자신의 코드에 타인의 LGPL 또는 BSD 결합하여 퍼블린 도메인화 한 경우를 아직까지 본 적이 없음.
코드를 섞는 게 아니라 그냥 동적 링킹하면 되는데. 아니면 런타임으로 LGPL 라이브러리 쓰는 것도 싫다는 거임? 그러면 어쩔 수 없고.
동적 링킹이 문제가 없으려면 libc,ruby 처럼 명세와 구현이 분리가 된 경우는 문제가 없는데, glib 는 명세는 없고 구현체 1개 뿐임. glib 에 있는 GHashTable, GPtrArray 등의 자료 구조로 뭔가를 만들었다고 하면, 그리고 GTypeModule 로 glib 의 플러그인 시스템을 사용하는 거라면 단순한 동적 링크라고 보기는 어려울 거 같은데. gobject , gtype 을 사용하면 glib 에 강하게 종속되어 다른 걸로 대체가 안 됨. 그것만 따로 만들어 쓸 수 없음.
예를 들어, vulkan api 를 gobject 를 사용하여 api 를 만들었다고 치자. 그러면 vulkan 이 광범위하게 사용될 수 없음. gtk im, qt im (입력 api)가 이런 문제점이 있다고 생각함. gtk im 이나 qt im 이 하나로 통합되려면 gobject 를 사용하지 말고, qt 를 사용하지 말고 im api 를 만들어야 gtk, qt 등의 여러 환경에서 사용할 수 있다고 생각함. XIM 이 과거부터 현재까지 광범위하게 사용되는데, XIM 은 명세와 구현이 분리되어 있어서 gtk/qt im api 를 사용하기 곤란한 자바,X11 환경에서는 XIM 을 사용하고 있음. 그 이유가 gtk/qt 에 대한 라이브로러 종속 문제와 라이선스 문제라고 생각함.
라이브러리가 제공하는 자료구조를 썼다고 해서 동적 링킹이 아니라고 하는 건 들어본 적이 없음. glib 쓰면 glib에 종속되는 거야 당연한 거고 결국 런타임으로 glib을 쓰는 게 싫다는 거잖음.
내가 잘 아는 건 아니라도 상식적으로 생각해 봤을 때 라이브러리가 제공하는 타입을 썼다고 해서 동적 링킹이 아니면 LGPL이 왜 있겠음? 그냥 GPL 쓰지 않을까.
기존에 작성해둔 코드에서 glib를 제거하여 posix c 만 사용하여 안드로이드에서도 그대로 돌리기 위함입니다. ui 가 플러그인(모듈)로 완전히 분리되어 있어서 안드로이드용 ui 플러그인(모듈)만 추가하면 안드로이드에서도 돌아간다는 것이 제 판단입니다.
LGPL 동적 링킹이 문제가 없다고 생각하는 사람들 많은데, LGPL 함수를 이용하여 코드를 작성했다고 치자. 그거랑 똑같은 소스코드가 기존 GPL 소프트웨어에서 발견됨. 그러나 저자는 GPL 소프트웨어를 베낀게 않고 스스로 작성했는데, GPL 쪽에서 문제 삼으면 진짜로 문제가 됨. 라이선스 받아서 사용하는 라이브러리(GPL, LGPL)를 사용할 때,
라이선스 이슈는 시한폭탄 같은 거임. 그래서 LGPL, GPL 라이브러리를 사용해서 뭘 만들었다면 오픈소스로 배포해야 시한폭탄이 터지지 않음. 외부 라이브러리 안 쓰고 완전 독점 소프트웨어 상태일 때, 퍼블릭 도메인화가 가능.
그래서 라이선스만 다르고 똑같은 기능을 하는 동일한 이름의 소프트웨어가 여러개 존재함. make, pkg-config, libc. GNU 쪽에서는 동일한 기능을 하는 걸 맨땅에서 만들어서 (L)GPL로 발표하고, BSD쪽에서는 GNU와 똑같은 기능을 하는걸 맨땅에서 만들어서 BSD로 발표함. 이 뻘짓을 괜히하는게 아님.
MS도 마찬가지고.
그냥 그렇게 하셈 그럼. 대신 다른 사람한테 그게 사실인 것처럼 말하지는 말고.
사실이 아닌게 아니라 이론과 현실은 다르고 현실에서 실제 발생하는 문제임. 저자권, 라이선스 문제는 5년후, 10년 후에도 터질 수 있음. 궁금하면 오라클과 자바 api 저작권 소송이 어떻게 되었는지 함 보시라구
gettext 가 왜 c 표준이 되지 않았는지 함 알아보고. 내가 없는 얘기를 지어내는게 아니라 현실에서 실제로 발생하는 문제임. 동적 링킹 했으니까 아무 문제없다는 식은 이건 정말 잘못 생각하는 거임. 왜 명세/구현을 분리시키는지 libc 가 왜 여러개 존재하는지 그 이유를 생각해 보시라구.
내가 볼 땐, 님은 너무 리눅스/GNU 관점에서 생각하는거 같은데 현실은 다름. 저작권이 없는게 퍼블릭도메인인데, 그래서 저작권/라이선스 고지를 할 수 없음. 거기에 LGPL 동적 링킹하면 라이선스 고지를 해야하는데... 그러면 퍼블릭도메인이 안 되는거잖아. 대체 뭐가 사실이 아니라는거지?
이거 하나만 기억하셈. 어떤 라이브러리 api 를 사용해서 만들었고 동적 링킹하고 있는데, 그 라이브러리에 법적 문제(특허,지적재산권), 라이선스 이슈 있으면 어쩔거임? 동적 링킹이니 아무 문제 없음??? 이론과 현실은 다르다는거 명심하셈
진짜 답답해서 무시하고 싶은데 혹시 니중에 보는 사람 있을까 봐 씀. 저거 개소리니까 무시하셈.