linux kernel, ath5k 드라이버와 GPL/BSD

cjh의 이미지

OpenBSD에 있던 Reyk Floeter의 atheos WLAN 드라이버를 linux kernel에 포팅하면서 포팅한 사람
(Jiri Slaby)이 BSD라이센스를 삭제하고 GPL로 교체하는 일이 있었습니다.

http://lkml.org/lkml/2007/8/28/157
http://undeadly.org/cgi?action=article&sid=20070829001634

이에 OpenBSD의 Theo de Raadt가 한마디 남겼군요.

http://undeadly.org/cgi?action=article&sid=20070901041657

요점은 해당 드라이버가 듀얼 라이센스 (BSD & GPLv2)였다는 것이고, import시킨 과정에서
BSD라이센스를 지우고 GPLv2로만 바꾸었다는 것입니다. 하지만 라이센스를 바꿀 수 있는 것은
"저자" 뿐이고, 해당 저자의 동의 없이 패치 (BSD드라이버를 linux용으로 바꾸었으니
패치겠지요)된 소스코드를 import시키면서 라이센스를 변경할 수는 없다는 것입니다.

법적인 문제도 있을 수 있겠지만 더 안좋은 점은 리눅스쪽에서의 개선사항이 GPLv2가
되므로 BSD쪽으로 되돌아올 수 없다는 것 (BSD 커널 소스코드에는 GPL을 넣을 수 없습니다)
인데... Theo는 이렇게 말하고 있습니다.

GPL fans said the great problem we would face is that companies would take our BSD code, modify it, and not give back. Nope -- the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time. But once the code is GPL'd, we cannot get it back.

Ironic.

익명 사용자의 이미지

음...ㅎㅎㅎ
BSD라이센스는 혈액형으로 따지면 O형과 같아서 듀얼라이센스가 의미가 있을까요?
즉, 상용라이센스와 듀얼로 해도 같은 결과가 되질 않는가요?
유연하게 할려면 LGPL과 짝을 지었으면 좀 좋았을텐데...ㅎㅎㅎ

그나저나 내 마음을 훔친여자를 절도죄로 감방에 가둘 수는 있는가요?
에휴... 한번이라도 가두어봤으면 좋으련만.
농담입니다. (박수는 치지말고) 그냥 웃으세요.

jg의 이미지

씁슬하네요. 잘못은 빨리 인정하고 빠른 시일내로 원 라이센스로 복구되길 (빕니다?)바랍니다.
BSD 라이센스가 대단한 걸 바라는 것도 아닌데... 좀 황당하군요..
더구나 패치 수준의 코드였다면 두 말할 나위 없구요.

--
perl -e's@@JEON Myoung-jin@;sub man{s| _|her e|}
sub see{s;^;Just;;u;s;e ;Perl ;;to;print$_,$/}$uperMan=M;
s=^....=U are not=;s~$uperMan~~;&admitIt;s=U are = A=;s|young|_|;&man;
sub admitIt{say;ye;s!-\w+! Hacker!};see U'

$Myoungjin_JEON=@@=qw^rekcaH lreP rehtonA tsuJ^;$|++;{$i=$like=pop@@;unshift@@,$i;$~=18-length$i;print"\r[","~"x abs,(scalar reverse$i),"~"x($~-abs),"]"and select$good,$day,$mate,1/$~for 0..$~,-$~+1..-1;redo}

익명 사용자의 이미지

개선작업을 한 저작자에게 BSD 코드로서 듀얼 라이센스를 제공해 줄 것을 요청하는 것이 가장 적절할 것 같군요.
이에 대한 홍보도 적극적으로 하고...

같은 오픈소스 커뮤니티로서 BSD와의 공생의 길을 '윤리적인 측면'에서 모색해 줄 것을 GPL진영에 요청하는 수 밖에는 없겠네요.

jg의 이미지

BSD 소스가 GPL 소스가 되었더라도 소스코드를 공개하는 이상 기존 라이센스를 지울 수는 없는 것으로 알고 있는데 아닌가요?
저작자의 라이센스를 무시하려면 애초에 그 코드를 사용하지도 보지도 말아야 한다고 생각합니다.
그리고 보니 저도 라이센스 표기를 누락한 게 생각나서 틈틈이 고쳐야 하겠습니다;;

--
perl -e's@@JEON Myoung-jin@;sub man{s| _|her e|}
sub see{s;^;Just;;u;s;e ;Perl ;;to;print$_,$/}$uperMan=M;
s=^....=U are not=;s~$uperMan~~;&admitIt;s=U are = A=;s|young|_|;&man;
sub admitIt{say;ye;s!-\w+! Hacker!};see U'

$Myoungjin_JEON=@@=qw^rekcaH lreP rehtonA tsuJ^;$|++;{$i=$like=pop@@;unshift@@,$i;$~=18-length$i;print"\r[","~"x abs,(scalar reverse$i),"~"x($~-abs),"]"and select$good,$day,$mate,1/$~for 0..$~,-$~+1..-1;redo}

keedi의 이미지

흠~ 제가보기엔 패치 저작자는 패치 코드에 대한 라이센스를 GPL로 하는 것은 사실 문제 자체는 없다고 생각합니다. 패치된 코드가 아니라 패치 그 자체 말이죠.

패치 이후의 파급효과가 지금은 문제가 되고 있는데...

제가 생각하기에 해결 방법은 있다고 생각합니다.
원래의 BSD 코드를 이용해서 해당 패치를 보지 않고
리눅스용으로 포팅해서 듀얼 라이센스를 적용하는 방법도 있겠지요.

보지않고 작성해도 코어 부분이 아니라 커널과의 인터페이스와
상관한 부분이므로 새롭게 보지 않고 작성한다고 해도 어느정도는
비슷해질 수 밖에 없지 않나 라고 생각하는데,
이 부분은 뭐 이쪽이나 저쪽이나 양심적인 문제니,, :-)

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

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

keedi의 이미지

그런데 또 생각해보니...
리눅스 커널 모듈의 특성상 GPL2와 BSD 라이센스를 동시 적용하는게 가능할까요?
한동안 리눅스 커널 모듈의 GPL2의 라이센스를 가지지 않는 경우에 대한
이야기가 생각나서요...

또 그러고보니까 그렇다면,
하드웨어의 커널 모듈을 GPL3으로 만든다면,
리눅스 진영쪽에서는 또 GPL3을 그리 반가워하지 않으므로
또 문제가 될 수 있겠다는 생각도 드는군요...

휴... 복잡하네요.

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

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

지리즈의 이미지

리누스 토발즈를 포함한 일부(사실은 리누스만?)가 반대할 뿐입니다. 리눅스 코어 개발자 중에서도 GPLv3를 지지하는 사람들도 많습니다.

커널을 GPLv3로 변환하지 못하는 것은 사실상 방대한 코드에 대해서 모든 작성자의 동의를 얻어내기가 어렵다는 기술적인 문제가 표면상의 가장 큰 이유입니다. 자신이 제공하는 소스 자체에 대한 라이센싱을 GPLv2로만 하던 듀얼로 하던 트리플로 하던 말그대로 원작자의 마음대로 입니다. 다만, 커널에 결합될 때 GPLv2 라이센스만을 이용할 뿐이죠.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

권순선의 이미지

gpl 진영(?)과 bsd 진영(?)이 결국 추구하는 것은 거의 같은 방향인데 참으로 안타까운 일이 또 생겼네요. 양쪽이 모두 공존할 수 있는 방향은 없을까요? gpl의 특성상 현실적으로는 불가능할 텐데 참 안타깝다는 말밖에는... 어쨌든 *bsd들도 계속 잘 개발/개선되기를 바랍니다...

keedi의 이미지

아이러니한 상황이군요.

패치 저자가 이런 상황까지 고려를 미처 못했던게 아닐까 하는 생각이네요.
(설마, 너 엿먹어봐... 라는 의도였다기 보다는 실수가 아니었을까 하는데...흠)
BSD 개발자들의 개발 욕구를 떨어뜨리지 않게 잘 해결되었으면 하네요.

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

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

ganadist의 이미지

lkml에서는 http://lkml.org/lkml/2007/9/1/102 에서 불타오르고 있네요.

----
Do not feed troll!

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

eungkyu의 이미지

그런데 전 솔찍히 왜 문제가 되는지 잘 모르겠습니다.

Dual licensing이라는 것은 코드 사용자가 두 라이센스중 하나를 선택할 수 있다는 것 아닌가요? 그 중에서 GPLv2를 선택했을 뿐인데... 당연히 그런 케이스를 예측했으니 dual licensing을 해서 내놨을거 같은데요.

feanor의 이미지

맞습니다. 제가 알기로도 BSD/GPL로 라이센스된 코드에서 BSD를 떼어내고 GPL로만 라이센스하는 것은 아무런 (법적) 문제가 없습니다. (윤리적으로 어떤지는 논외)

링크를 읽은 뒤 제가 내린 결론은, OpenBSD의 ath 드라이버는 두 부분이 있는데, Sam Leffler가 작성한 부분은 BSD/GPL이지만 Reyk Floeter가 작성한 부분은 BSD only이기 때문에 BSD 라이센스를 삭제해서는 안 된다는 것입니다.

cjh의 이미지

> 맞습니다. 제가 알기로도 BSD/GPL로 라이센스된 코드에서 BSD를 떼어내고 GPL로만 라이센스하는 것은 아무런 (법적) 문제가 없습니다. (윤리적으로 어떤지는 논외)

이번의 문제의 근원이 그겁니다. 법적 문제가 "있다"는 것이지요 -_-
(저도 애매하긴 했지만 이번에 확실히 해 두게 되었습니다)

원 저자의 동의 없이 라이센스를 수정하는것은 안됩니다. dual licensed 에서 하나만 "지우는" 것도 수정과 마찬가지라는 것이지요. 그냥 dual license로 그대로 두었으면 되는걸 import하는 사람이 굳이 지워버린게 문제라는 겁니다.

http://lkml.org/lkml/2007/9/1/102

- If you receive dual licensed code, you may not delete the license you don't like and then distribute it. It has to stay, because you may not edit someone's else's license -- which is a three-part legal document (For instance: Copyright notice, BSD, followed by GPL).

--
익스펙토 페트로눔

--
익스펙토 페트로눔

keedi의 이미지

듀얼 라이센스라 또 궁금해지는 것이 있습니다.

Perl의 경우 아티스틱 라이센스와 GPL이 듀얼일텐데...
대부분 Perl 모듈들이 Perl의 라이센스를 따라가는데
해당 듀얼 라이센스 모듈을 수정해서 새로운(?) 것을 만들때
아티스틱 또는 GPL 하나만 적용하거나, 또 다른 라이센스를
적용하는 것도 문제가 있는것인가요?

뭐가 뭔지 잘 모르겠네요. 0_0;;

예를 들면 코드 뿐만이 아니라 문서 같은 경우에 원래 도큐먼트가 Perl의 라이센스를 따라가는데
그 문서를 번역하면서 Perl의 라이센스를 그대로 따라가지 않고
아티스틱으로만 한다거나, GPL로만 한다거나, 또는 자기만의 라이센스를 가지고 간다면,
문제가 되는것인가요?

궁금하네요. :-)

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

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

jg의 이미지

최근에 본 모듈 중에 아티스틱하고 GPL로 듀얼 라이센스가 된 경우가 있었는데
그 경우에는 아티스틱 "또는" GPL 로 배포할 수 있다라고 명시가 되어 있더군요.
그런 경우에는 GPL로만 표기할 수도 있는 것 같습니다.

그러나 이번 사례에서 간단하게 짚고 넘어갈 것은
원저작자에게 문의를 하는게 가장 확실하다는 것 같습니다.

원저작자의 동의를 얻을 수 있는 법적인 문제에도 맞는 것일테고..
원 저작자는 누가 내 소스를 이용했는가에 대해서 뿌듯할 수 있고,
참고한 이는 감사의 표시를 할 수 있는 등 도덕적으로도 보기 좋은 형태이니까요.

--
perl -e's@@JEON Myoung-jin@;sub man{s| _|her e|}
sub see{s;^;Just;;u;s;e ;Perl ;;to;print$_,$/}$uperMan=M;
s=^....=U are not=;s~$uperMan~~;&admitIt;s=U are = A=;s|young|_|;&man;
sub admitIt{say;ye;s!-\w+! Hacker!};see U'

$Myoungjin_JEON=@@=qw^rekcaH lreP rehtonA tsuJ^;$|++;{$i=$like=pop@@;unshift@@,$i;$~=18-length$i;print"\r[","~"x abs,(scalar reverse$i),"~"x($~-abs),"]"and select$good,$day,$mate,1/$~for 0..$~,-$~+1..-1;redo}

eungkyu의 이미지

머리속이 혼란스러워지네요.

그럼 BSD/GPL 코드를 수정하여 나온 파생물은 BSD를 따라야 하나요? 아니면 GPL을 따라야 하나요?

지리즈의 이미지

원래 부분은 BSD/GPL로 남겠죠.

구태연하게 설명드리면,
1000줄짜리 BSD/GPL 소스를 수정해서 그중 100줄은 삭제하고, 200줄을 첨가해 놓았다면,
원 900줄은 BSD/GPL의 적용을 받고, 첨가한 200줄은 작성자의 마음대로 GPL, BSD 아니면 GPL/BSD 셋중에 하나를 택하면 됩니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

eungkyu의 이미지

어떤 과정에 의해서 애매한 것이 확실하게 되었는지 가르쳐주실 수 있나요?
저는 아직도 법적 문제가 없다는 확신이 들어서요.

가르침 부탁드립니다.

jg의 이미지

<span>제가 이해한 바로는</span>
이 문제는 GPL로만 표기할 수 없는 이유가 두 가지입니다.
하나는 원저작자의 본래 라이센스를 수정할 수 없다는 것이고
또 하나는 소스 자체가 BSD only 와 Dual(BSD,GPL) 이 섞여 있기 때문입니다.
 
위와 같이 원래 라이센스를 지워버리고 원저자 이름의 저작권 표기만 남겨버리면
제 삼자의 입장에서 최종 패치된 코드만 보면
마치 원저작자가 아예 처음부터 GPL로 배포한 것처럼 보이게 됩니다.
 
어차피 이 메일링 리스트가 있으니 괜찮지 않냐? 고 할 수 있을지도 모르겠지만
헷갈리지 않게 처음부터 하지 않는게 낫다고 보는게 맞는 것 같습니다.
 
아무리 GPL 만으로 재배포한다고 하더라도 라이센스의 경유를 알릴 필요가 있습니다.
즉, 원래의 라이센스를 남겨두고 자신의 라이센스를 추가해야 맞는 것 같습니다.
더 명확히 하려면 정확히 소스 중간중간에 자신이 라이센스를 달리하는 부분에
주석을 달아야하구요.
 
따라서 듀얼 라이센스를 GPL로 바꿀 수 있느냐의 문제가 아니라
본래의 라이센스 표기를 수정(삭제)할 수 있느냐 없느냐의 문제 인 것 같습니다.

여기까지인데 쓰고 보니 제가 keedi*님 글에 댄 댓글도 잘못된 것 같군요.
이 논리라면 본래의 라이센스를 남겨야 하겠군요.

--
perl -e's@@JEON Myoung-jin@;sub man{s| _|her e|}
sub see{s;^;Just;;u;s;e ;Perl ;;to;print$_,$/}$uperMan=M;
s=^....=U are not=;s~$uperMan~~;&admitIt;s=U are = A=;s|young|_|;&man;
sub admitIt{say;ye;s!-\w+! Hacker!};see U'

$Myoungjin_JEON=@@=qw^rekcaH lreP rehtonA tsuJ^;$|++;{$i=$like=pop@@;unshift@@,$i;$~=18-length$i;print"\r[","~"x abs,(scalar reverse$i),"~"x($~-abs),"]"and select$good,$day,$mate,1/$~for 0..$~,-$~+1..-1;redo}

keedi의 이미지

간단하게 말하면 원래 소스는 author가 정한 라이센스
고친 부분은(어떻게 보면 패치죠) patcher(?) 정한 라이센스

만약 둘이 합치면??

원래 코드 부분은 author의 라이센스
중간중간 패치되는 부분은 patcher의 라이센스
소스코드에는 author의 라이센스를 그대로 남겨두면서
패치 적용 부분에 patcher의 라이센스를 명시한다...

그런것 아닐까 라고 생각하고 있습니다. :-)

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

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

cjh의 이미지

추가 논의사항에 대해서는

http://kerneltrap.org/OpenBSD/Stealing_Versus_Sharing_Code

를 참고하십시오.

여기서 제가 얻은 내용이라고 한다면 (한국 법에는 어떻게 되어 있는지 모르지만)

- 저작권은 "기본적으로 부여되는 것"
-> 저작권 표기를 안해도 자동적으로 부여된다는 것입니다.
-> 그래서 명백한 저작권 표기가 없어도 주장이 가능함.
-> 따라서 저작권이 없는 소스는 안쓰는게 현명함.

- 저작권 포기는 "부여된 후 자발적으로 하는 것"
-> GPL이든 BSD이든 "자동적으로 부여된 저작권을 포기하는 선언"이라는 것이지요.
-> 하지만 두 라이센스 모두 "사용자가 저작권 문구를 삭제할 권리"가 없습니다.

- 원 저작권자가 아니면 저작권을 "변경"할 권리가 없다.
-> 반대로 말하자면 원 저작권자는 변경할 수 있다.
(이런 방법으로 GPL 소스를 closed로 바꿀 수 있습니다)
-> 물론 다른 공헌자들의 동의를 얻어야 겠지요.

따라서, 듀얼 라이센스된 파일의 경우

- 어떤 라이센스로 배포할지는 각자가 선택할 수 있으나, 저작권 문구는 그대로 유지한다.
- 패치의 경우 패치의 저자가 둘 중 하나를 선택할 수 있다.
(또는 호환되는 라이센스를 선택 가능)

이렇게 해석이 가능하겠네요. 어떠한 경우도 "원저작권자의 허락이 없는
라이센스 문구의 삭제"는 불가능하다고 보시면 될 것 같습니다.

결국 위 문제는 아래와 같이 수정된 패치를 넣는 것으로 해결된 듯 합니다.
법적 문제가 없다면 이런 수고를 덜 필요도 없었겠지요.
(사실 최초 import에는 듀얼도 아닌 BSD라이센스를 GPL로 바꾸는 등의 문제점도 있었습니다)

아래 보시면 모듈 라이센스가 GPL이 되고 있는데 (사실 최초 import한 사람의 목적은
이게 하고 싶은 것이었겠지요), 이 과정은

- 원본 소스는 BSD/GPL 듀얼
- linux용 패치는 GPL
- 따라서 이 소스는 GPL로 배포 가능 (둘 중 하나를 선택하면 되므로)

이렇게 해석이 가능합니다.

http://marc.info/?l=linux-wireless&m=118857712529898&w=2

--
익스펙토 페트로눔

--
익스펙토 페트로눔

eungkyu의 이미지

이 글과 소스를 보니 이해가 가는군요.

결국 파생물의 라이센스가 GPL이냐, BSD/GPL이냐의 문제라기보다는,
파생물이 GPL이더라도 원 소스의 라이센스 문구를 마음대로 지워서는 안되다.

는 결론 맞죠?

전 원 저자가 BSD 버전의 GPL을 요구하는 줄 알았습니다.

설명 감사합니다.

그런데 OpenBSD측에서 stealing code 이슈는 해결되지 않은건가요?
결국 파생물이 GPL이라면 그 수정 사항을 다시 BSD에 적용하기가 어려울 것 같은데요.

cjh의 이미지

> 그런데 OpenBSD측에서 stealing code 이슈는 해결되지 않은건가요?
> 결국 파생물이 GPL이라면 그 수정 사항을 다시 BSD에 적용하기가 어려울 것 같은데요.

그건 현재 라이센스로는 어쩔 수 없지요. BSD소스들은 GPL 전염에 상당히 신경을 쓰니까 리눅스 소스라면 참조는 할까 그냥 들여오지는 못합니다. (라이센스 나누어 별도로 관리하지 않는 한) 리눅스가 비교적 H/W 지원이 좋은데 각종 디바이스 드라이버를 BSD에서 가져다 쓸 수 없는 이유가 그래서입니다.

--
익스펙토 페트로눔

--
익스펙토 페트로눔

modestcode의 이미지

원저자가 의도는 분명하군요.
http://uwsg.indiana.edu/hypermail/linux/kernel/0709.0/0159.html

"그렇게 하라고 dual license 한 것이다."라고 요약할 수 있습니다.

이미 kerneltrap 의견에서도 나왔지만, dual license에서 하나를 제거하지 못한다면 dual license의 의미가 없는 것입니다.
왜냐면 같은 dual license를 사용하지 않는 프라젝트에서 하나를 선택할 수 없다면 정책상 배포할 수가 없게 됩니다.

BSD license 정의에 의해 기업에서 돌려 받지 못하는 코드가 더 많을 텐데 GPL인 리눅스 커널에 유난히 민감한 것이 아닌가 합니다. 예전에 GPL 드라이버 문제로 화난 BSD진영에서 한 목소리 내는 정도로밖에 이해 안됩니다. 결국 가져가는 것이 문제가 아닌데 개선된 패치를 공유하지 못하는 것이 핵심이라고 보면, dual license인 것을 merge 했다면 patch도 dual license로 제공하는 것이 도덕적인 해결책일 것같습니다. 그러나 객관적으로 BSD 라이센스의 정의에 의해 그것을 예상하고 한 것인데 왜 내가 만든 코드에서 파생된 것이 반드시 다 내 한테 돌아와야 한다고 생각하는 지는 의문입니다.

cjh의 이미지

> 왜냐면 같은 dual license를 사용하지 않는 프라젝트에서 하나를 선택할 수 없다면 정책상 배포할 수가 없게 됩니다.

라이센스 중 하나를 선택할 권리는 있지만 라이센스를 변경할 권리는 없다는 것이 핵심입니다.
이번 결과를 보시면, 원본 소스의 copyright는 그대로 놔둔 채 "파생 소스"를 어떻게 배포할 지를 결정한 것이지요.
(이 경우 GPL로 배포) 해당 프로젝트의 정책과는 관련이 없습니다.

> BSD license 정의에 의해 기업에서 돌려 받지 못하는 코드가 더 많을 텐데 GPL인 리눅스 커널에 유난히 민감한 것이 아닌가 합니다.

BSD -> GPL로 되어 버리면 BSD쪽에서는 다시 가져갈 수 없고 그냥 바라만 보게 됩니다.
물론 원래 그런게 BSD라이센스이니 윤리적 이외의 이의 제기는 못하지만, 오픈소스의 정신이
소스의 공유에 있으므로 "가능하다면" 피드백을 받기를 원하는 것이지요.

그리고 의외로 BSD라이센스로 돌려받는 코드들 꽤 있습니다. :) BSD소스에는 기업에서 기증한
코드들이 많이 들어 있습니다. 다만 Theo가 말했듯이 "기업에서 가져가 closed source로 하나
GPL로 만들어 버리나 BSD쪽으로 피드백 받을 수 없는(맘대로 못 가져다 쓰는) 것 마찬가지"라고
하는 것이 GPL진영과 (linux로 대표되는)의 마찰의 핵심이겠지요.

--
익스펙토 페트로눔

--
익스펙토 페트로눔

modestcode의 이미지

>> 왜냐면 같은 dual license를 사용하지 않는 프라젝트에서 하나를 선택할 수 없다면 정책상 배포할 수가 없게 됩니다.

>라이센스 중 하나를 선택할 권리는 있지만 라이센스를 변경할 권리는 없다는 것이 핵심입니다.
OpenBSD cvs 소스를 확인한 결과 역시 GPL 부분은 제거하고 commit 돼 있었습니다.
이렇든 마찬가지인 상황에서 GPL 부분만을 취한 것을 가지고 뭐라 할 수 없습니다.
만약에 말씀대로 변경할 권리가 없다면, 현재 많은 dual license 모델은 성공할 수 없다고 생각됩니다.

>이번 결과를 보시면, 원본 소스의 copyright는 그대로 놔둔 채 "파생 소스"를 어떻게 배포할 지를 결정한 것이지요.
>(이 경우 GPL로 배포) 해당 프로젝트의 정책과는 관련이 없습니다.
GPL only 정책을 가진 프라젝트에서 BSD license 부분을 그대로 가져가고 싶지 않을 수도 있으니까요. 보통 header에 두지
patch마다 GPL ony라고 명기하는 것은 아주 현실적이지 않습니다.

그리고 결과적으로 리눅스에는 그 드라이버가 공식적으로 포함되지 않았습니다. netdev 개발용 tree도 확인도 해 봤지만요.

cjh의 이미지

> OpenBSD cvs 소스를 확인한 결과 역시 GPL 부분은 제거하고 commit 돼 있었습니다.
> 이렇든 마찬가지인 상황에서 GPL 부분만을 취한 것을 가지고 뭐라 할 수 없습니다.

http://linux.slashdot.org/comments.pl?sid=282341&cid=20409747

> GPL only 정책을 가진 프라젝트에서 BSD license 부분을 그대로 가져가고 싶지 않을 수도 있으니까요.

그렇다고 해도 원저자가 쓴 라이센스를 지우지 말고, 이번에 그랬듯이 GPL을 헤더에 덧붙이면 됩니다.
그럼 이후부터는 GPL로 배포할 수 있겠지요.

--
익스펙토 페트로눔

--
익스펙토 페트로눔

modestcode의 이미지

>> OpenBSD cvs 소스를 확인한 결과 역시 GPL 부분은 제거하고 commit 돼 있었습니다.
>> 이렇든 마찬가지인 상황에서 GPL 부분만을 취한 것을 가지고 뭐라 할 수 없습니다.

>http://linux.slashdot.org/comments.pl?sid=282341&cid=20409747
이것은 OpenBSD쪽에서 잘 존중하였군요. 제가 history를 보지 않은 불찰입니다.

>> GPL only 정책을 가진 프라젝트에서 BSD license 부분을 그대로 가져가고 싶지 않을 수도 있으니까요.

>그렇다고 해도 원저자가 쓴 라이센스를 지우지 말고, 이번에 그랬듯이 GPL을 헤더에 덧붙이면 됩니다.
>그럼 이후부터는 GPL로 배포할 수 있겠지요.
원 저작자 Sam Leffle는 확실히 용인 했으므로 불법이 아닙니다. 이것은 위에서도 언급했지만 현실적으로 간단한 patch들이 header에 있는 라이센스를 따르므로(사후 컨설팅의 결과 다른 라이센스인 경우는 제외하고) patch를 포함해서 dual license인 부분을 선택적으로 따를 수 있습니다.
사실 저라면 라이센스 부분을 건들지 않겠습니다만, 일반론으로 가서(다른 모든 dual license의 경우) 불법인지 의문입니다. 아마도 기존 법률 시스템을 거친다면 확실한 결론이 나겠지만요.

modestcode의 이미지

>>> OpenBSD cvs 소스를 확인한 결과 역시 GPL 부분은 제거하고 commit 돼 있었습니다.
>>> 이렇든 마찬가지인 상황에서 GPL 부분만을 취한 것을 가지고 뭐라 할 수 없습니다.

>>http://linux.slashdot.org/comments.pl?sid=282341&cid=20409747
>이것은 OpenBSD쪽에서 잘 존중하였군요. 제가 history를 보지 않은 불찰입니다.

이것은 OpenBSD쪽에서 잘 존중했다고할 수 없을 것 같습니다.
왜냐면 2004년에 원저자가 FreeBSD에 dual license로 commit한 것을 OpenBSD에서 import 했습니다. 근데 2007년에 원저자가 FreeBSD에서 BSD license로 바꿨다고 해서 소급적용해서 OpenBSD에 있는 현재 코드의 라이센스를 바꾼 것은 문제가 있습니다.

http://permalink.gmane.org/gmane.linux.kernel.wireless.general/5401

Quote:

The code in question is my code. It has my copyright (modulo bits shared with onoe-san who was consulted on the switch from dual-bsd/gpl to bsd only in freebsd). Of course what was amusing was how after I changed the license on the current code in freebsd certain folks retroactively applied the license changes to code that was 3 years old.
cjh의 이미지

위 경우 실제 Copyright을 바꾼건 원저자이므로 큰 문제는 되지 않을듯 싶네요. ("그 코드랑 100% 같은 소스였냐"라고 하면
아니긴 합니다만) 그 다음 문장에서 Sam Leffler (해당 dual-licensed 코드의 저자)는 자신의 코드를 도용하지
않는 한 크게 신경쓰지 않는다고 쓰고 있습니다.

I dual-licensed the code so folks could adopt and use it however they saw fit. As I've said before I don't care what people do with the work I give away so long as they don't claim it's their own.

이 논쟁의 핵심은 "원저자가 아닌 사람이 dual-licensed의 라이센스 중 하나를 임의로 삭제할 수 있는가?"
라고 봅니다. 라이센스 변경은 원저자만 가능하다는 조건 하에서, "삭제=라이센스 변경" 이라고 보는 사람은 안된다고 하는 것이고(Theo 등), "둘 중 하나만 쓰라고 했으니 하나만 남기는 건 변경이 아니다"라고 하는 사람의 두 가지 부류가 있는 것이지요.

누군가 신뢰할 수 있는 법적 견해를 보이기 전에는 깔끔하게 정리되기는 어려울 것 같습니다만.

--
익스펙토 페트로눔

--
익스펙토 페트로눔

modestcode의 이미지

>위 경우 실제 Copyright을 바꾼건 원저자이므로 큰 문제는 되지 않을듯 싶네요. ("그 코드랑 100% 같은 소스였냐"라고 하면
아니긴 합니다만)
제가 말한 취지는 GPL only로 제거한 것이랑 별반 다르지 않다는 것입니다.
원저자가 직접 바꾼 것도 아니고 바꾼 후에 다시 import 한 것도 아닙니다.
원저자가 그렇다는 것은 이미 말했듯이 분명하고요.

cjh의 이미지

"원저자가 BSD/GPL로 한 것을 다른 사람이 GPL로 바꾸었다"와
"원저자가 BSD/GPL로 한 것을 (원저자가) 다시 BSD로 바꾼 것을 다른 사람이 그대로 반영했다"는
저는 느낌이 다르군요. 물론 보는 사람에 따라 심각도는 달라질 수 있고, 저는 비교적 낮다고
생각하는 편입니다.

이게 정말 심각한 문제였다면 이번에 왜 화제가 되지 않는지는 의문이군요.

--
익스펙토 페트로눔

--
익스펙토 페트로눔

modestcode의 이미지

저도 심각도로 말하자면 낮다고 생각하지만, 엄격히 말한다면 같은 사안이라는 것이죠.
왜 화제가 안 되는 지는 원저자가 확실히 했기 때문이 아닌가라고 생각됩니다.

modestcode의 이미지

Quote:
"삭제=라이센스 변경" 이라고 보는 사람은 안된다고 하는 것이고(Theo 등),

Theo de Raat가 처음엔 Alan Cox가 불법을 조장하고 있다고 목소리를 높였지만 이젠 소스를 돌려 받지 못하는 도덕적인 측면을 왜 강조하고 있는지 생각해 볼 필요가 있습니다(실제론 서로 공유 되는 측면이 많이 있지만요).
마잇의 이미지

듀얼 라이센스는 둘중의 한가지를 택해서 나머지 한가지에는 상관없이 원하는 라이센스로만 이용하는 것이 핵심 아니던가요?

QT의 경우 처럼 QPL, GPL 중 한가지를 택해서 다른 한가지 라이센스와는 빠이빠이 할 수 있는 걸로 알고 있는데 헷갈리네요. KDE 진영은 GPL을 선택했고 어디선가 QPL 라이센스의 상용 버전을 구입해 GPL과는 상관없이 독점 소프트웨어를 개발하는 곳도 있을테고 말이죠.

BSD/GPL 듀얼 라이센스라면 GPL로 재배포 하는 순간 BSD 라이센스가 강제하는 효력은 다 사라지는게 아니던가요? GPL의 요건만 충족시키면 되지 않을까요

그것이 아니라면 듀얼 라이센스라기보다는 두가지를 합한 새로운 라이센스라고 보는게 옳지 않을까 싶네요.

--
마잇


--
마잇

eungkyu의 이미지

역시 저처럼 헷갈리는 분이 많으시군요.

제가 간단히 요약해보자면,

"재배포할 때 라이센스 선택 가능합니다.
단, 원 소스에 있던 저작권 문구를 마음대로 지워서는 안됩니다."

마음대로 지워버리면 마치 새로 작성된 소스처럼 되어서 소스 훔치기가 되어버린다는 것이지요.

이것이 제가 이해한 요지입니다.

jg의 이미지

http://uwsg.indiana.edu/hypermail/linux/kernel/0709.0/0487.html

흠.. 메일링리스트 글을 쭉 읽다보니 듀얼 라이센스에 어느 한쪽을 지울 수 있다고
표기가 되있다면 당연히 지울 수 있고 배포할 수 있다는 결론 내리게 되었습니다.
즉 듀얼라이센스를 일차적으로 이용하는 입장에서 본 것입니다.

그러나 다른 한쪽을 지우더라도 듀얼라이센스의 2차적인 사용자에게 대해서도
원 저작자의 소스에 대해서는 원 저작자의 라이센스를 적용받습니다.
1차적으로 라이센스를 지웠던 사용자는 여기에 대해 라이센스를 바꿀 수 있는
어떤 권한도 없다는 것입니다. (당연한 것이겠지만)

그러나 제가 궁금한 것은 그런 차이가 없다면 왜 지우냐는 것입니다.
제 삼자의 입장에서 보면 혼란만 가중시키는 것이 아닌가요?
개인적으로 알아보지 않는이상, 파일에 드러난 라이센스만 보고는 판단하기 어렵습니다.
뭐.. 파일에 드러난 라이센스와 같게 라이센스를 간다면 문제가 될 것이 없지만
그게 아니라면.. 일단 불이익을 안고 가는 것 아닌가요?

--
perl -e's@@JEON Myoung-jin@;sub man{s| _|her e|}
sub see{s;^;Just;;u;s;e ;Perl ;;to;print$_,$/}$uperMan=M;
s=^....=U are not=;s~$uperMan~~;&admitIt;s=U are = A=;s|young|_|;&man;
sub admitIt{say;ye;s!-\w+! Hacker!};see U'

$Myoungjin_JEON=@@=qw^rekcaH lreP rehtonA tsuJ^;$|++;{$i=$like=pop@@;unshift@@,$i;$~=18-length$i;print"\r[","~"x abs,(scalar reverse$i),"~"x($~-abs),"]"and select$good,$day,$mate,1/$~for 0..$~,-$~+1..-1;redo}