gpl

reyus5의 이미지


자바 개발자입니다.

자바로 개발하다보면 오픈소스를 참 많이 사용하게 되는데, 대부분이 gpl license를 가지고 있습니다.
gnu.org, license파트를 읽어보면 해당 라이센스의 소스를 사용하게되면 개발한 소스또한 오픈하게 되어있던데요.

그렇게 되면 소프트웨어 패키지를 개발해도 소스를 오픈해야하기 때문에 판매를 할 수 없을텐데요.

이 부분에 대한 명쾌한 해답을 얻을 수 있을까요??

희진군의 이미지

판매라는 개념보다는...

서비스를 제공한다는 개념으로 많이 가는거 같던데요...

얼핏 여기글중에서 본듯한...

정확한 답변은 다른분들께 패스.. ㅎ

keedi의 이미지

판매를 못하는 것은 아니지요.
소스를 오픈해야 하니 배포물의 2차 배포를 막을 수 없다는 것이 문제겠지만요.

결국 윗분 말씀처럼 서비스를 제공하거나...
아예 밑바닥부터 라이브러리를 자체적으로 다시 만드는 방법이 있겠지요.

삽질이라고도 할 수 있지만... GPL은 GPL로 보답하는 것이 GPL만의 룰이니까요.
이것이 싫다면 쓰지 않는 방법을 고려해야겠죠.

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

권순선의 이미지

라이브러리의 경우 대부분 lgpl로 되어 있을텐데요... 사용하시려고 하는 해당 gpl 모듈이 어떤 것인지를 알려 주시면 좋겠습니다. 왜냐면 gpl 코드라고 해서 무조건 사용하였을 경우 전체 코드를 오픈해야 하는 것은 아니거든요.

체스맨의 이미지

권순선님께서 말씀하신 다음 부분

"gpl 코드라고 해서 무조건 사용하였을 경우 전체 코드를 오픈해야 하는 것은 아니거든요."

에 대해서 좀 더 알고싶습니다. 제가 이제까지 알고있던 내용과 다른 것 같아서요... 구체적으로 어떤 GPL 코드인 경우 위와 같은 상황이 적용되는지요?

그리고, ethereal 코드를 이용하는 회사를 본 적이 있습니다. 해당 라이브러리도 이런 상황에 해당하는지요?

http://www.ethereal.com/

Orion Project : http://orionids.org

권순선의 이미지

gpl 코드를 어떻게 사용하느냐에 따라서 다릅니다. gpl에서 소스코드 공개의 의무는 기본적으로 그 결과물이 원 gpl 코드의 파생물(derivative work)로 정의될 때 발생하며 소프트웨어를 개발하는 방법에 따라서 그 결과물이 gpl 코드의 파생물이 되는 형태로 개발할 수도 있고 그렇지 않은 경우도 있습니다.

파생물의 정의는 'work based on that program'이라고 이야기할 수 있습니다. 즉 원래의 gpl 코드를 수정하거나 코드 일부를 복사하여 만든 결과물은 원래의 gpl 코드의 파생물입니다.

그러나 위와 같은 경우는 소스코드를 공개하되 gpl 코드의 파생물이 제공하는 서비스만을 사용하도록 해서 공개하고 싶지 않은 소프트웨어를 완전히 분리한다면 분리된 소프트웨어는 파생물이 아니므로 소스코드 공개 등의 의무가 발생하지 않습니다.

fsf의 gpl faq에서는 모듈을 예로 설명하고 있는데, 만약 모듈이 원 프로그램과 완전히 분리된 채로 동작할 수 있다면 원 프로그램이 gpl이라 할지라도 모듈은 gpl이 아닐 수도 있다고 설명되어 있습니다. 해당 모듈이 원 프로그램의 파생물이 아니라고 이야기하는 것이지요. 이렇듯 파생물의 정의를 어떻게 define하느냐가 소스코드 공개의 핵심 관건인데, fsf의 입장은 gpl faq에 나와 있으므로 확인해 보시면 되고, gpl 코드라고 해도 저작권자가 fsf가 아닌 경우에는 gpl faq에 나온 정의가 그대로 적용받지는 않습니다.

체스맨의 이미지

예... 그 부분은 알고 있습니다. 어떤 라이브러리를 사용하려는지 물으셔서, GPL 인 경우도 라이브러리 종류에 따라 예외가 있는지 의문을 가졌습니다.

그리고 지금 말씀해주신 부분은, 알고는 있었지만 참 애매한 부분이었는데요... 사실상 플러그인화해서 가능하다면 대부분의 GPL 라이브러리는 LGPL 처럼 사용할 수 있을 것 같습니다. 예를 들어 이더리얼이 GPL 인데, 그걸 이용하는 측에서는 필요한 인터페이스 함수만 정의하고 그냥 가져다 쓴 뒤, 인터페이스 함수를 구현한 소스만 공개하면 GPL 의무는 다한 것처럼 되는 셈이어서요.

그러니까, FAQ 다음 부분인 것 같은데요...

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

이더리얼 같은 프로그램은 현실적으로 대안이 없는 상태이지만, 기술적으로 저 at arms length 정도는 떨어뜨려 놓을 수 있을거라 보거든요. 그렇다면 라이브러리인 경우, GPL 이냐 LGPL 이냐가 무의미해지는 것 같다는 생각이 들더군요.

Orion Project : http://orionids.org

klyx의 이미지

GPL라이브러리를 어플리케이션에 포함하는게 아니라, 플러그인같이 어플리케이션이 GPL로된 부분에 의존성 없이 독립적으로 작동하게 되어있으면 어플리케이션은 GPL이 아니어도 되는 걸로 알고 있습니다.