안녕하세요,

mere aggregation 에 관하여 전염성과 공개여부에 관하여 여쭙고 싶습니다.

하나의 임베디드 시스템에 C언어로 진행된

A(GPLv2), ubus(LGPLv2), C(Proprietary)

세가지 프로젝트가 있으며, 이들은 하나의 바이너리로 결합되며, 다이나믹 링크로 링킹됩니다.

그리고 여기서, A와 C는 LGPLv2 라이선스로 이루어진 ubus를 통해 소통을 진행하며, 소통을 위해, A와 C는 당연히 ubus 라이브러리를 포함하고 있습니다.

현재 A project는 GPLv2 Open Source 이며, 이미 저희 프로젝트에 맞게 수정을 거쳤고, C project는 본래 저희의 closed source 입니다.

https://www.oss.kr/oss_guide/show/04e46b00-d904-45b7-846f-45bd30c4cbbb

에 의하면, 통신으로서 이루어진 결합은 공개 사항에 해당되지 않는다고 나와있는데요.

여기서 질문은:

1. B와 C는 A GPLv2 라이선스에 감염되는가?

2. 공개 범위는 A에 국한되나? 아니면 B, C도 전부다 공개 해야하는가?

3. mere aggregation에 관하여 판례가 있는가?

4. 이들이 derivate work 라고 판단하는 방식은 데이터의 복잡성과(데이터 복잡도의 판단기준이 무엇인가), 시스템이 사용하는 메모리 주소에서의 차별 여부인가?

5. restfulAPI, RPC, IPC 에따라 판단 방식이 다른가?

입니다..

많은 질문으로 불편을 드려 죄송합니다.

만약 이 문제들에 대한 답별은 받을 수 있다면 매우 감사 할 것 같습니다.

감사합니다!

------ 댓글 -------

License 관리자

안녕하세요,

오픈소스SW 라이선스 관리자입니다.

문의주신 내용 답변 드립니다.

(B를 ubus로 보고 답변드리겠습니다. 그리고 모든 문의주신 내용이 )

1) B와 C는 A와 다이나믹 링킹 형태이므로 GPL-2.0 라이선스에 전염된다고 볼 수 있습니다.

2) B, C 전부 다 공개 대상입니다.

3) mere aggregation은 단순히 한 저장매체 혹은 기기에 2개의 소프트웨어가 저장되어 있고 서로 동작에 영향을 주지 않는 개별 저작물이라고 볼 수 있습니다.

정확히 어떤 내용의 판례를 말씀하시는지 확인 부탁드립니다.

4) derivate work는 해당 오픈소스SW의 소스코드를 변경, 삭제 등 수정하는 행위로 인한 결과물 뿐만 아니라 다른 코드와의 결합의 결과물로 볼 수 있습니다.

5) restfulAPI, RPC는 GPL-2.0 전염이 안될 수 있다고 볼 수 있으나, IPC는 전염이 된다고 볼 수 있습니다.

감사합니다.

※ 법적 분쟁 발생시 본 답변은 법률적 해석이나 논리로 활용될 수 없습니다.

------ 댓글 -------

정말 감사드립니다!

질문에 문제점을 발견하여 다시 질문을 드리겠습니다.

A: GPLv2 daemon 이자 library

ubus: LGPLv2 daemon 이자 library

C: proprietary library

1) A와 C는 각자 ubus를 사용하기 위해, ubus를 링킹 합니다만, A와 C는 직접적으로 링킹 하지 않고,  ubus를 통해 소통하려고 합니다, 이 경우에도 A는 B를 감염시켜 C에게도 전염이 될수있나요? A와 C를 ubus 사용구조로 개작하여 소통 하려는것인데, 이때 ubus(RPC)가 A에게 전염되어,  C까지 이어져, B와 C 모두 공개를 해야하는지 알고 싶습니다.

2) A를 개작하여 ubus를 사용하게 만들면, ubus도 GPL이 되는가 궁금합니다.

A를 개작을 하였지만, A가 ubus를 사용하는 입장이고, ubus는 LGPL인데 말입니다.

3)  만약, ubus를 통하지 않고, C를 사용하여 A를 개작한다면(A가 C를 include 하는 형식), C도 공개해야하나요?

저희가 A를 개작을 했지만, A가 C를 사용 하는 상황인데, C까지 공개가 필요한지 궁금합니다.

3번에서의 판례를 여쭈어 본것은 아래가 궁금해서 여쭈어 본것입니다:

RPC/IPC/Restful/file system 등, 직접적인 링킹이 아니라, 중간의 매개체로 소통이 가능하게 개작한 GPL과 개작한 non-GPL(proprietary) 소스가 서로 소통할때, 전염을 판단하는 기준이 궁금합니다.

소통하는 데이터가 긴밀할 경우, 전염으로 판단한다는 문장이 gnu mere aggregation FAQ에 존재하는데,  개작한 오픈소스에는 해당이 안되는건지, 그렇지 않고 해당이 된다면, 긴밀의 정도가 어느정도인지, 이 정도를 판단하는 척도가 궁금해서 그렇습니다.

이전 5번의 답변에서

"restful API, RPC는 전염이 안될 수 있다고 볼 수 있으나, IPC는 전염이 된다고 볼 수 있습니다."

라고 말씀을 주셨는데, 왜 그런지 이유를 알 수 있을까요?

감사합니다.

------ 댓글 -------

License 관리자

안녕하세요,

오픈소스SW 라이선스 관리자입니다.

문의주신 내용 답변드립니다.

1) A와 C가 파이프(Pipe), 소켓(Socket), 명령행 인자(Command-line Argument)로 통신하거나, 플러그인을 실행하기 위해 Fork나 Exec를 사용하는 경우에만 전염되지 않습니다.

A의 GPL 라이선스가 라이브러리로 사용된다고 하더라도 전체 프로그램에 GPL이 전염된다고 볼 수 있습니다.

2) ubus가 GPL이 되는 것은 아니지만 A로 인해 ubus도 GPL 라이선스를 준수하여야 합니다.

3) 1번 답변에서와 같은 내용이 아니라면 C까지 공개가 필요합니다.

이에 대한 판례는 아니지만 말씀하신 것처럼 GPL 라이선스를 만든 Free Software Foundation의 FAQ 내용에서 확인할 수 있습니다.

소통하는 데이터의 긴밀한 경우의 정도는 법원에서 판단합니다. 아직 그에 대한 판례는 확인하지 못하였습니다.

restful API와 RPC는 각 통신 방법으로 데이터만을 주고 받는 형태로 볼 수 있지만, IPC는 메모리를 공유할 수도 있기 때문입니다.

감사합니다.

※ 법적 분쟁 발생시 본 답변은 법률적 해석이나 논리로 활용될 수 없습니다.