GPL소프트웨어 채용보류-영국 업계단체가 정부에 강력히 호소
기사제목: GPL 소프트웨어 채용 보류 - 영국 업계 단체가 정부에 강력히 호소
기사작성 : RisaPapa
영국의 업계 단체인 Intellect가 영국 정부에 대해, 오픈 소스 소프트웨어, 다시말해 GPL(General Public License) 소프트웨어의 채용을 억제하도록 호소하고 있다.
Intellect는 작년, 영국 업계 단체인 Computer Services and Software Association(CSSA) 와 Federation of the Electronics Industry(FEI)의 합병에 의해 발족된 단체이다. 미국 Microsoft, 미국 IBM, 미국 Intel, 영국 BAE Systems등 하이테크 기업이 지원하고 있고, 약 1000여사의 영국 기업을 대표하는 업계 단체이다.
Intellect는 "정부 자금에의한 소프트웨어에서 오픈 소스 라이센스를 조건으로 하면 입찰이나 완성된 소프트의 품질, 더나아가서 정부기관의 기밀성에까지 마이너스 영향을 줄 가능성이 있다" 고 밝혔다.
특히 Intellect가 영국정부에 충고한 것이, GNU/Linux가 베이스로하고 있는 GNU General Public License(GPL)란 점이다. Intellect는, 정부자금에 의해 개발되는 소프트웨어에 관해서 그 디폴트 라이센스 리스트로부터 GPL을 제외할 것을 요구하고 그 위에 각 행정기관에 대해서도 기본적으로 GPL에서 손을 떼도록 강력하게 촉구했다.
Intellect가 이러한 코멘트를 발표한 것은 Intellect가 참가했던 영국정부 OEE(Office of the E-Envoy) 와 영국무역산업성(DTI)과의 심의회에서 공공자금에 의한 소프트개발에서 오픈 소스 소프트웨어 개발에 오픈 소스 라이센스를 요구했기 때문이다. OEE와 DTI는 현재, 정부자금에 의한 소프트웨어의 전제 조건으로 오픈 소스 라이센스를 도입하려고 검토하고 있다.
유럽등의 정부기관에서는 오픈 소스 소프트웨어의 채용이 비용 절감의 효과가 있기 때문에 주목을 받기 시작하고 있다. 이미 정부자금에 의한 소프트웨어중 많은 수가 오픈 소스 라이센스에 의해서 릴리즈되고 있으나, 오픈소스의 보증을 총괄하는 정책은 아직 없다.
오픈 소스 라이센스를 대충 설명하자면 하나의 조직이 소프트웨어의 일부를 관리(독점)하는 것을 방지하는 것이 가능하다. 이 라이센스에서는, 수정한 부분을 개발 커뮤니티에 다시 되돌리는 조건 아래, 소스 코드의 테스트나 변경, 재배포를 인정하기 때문이다. Intellect는 "이러한 오픈 소스 라이센스의 사용에 다른 의견을 표명하는 것은 아니다." 라고 하면서도 GPL의 사용에 관해서 강경한 반대 입장을 표명하고 있다.
"GPL조건에 의해, 정부는 소프트웨어(산업)로부터 이익을 얻을 수가 없다. 또한 상용목적의 소프트웨어 기업을 멀리하는 일이 벌어질 수도 있다." 고 덧붙였다.
저걸보고 느낀점..
:P 오픈소스는 이미 시대의 대세입니다.
강경한 반대입장이 내세우는 논리정도는 이미 옛날에 압도할만한 힘을 가지고있고, 서서히 키워나가고 있습니다.
공산주의와도 비슷하긴 하지만, 또 뭔가 다른것이 오픈소스죠 +_+
공산주의는 누군가 제약을 가하고 뭔가 폐쇄적인 분위기 인것에 비해..
오픈소스는 완전 살맛나는, 사람사는 세상이죠.
오픈소스가 돌아가는 세상을 보고있자면, 옛날 팬터지 소설에서나 나오는 작고 평화로운 마을의 분위기가 생각납니다.
오픈소스에 관한 이러한 사실들을 잘 모르나보군요 :evil:
원래 어른이 되면 될수록 새로운것을 받아들일땐 "싫으면 싫고, 좋으면 좋은것"이 확실해지죠 :wink:
그런데 저는 어른이 되었다고 해서 "싫으면 싫고, 좋으면 좋다" 라고하는게 싫더군요.
제대로 알지도 못하면서 섣붙리 결정하게 되니까 :lol:
그런데, 한국에도 저런 보수파가 많아서 문제인것 같습니다.
생각이 늙은 이들이 지배하는 세상치고 암울하지 않은 세상본적 없는것 같네요 =_=
"나에게 익숙하지 않은건 무조건 싫거나 좋아!"
"그냥, 당연하다" 라는 생각은 할 수 없는걸까요?
L-System
Re: 저걸보고 느낀점..
저는 GPL라이센스에 의구심을 가지고 있습니다. 예를 들어 이러한 부분입니다.
PostgreSQL에서 "readline"을 사용하지 못하는 예입니다. "readline" 라고 불리는 라이브러리는 정보를 컴퓨터에 입력할 때에 화살표 키를 사용하면서 다른 작업이 가능하도록 하는 것인데 PostgreSQL은 GPL과 다른 규정을 가지는 BSD타이프 라이센스에 기반을 두고 릴리즈되고 있기 때문에 내부에 readline등의 GPL코드를 자유롭게 삽입할수가 없습니다.
만약에 readline라이브러리가 필요해 코드를 삽입하면 PostgreSQL소프트 전체를 GPL로 하지 않으면 안됩니다. 그러나 다행이도 BSD라이센스의 libedit이라는 소프트가 같은 기능을 가지고 있기는 합니다.
또 제가 참여하는 운영시스템 프로젝트에서 GCC컴파일러를 수정해서 이 컴파일러로도 개발이 가능하도록 GCC의 프리프로세서만을 사용하고 어셈블코드를 생성해 새로 개발된 컴파일러로 컴파일을 해서 바이너리를 생성합니다. 그런데 GCC에서 생성한 어셈블 코드이기 때문에 라이센스는 GPL을 적용해야한다고 주장하는 세력들이 나타나 개발이 잠시 중단되었습니다. 원래 개발되는 운영시스템의 C소스는 BSD-LIKE로 릴리즈되고 있고 원래의 C소스의 라이센스가 적용되어야 한다고 반론하고 현재의 FreeBSD등의 BSD라이센스를 가진 C소스를 GCC로 컴파일하면 GPL을 적용해야만 하는가 하는 식으로 반론을 펼치고 있기도 합니다.
이러한 경험을 하면서 GPL라이센스에서 특히 라이브러리 사용에 관한 라이센스의 구속력에 대해서 좀더 완화해야 되지 않는가 하는 생각을 하는 것입니다. 가끔 아메바와 같은 성질을 가지는 라이센스라고 생각될 때도 있습니다.
Re: 저걸보고 느낀점..
안녕하십니까. php 스쿨 카이지입니다. 여기서도 뵙게 되는군요 :-)
애초에 GPL이 만들어질 때, 바로 그러한 아메바같은 성질을 목표로 만들어진 것입니다. (FSF 사이트에 가보면 아시겠지만, 이녀석들 지독한 빨갱이들입니다. :-) ) 또한 그런 라이센스가 필요하다면 새로운 라이센스를 만들어 적용하면 되는 것이지, 굳이 지금의 GPL을 완화할 필요는 없다고 생각합니다. 또한 완화해서도 안됩니다. 그 누구보다도 지금까지 자신의 저작물을 GPL로 내놓은 사람들이 그것을 용서하지 않을 것입니다.
FSF는 절대 놀면서 지금의 GNU 세상을 만든 것이 아닙니다. Emacs, gcc와 같은 컴파일러와 유닉스의 유틸리티들을 하나하나 만들고 여건을 조성하여 지금과 같은 세상을 만든 것입니다(정작 중요한 커널은 리눅스 토발쯔에 의해 완성되었지만). 만약 누군가 BSD 라이센스로 이루어지는 또다른 진영을 만들고 싶다면, 바로 그렇게 하면 됩니다. 자신이 만든 것을 BSD 라이센스로 내놓는 것이죠.
만약 BSD를 더 선호하는 사람들이 많았다면 세상은 그렇게 돌아갔을 것입니다. 그러나 많은 개발자들이 자신의 것을 공개할 때 GPL 라이센스를 택했고, 그결과 지금의 GNU 세상이 이루어진 것입니다. 지금부터라도 사람들이 자신의 것을 공개할 때 BSD를 택한다면, 세상은 그렇게 돌아갈 것입니다.
실무에 종사하는 리사파파 님으로써는 당연히 GPL에 대해 좋은 인식을 가지실 수 없을 것입니다. 만약 제가 취직하여 소프트웨어 개발에 종사한다고 해도 역시 마찬가지 태도를 취할 수밖에 없을 것입니다(전 아직 공부하는 입장입니다 :-) ). 그러나, 애초에 GPL 프로그램들은 그런 사람들을 위해 공개된 것이 아닙니다. 독점 프로그램을 사용하기 위해서는 돈을 내야 되지만, GPL 프로그램들은 그 돈 대신에 GPL을 사용해야 한다는 댓가를 지불해야 하는 것이죠. GPL을 단지 '무료'라고 생각해서는 곤란합니다.
그런 면에서 MS (로 대표되는 독점 소프트웨어) 진영은 또 하나의 훌륭한 해답이 아닐까 싶습니다. 돈만 내면 컴파일러고 라이브러리고 얼마든지 마음 편하게 이용할 수 있습니다. 또한 요새는 OS 자체도 유닉스 계열에 딸리지 않는 훌륭한 완성도를 보여주고 있습니다. 제 생각에는 님께서는 굳이 GPL로 강력하게 제한받고 있는 리눅스 쪽을 고집하는 것보다는 MS 쪽의 자원을 이용하는 것을 고려하는 것이 어떨까 합니다만...
ps. gcc 컴파일러를 이용하여 non-GPL 인 프로그램을 제작하신다면, gcc의 저작권을 가지고 있는 FSF에 직접 문의를 넣어보는 것이 어떨까 생각합니다. 확실한 답변을 얻는다면, 나중에 문제가 생긴다 하더라도 최소한 gcc와 관련된 부분에서는 문제가 생기지 않을 것입니다.
Re: 저걸보고 느낀점..
gcc 컴파일러로 만든 결과물에 대해서는 GPL 안적용해도 상관 없습니다.
저작권은 자기 맘입니다. 그렇기 때문에 gcc로 컴파일된 프로그램은 아무
문제 없습니다.
단, gcc를 개조해서 어쩌구저쩌구 하거나 할 때에 GPL 라이센스가 문제가
되죠 (같은 GPL로 배포해야 하니까요) 또한 gcc 코드 일부나 전부를 다른
프로그램에 집어 넣을 때도 해당되고요.
GPL 라이브러리가 문제가 되는 이유는 이들 라이브러리를 사용하는 것
자체가 프로그램 속에 GPL 라이센스 코드를 집어넣기 때문에 여기에
걸려드는거지요.
Written By the Black Knight of Destruction
Re: 저걸보고 느낀점..
gcc의 결과물은 gpl의 영향을 받지 않습니다. 상용으로 팔아도 됩니다. :)
물론 gcc를 수정해서 non-gpl로 배포하면 문제가 있겠죠.
즉, 이럴 경우에는, (수정하지 않은)cpp를 그대로 이용하고, 이 출력물을 직접 만드신 BSD-ish compiler에 이용하시면 되지 않을까 생각됩니다.
음... 얼마전에 gdb에 ARM용 multi-ice support를 장착한 케이스가 있습니다... 이 경우에는, multi-ice DLL 파일은 별도 배포하고, 이의 헤더파일은 ARM측에서 GPL로 공개해서, 상용코드를 DLL로 불러와서 이용하는 방법을 쓰던데... 이런 접근을 이용하는 것은 어떠실지요....
즉, interface 부분 코드는 GPL로 공개해서 gcc의 patch 형태로 배포하고, 핵심 엔진은 별도의 라이브러리로 제작하는...
(GPL 프로그램에서 다른 라이센스의 라이브러리를 이용하는 것은 제한하지 않겠죠. 만일 그렇다면 VC++등의 상용 툴킷으로 컴파일하는 것 자체가 어불성설일테니까)
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
Re: 저걸보고 느낀점..
맞습니다. GPL의 목적이 다분히 아메바 같은 성질을 가지도록 하는 것입니다. Public Domain과 다른 점이 바로 한번 GPL로 태어난 소프트웨어의 부산물 모두가 GPL 라이센스를 가져야 한다는 점입니다. 이는 GNU 진영의 전략입니다. GNU 진영의 궁극적인 목적은 모든 소프트웨어의 자유(Free) 소프트웨어화입니다. 어디까지나 FSF를 주축으로 하는 GNU 진영에 한에서는 그렇습니다.
다만 파파님께서 드신 예에서는 컴파일러가 생성한 코드 자체를 GPL로 하실 필요는 없을 듯 합니다. 물론 컴파일러 자체를 뜯어 고쳐서 새로운 gcc를 만드셨다면 GPL로 라이센싱 하셔야 합니다.
Re: 저걸보고 느낀점..
GPL 라이센스 프로그램들은 특별한 언급이 없으면 OpenSSL 라이브러리를 이용할 수 없습니다. OpenSSL은 BSD-like license를 가지고 있어서, 이 라이브러리를 이용하려면 "OpenSSL을 사용합니다" 류의 문장을 추가해야만 합니다. 그런데 GPL 라이센스는 이런 추가적인 제한을 가하는 것을 금하기에 함께 쓰일 수 없게 됩니다.
그밖에 GPL로 된 template library가 있다면 컴파일되면서 static link되는 셈이라 GPL이 아닌 프로그램에서는 이용할 수 없습니다.
GPL에 따르기 싫다면, 한가지 방법이 있습니다.공짜인 GCC를
GPL에 따르기 싫다면, 한가지 방법이 있습니다.
공짜인 GCC를 안쓰는 방법이죠..;;
ㅡ_ㅡ 의구심 가지실 필요 없습니다.
많은 회사들이 MS진영으로 옮겨 간 이유중 하나입니다.;;;;
GCC등의 편리하고 기능이 좋은 소프트웨어들이 바로 FSF가 파놓은 모든 소프트웨어 GPL화의 함정이죠.
그리고 GCC로 컴파일한것은 GPL이 되어야 한다고 주장하는 부류들의 이유는
저도 스태틱 라이브러리들의 링크 때문인것으로 생각되네요;;
그리고, 저런 강경하고 무식해보이는 전략인 모든 소프트웨어의 GPL화는
FSF의 빨갱이식 정책과 관련된것이 맞습니다 :D
빨갱이라는게 뭐냐면 "자신이 믿는것에 관한 한 어떠한 수단과 방법도 가리지 않는다"
이죠 :wink:
뭐 저런 강경한 정책때문에 사람들에게 반감을 살때도 있지만, 개인적으로 GPL은 상업적으로도 충분히 괜찮은 모델이라고 봅니다.
적어도, 넷스케이프가 공개되지 않았다면.. 을 상상해보면 말이죠.
뭐 이런얘기하면 복잡해지니.. 나머지는 성당과 시장이라는 글에 잘나와있더군요.(전 이 글보고 저도 빨갱이 되는거아닌가하고 놀랠정도로 충격받았습니다. :wink: )
L-System
[quote="yubgipenguin"]GPL에 따르기 싫다면, 한가지
허, 저는 GPL 안따르고도 지난 몇년동안 멀쩡하게 GCC를 써왔는데요?! 저뿐만 아니라 전세계 수천명의 개발자들이 GPL을 안따르고도 지난 몇년 동안 멀쩡하게 GCC를 써왔습니다.
셀빅 SDK GCC
셀빅 SDK도 GCC로 알고 있는데 소스 공개 안 했던데요.
--
Minimalist Programmer
[quote="yubgipenguin"]GPL에 따르기 싫다면, 한가지
glibc와 gcc를 약간 혼동하신 것이 아닌지? *BSD의 경우에는
glibc가 아니고, BSD license를 가지고 있는 libc를 사용하므로
기본 컴파일러는 gcc이지만, 그 결과물이 GPL을 따르지는 않습니다.
----
Let's shut up and code.
엇 지금 그얘기하러왔는데http://www.gnu.org/phil
엇 지금 그얘기하러왔는데
http://www.gnu.org/philosophy/why-not-lgpl.ko.html
GPL이 아니라, Library GPL 이군요.
윗분들 글 보고 GPL인줄알았는데..
Library GPL은 독점소프트웨어 쓸 수 있다고 되어있네요.. ㅇ_ㅇ;;
GPL이 적용된것을 이용할때는 GPL을 따라야하는게 맞습니다.
GPL이지만 따르지않아도 되는게 아니라 다른 라이센스이기 때문입니다.
음 그리고 libc가 C용 라이브러리를 뜻하는군요?
ㅇ.ㅇ;;
그게 GCC에 포함이 안되어있나 보네요? 전 당연히 포함되어있을줄알고..;;
L-System
g++ 로 짠 STL 코드들은 --;
쩝 리눅스에서 STL 로 짠 프로그램들은 전부 GPL를 따라야 한다는 말인가요?
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
[quote]// Main templates for the -*- C++
/usr/include/g++-3/std/bastring.h 에 들어 있는 내용입니다.
파일들을 하나씩 열어보니 STL의 일부는 HP/SGI에서 유입되어 그쪽 license를 따르고,
일부는 GPL이며 동시에 special exception을 가지도록 되어 있군요.
---
http://coolengineer.com
[quote="yubgipenguin"]GPL이 적용된것을 이용할때는 G
아마도 GPL된 프로그램을 이용하는 것과 GPL된 코드를 이용하는 것을 혼동하고 계시군요.
gcc와 glibc를 구별못하고 GPL을 논하시다니 약간 황당...
쩝 gcc 몹쓸 물건이군여 -_-;
공짜 컴파일러 찾아봐야겠네여 것참 --_--;
컴파일러와 라이브러리를 GNU로 해놓으니 여기서 파생되는건
GNU가 될수 밖에 없는구조라니 --;
상업용으로 만들일이 지금은 없어서 , g++ 쓰지만 나중에 상업용으로
만들때는 , 진짜 Free를 써야겠다는 생각이 듭니다
쩝
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
Re: 쩝 gcc 몹쓸 물건이군여 -_-;
yupgipenguin님 말씀은 전혀 사실무근이니 gcc를 자유롭게 쓰셔도 됩니다.
[quote="yubgipenguin"]Library GPL은 독
LGPL은 'Lesser GPL' 입니다.
라이브러리용 GPL이 아니라, '덜 general한 공용 라이센스' 이죠.
이 라이센스의 목적은 상용프로그램들을 개발하는 데에 free software를 이용하도록 하는 것입니다. 예를 들어, 누가 glibc를 이용한다면, 분명히 리눅스 혹은 허드 환경에서 작업을 하는 것이겠고, 그렇다면 장기적으로는 GNU platform에 정착하게 되어 이 platform을 더더욱 활성화시키겠죠.
여기에는 상용 프로그램들이 라이브러리를 '이용'할 수 있게 해 주는 대신 하나의 제약이 붙는데, 바로 '그 라이브러리 부분을 마음대로 교체할 수 있게 하는 것' 입니다. dynamic library라면 그냥 .so 파일을 첨부하는 형태가 가능하겠고, static이라면 자신이 따로 라이브러리를 갖고 와서 할 수 있도록 object file들을 제공하도록 하고, 그것도 아니라면 사용자의 요청에 따라서 최소 3년동안 재컴파일 기술지원을 하도록 하는 것... 뭐 이런 것들이 붙습니다....
LGPL은 이미 상용으로 흔히 제공되는 것들에 적용하기를 권하고 있습니다. glibc, gmp, 의 경우가 그 예겠죠. 반면 상용으로 잘 제공이 안 되는 것들(가령 GNU readline) 같은 것들은 GPL이 적용됩니다. 이를 이용하면 GPL이 적용되어야 한다는 얘기죠.
리눅스에서 돌아가는 많은 상용 소프트웨어들이 glibc를 기반으로 만들어졌음을 생각하면 편할 듯 합니다.
http://www.gnu.org/manual/glibc-2.2.5/html_node/Copying.html#Copying
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
Re: 셀빅 SDK GCC
실제로 일선의 개발자들이 GPL 프로그램을 버젓이 갖다놓고 소스를 통째로 긁어다넣는 일도 허다하다고 하더군요. debug symbol 없이 배포하면 찾을 수 없을테니깐요. 그냥 어디서 주워들은 얘기입니다.
FSF에서 제이텔 측에 태클을 안 거는 것인지... 아니면 셀빅SDK의 gcc가 자체수정한 것이 없어서 그런건지....
(자체수정한 것이 없다면 build 방법 같은 것이라도 올려야 할텐데-_-;;)
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24