MySQL 라이센스에 대한 고찰
mysql 라이센스에 대해서 얼마 전에 Channy 님의 글에서 다음과 같은 글을 남긴 적이 있었는데 최근 제로보드 업그레이드 등과 맞물려 mysql 라이센스에 대한 불필요한 오해가 많이 발생하는 것으로 판단되어 이에 대한 제 의견을 올립니다.
mysql의 라이센스는 GPL/Commercial 을 사용자가 선택할 수 있습니다. 그리고 GPL 버전을 사용하면 GPL의 의무를 지키기만 하면 됩니다. 그런데 GPL의 의무는 해당 소프트웨어를 타인에게 배포할 때 발생하는 것이고 해당 소프트웨어를 사용하여 서비스를 할 때에는 소프트웨어 자체가 타인에게 전달되는 것이 아니기 때문에 특별한 의무가 발생하지 않습니다.포털 사이트의 경우 mysql이 포함된 제품을 판매(mysql을 구매자에게 배포)하는 것이 아니기 때문에 GPL 버전을 사용한다고 해서 문제가 될 것은 없습니다.
mysql의 GPL 버전에 실제로 영향을 받는 사람들은 개별 웹 에이전시나 프리랜서들입니다.
mysql 라이센스에 대한 2006년 8월 6일자 mysql 본사 정책은 http://www.mysql.com/company/legal/licensing/ 에 정리되어 있습니다. 이를 잘 해석해 보면 상용 라이센스를 구매하여야 할 경우는 자유 소프트웨어/오픈소스 소프트웨어가 아닌 소프트웨어들과 mysql을 함께 배포하는 경우 뿐입니다. 그 외에는 mysql의 gpl 버전을 그대로 사용하여도 무방하며 이 경우 gpl의 의무를 지키기만 하면 문제가 없습니다.
gpl의 의무는 제가 위에서 적은 것과 마찬가지로 소프트웨어를 배포하는 시점에 발생하는 것이므로 mysql gpl 버전을 다운받아서 다른 이에게 배포하지 않은 채로 사용한다면 사용에 별다른 의무사항이 존재하지 않습니다. 대표적인 경우가 인터넷 포털 사이트 등이 되겠지요.
그런데 위에서 개별 웹 에이전시나 프리랜서들이 영향을 받을 수 있다고 한 부분은 조금 더 자세하게 쓰면 다음과 같습니다. 요약하자면 소켓이나 파이프를 이용하는 DBI나 ODBC를 통해서 해당 소프트웨어가 mysql과 통신하는 경우에는 gpl 버전을 그대로 사용할 수 있습니다. 즉 가장 대표적으로 php가 이 경우에 속하며 mysql 서버 프로세스와 apache 웹 서버 프로세스의 php 모듈은 동일한 서버일 경우 유닉스 도메인 소켓으로, 서로 다른 서버일 경우 TCP/IP 소켓으로 통신하게 되어 이 php 모듈 위에서 돌아가는 php 애플리케이션(웹 에이전시나 프리랜서들이 작성한 것)은 자유 소프트웨어/오픈소스 소프트웨어가 아니어도 문제가 없습니다.
따라서 commercial 라이센스를 구매하여야 하는 경우는 mysql의 클라이언트 라이브러리와 직접적으로 링크되는 자유 소프트웨어/오픈소스 소프트웨어가 아닌 소프트웨어를 따로 작성하여 고객에게 넘겨주는 경우로 그 범위가 상당히 좁혀지고, libmysqlclient와 함께 링크가 되지 않는다면 gpl 버전을 다른 소프트웨어들과 함께 배포도 할 수 있습니다. 왜냐면 gpl 라이센스는 gpl 소프트웨어가 gpl이 아닌 다른 소프트웨어들과 함께 배포되는 것을 막고 있지는 않기 때문입니다.
다만 지금 mysql의 라이센스에 대해서 여러가지 혼란이 일어나고 있는 것은 위와 같이 mysql이 듀얼 라이센스로 배포되면서 gpl 버전에 대해 부여되는 권한/의무와 commercial 버전에 대해 부여되는 권한/의무에 대해 명확히 구별하지 않은 채 무조건 mysql을 가지고 상용 서비스를 하려면 commercial 라이센스를 구매하여야 한다는 식으로 인식되고 있기 때문입니다.
그러나 이는 어디까지나 저의 개인적인 해석입니다. 실제로 mysql의 저작권자인 MySQL AB가 mysql의 저작권을 어떤 식으로 고객들에게 enforce할 것인가는 MySQL AB의 고유 권한입니다. 의도하였든 의도하지 않았든 간에 http://www.mysql.com/company/legal/licensing/ 에도 가장 일반적인 경우가 될 개별 php 애플리케이션의 라이센스에 따른 gpl 버전/commercial 버전의 선택 기준에 대해서는 언급되어 있지 않기 때문에 최종적인 의견은 MySQL AB 본사에 문의하여 보는 것이 가장 좋습니다.
댓글
잔머리 하나
잔머리 하나 굴리면,
웹에이젼시에서는 계약서에 "mysql은 고객이 직접 설치하돼, 웹에이젼시 측에서 모든 기술 지원을 한다"라고 하고 실제로는 다 해주면 '배포' 문제는 피해 갈 수도 있겠네요.
<- 이거면 안되는 게 없어~
정품 소프트웨어 사용 캠패인
<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인
그러니까...
mysql library를 직접 사용해서 상용 소프트웨어를 만든 경우가 아니라면 거의 GPL 버전을 써도 무방하다는 거군요.
옛날에 고등학교 홈페이지 서버를 보니까, 웹에이전시에서 자체적인 관리 데몬을 만들어서 돌리던데 그런 것이 mysql과 통신하는 것이 아니라 mysql 라이브러리를 직접 써서 만든 것이라면 문제가 될 수 있겠네요.
한때 mysql의 국내
한때 mysql의 국내 총판에서 몇몇 업체(주로 웹호스팅)에 license fee(그것도 한국 전용 요금제?를 만들어서)를
요구한 적이 있었지요. 지금은 그런 얘기가 싹 들어갔습니다만...
혼동되는 MySQL 라이센스 정책
MySQL 라이센스 정책에 많은 혼동이 있는 이유는 라이센스 문구의 모호함에도 있겠지만, MySQL사의 상용라이센스 유도 정책으로 당한 고객 사례가 빈번해지면서 (미국의 경우가 대부분) 그 파장으로 인한 면도 있는 것 같습니다. MySQL사의 support forum의 License 섹션(http://forums.mysql.com/list.php?4)을 보면, 아직도 수많은 고객이 문구의 모호함으로 인해 질문을 하고 있고, MySQL Sales에 연락하라는 식의 답이 많군요. 어쨋든, 결국 사례별로 정리되는 데에는 시간이 걸릴 것 같고, 제가 아는 바로 가장 분명한 것은 GPL은 MySQL의 라이브러리를 이용한 코드가 개발자(회사)의 손을 떠나 다른 사람(회사)에게 갈 때 적용이 됩니다. 아래는 예입니다.
- 게임포털회사에서 java로 MySQL JDBC를 이용하여 게임을 개발하여 서비스하는데, 클라이언트에 java코드가 분배되는 방식이다. ==> GPL 위반입니다.
- SI 회사 (혹은 프리랜서)가 MySQL ODBC를 이용하여 응용을 개발하여 고객에게 납품하였다. ==> GPL 위반입니다.
- 포털회사에서 MySQL을 이용하여 게시판 서비스를 자체 개발하였고, 클라이언트쪽에는 MySQL을 접근하는 코드가 분배되지 않는다. ==> GPL에 문제 없습니다.
국내의 경우 자체개발보다는 외주 용역이 많기 때문에 전체적으로 타격이 클 것으로 봅니다.
또 한편 생각으로는, GPL은 SW의 공개를 통한 공유 철학을 지키기 위해 있는 것이고, 따라서 MySQL을 사용할 때에는 이러한 철학을 견지하여 모두 공개한다는 생각에서 출발하면 아무런 문제가 될 것이 없을 겁니다.
...
> - SI 회사 (혹은 프리랜서)가 MySQL ODBC를 이용하여 응용을 개발하여 고객에게 납품하였다. ==> GPL 위반입니다.
위에 권순선님도 상용프로그램이 ODBC 를 이용해서 개발해도 아무 문제가 없다고 하셨고 제가 알기로도 이게 맞는것으로 알고 있는데 어떤 의미에서 GPL 위반이라고 하신건지 좀 의아하군요?
"고객에게
"고객에게 납품하였다" 때문에 GPL 의 영향을 받는 것일 듯 합니다.
F/OSS 가 함께하길.. (F/OSS서포터즈 : [[FOSS/Supporters]], [[FOSS/Supporters/Group]]) - 게시판 활성화 프로젝트 : 하루에 2개의 새글 쓰기 -
F/OSS 가 함께하길..
ODBC를 이용할 때
ODBC를 이용할 때 libmysqlclient와 개발된 응용 소프트웨어가 링크될 경우 해당 응용 소프트웨어를 GPL이 아닌 독점 라이센스로 고객에게 납품하면 GPL 위반이 됩니다.
...
요 며칠 웹에서 관련사항들을 검색해 보았습니다. 결론을 말씀드리면,
http://www.mysql.com/company/legal/licensing/commercial-license.html
여기에 잘 정리되어 있네요.
If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries.
이걸 보시면 소켓이건, ODBC 건 libymsqlclient 건 아무 상관이 없고 결국 상업적으로 판매하려는 제품을 쓸 때 MySQL 이 설치되어야 한다면 상업용 버젼을 구입하여야 합니다. 물론 이건 하나만 구입하면 되는게 아니라 제품을 팔 때마다 각각의 상업용 버젼을 계속 구입하여야 합니다.
따라서 회사 자체내에서 개발해서 쓰는 경우에만 GPL 버젼을 쓸 수 있을 뿐, 웹에이젼시나 프리랜서가 MySQL 을 이용하는 응용을 개발해서 판매하는 경우에는 상업용 버젼을 구입해야 합니다.
(소켓이나 파이프를 통하는 부분의 얘기는 어디서 보신것인지 궁금합니다)
그건
그건 아니지요.
A소프트웨어가 ODBC로 DB에 연결될 수 있는데 pgsql을 연결하거나 mssql을 사용할수도 있는것 아니겠습니까?
고객이 무슨 DB를 쓰던 A소프트웨어를 제작/판매하는 사람은 신경 안써도 상관없지요.
고객이 mysql을 선택했을 뿐이고 A소프트웨어를 제작/판매하는 곳에서는 A소프트웨어를 잘 쓸수 있도록 mysql이건 pgsql이건 mssql에 대한 지원을 해줄수 있을 뿐이죠.
물론 A소프트웨어가 mysql로만 돌아간다면 문제의 소지가 있을수 있겠죠.
제가 이야기한 것은
제가 이야기한 것은 http://www.mysql.com/company/legal/licensing/foss-exception.html 에 근거한 분석입니다.
그리고 GPL이냐 아니냐와 해당 SW를 상업적으로 판매하느냐 않느냐는 관계가 없습니다. http://www.mysql.com/company/legal/licensing/foss-exception.html 에 있는 내용대로 개발하면서도 얼마든지 상업적으로 판매할 수 있으니까요. (commercial application)
...
> mysql의 GPL 버전에 실제로 영향을 받는 사람들은 개별 웹 에이전시나 프리랜서들입니다.
제가 올린건 이 부분에 대한 얘기를 하고 있는 것입니다.
다시말해 소스를 공개하지 않고 MySQL 을 이용하는 제품의 상업적인 판매가 가능하느냐의 문제입니다.
권순선님의 글을 보면 PHP 는 예외적으로 이것이 가능하고 그밖의 경우에도 libmysqlclient 과 직접 링크되지 않는다면 가능하다는 것처럼 설명을 해놓으셨기에 자료를 찾아보았습니다만 잘못된 설명으로 보입니다.
FLOSS 나 php 예외 조항은 해당 프로젝트나 php 가 mysql 과 관련된 라이브러리를 포함할 수 있게 허용하는 것일 뿐 php 로 개발된 제품이 소스를 공개하지 않고 판매할 수 있다는 얘기는 찾아볼 수 없습니다.
그리고 GPL 이냐 아니냐와 해당 SW 를 상업적으로 판매할 수 있느냐 없느냐는 관계가 없는 것 맞죠.
MySQL 이 그걸 멋지게 보여주고 있으니까요.. :)
mysql의 FLOSS License
mysql의 FLOSS License Exception 이 부분이 잘 이해가 가질
않습니다.
1) gpl과 호환되지 않는 FOSS license를 독립적으로 구성시에 같이 사용가능하다는 말은
gpl자체에서도 있는 것이 아닌지. gpl 전문을 봐도 딱 그렇게 적혀져 있지는 않습니다만,
오픈소스가 아닌 라이브러리 라도 위처럼 구성을 할 수는 있는 것으로 FAQ나와있더군요.
그렇다면 호환되지않는 license라도 위처럼 구성할 수 있다는 것과 별반 다를 것이 없는데
왜 굳이 mysql에서 License Exception을 만들어 놨는지 이해가 가질 않네요.
Exception이 정확이 무엇을 위해 존재하는 것입니까?
호환불가능하지만 인정하는 범위의 list를 보여주는 것인지,
그렇다면 gpl에서도 독립적인 부분 구성은 가능한데 굳이 왜 exception이 있어야하는지 모르겠습니다.
2) 그리고 이렇게 만들어진 결과물의 license는 gpl이 되는것인가요?
아니면 각개 각자의 license를 고유하게 지니게 되는 것인가요?
gpl의 경우 각자 고유의 license를 지니게 되어있는 것으로 보입니다만...
http://www.mysql.com/company/legal/licensing/faq.html에 보면 이런
부분도 있습니다.
Some open source licenses are not fully compatible with the GPL and so
this exception makes it possible for developers to chose their preferred
open source license and still have the ability to include the MySQL client
libraries.
You are free to distribute a Derivative Work that is formed entirely from the Program and one or more works (each, a "FLOSS Work") licensed under one or more of the licenses listed below in section 1, as long as: ....
'to chose their preferred open source license'라면 라이센스를
맘대로 선택하여 distribute가 가능하다는 것인가요?
3) 또한 Licen Exception을 보면
http://www.mysql.com/company/legal/licensing/foss-exception.html
If the above conditions are not met, then the Program may only be
copied, modified, distributed or used under the terms and conditions of
the GPL or another valid licensing option from MySQL AB.
이런 부분이 있는데 그럼 독립적인 구성이 아닐시에는 다른 license를 가진 software를 사용하는 것이
불가능하다는 의미입니까?
글쎄요. 보통 그런
글쎄요. 보통 그런 문구들은 프로그래머 같은 평범한(?) 사람들의 해석과 법조인의 해석이 다른 경우가 많습니다. http://www.mysql.com/company/legal/licensing/ 내용을 큰제목 위주로 그냥 액면 그대로 해석하면:
오픈소스 프로젝트(For Open Source Projects) => GPL 혹은 FLOSS License Exception
상업 OEM, ISV, VAR(For Commercial OEMs, ISVs and VARs) => 상용 OEM License
웹사이트, 기업, 정부(For Web Sites, Enterprise IT, and Government IT) => MySQL 엔터프라이즈 subscription, 옵션으로는 상용 라이센스.
----
그렇다면 만일 KLDP에서 MySQL을 사용한다면 어떤 라이센스가 해당되는 건가요? 액면 그대로라면 MySQL 엔터프라이즈 (옵션으로 상용 라이센스)인 듯 한데, MySQL 엔터프라이즈는 어떤 조건이며 상품(?)인지는 모르겠습니다.
프로그래머로써 뭔가 깔끔하게 이해되지 않는 것, 특히 위와같은 라이센스는 피할 수 있으면 피해야 하는 것이 아닌가 합니다. 라이센스 명확하게 이해 되는 소프트웨어, 특별히 법조인의 해석과 프로그래머의 해석이 상충하지 않을 정도의 간결하고 명확한 라이센스가 필요하지 않을까 합니다.
차라리
일반 법조문이 더 보기 편하다는 생각이 듭니다. 상세히 많은 조항들을 가지고 정확하게
정의하고 있으니까요.
근데 이건 가이드라인처럼 디테일하지않아 많은 부분이 혼란스럽네요.
'프로그래머의 해석이 상충하지 않을 정도의 간결하고 명확한 라이센스'란 말씀에 동감하는 바입니다.
어디선가
지나가면서 봤는데 일부러 GPL같은 경우도
크게 라인만 그어놨다고 하더군요.
디테일하게 파고들경우 악용의 소지가 크기때문에..
하나하나 조목조목 항목을 열거하면 편하기야 하겠지만
그만큼 그 조항만 비껴가면 되니까요.
MySQL이 Sun에
MySQL이 Sun에 인수되면서 라이센스 정책 등에 변화는 없는 건지 궁금합니다.
--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
댓글 달기