<div id="readability-page-1" class="page"><section id="main_content">
        <small>2019/12/28</small>


<p>by 류창우</p>

<h2 id="ofl이란">OFL이란</h2>

<p><a href="https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&amp;id=OFL">SIL Open Font
License</a>는
(SIL OFL, OFL) 여러 오픈소스 글꼴에 사용되는 라이선스이다. 여러 글꼴에
사용되고 있고, <a href="https://fedoraproject.org/wiki/Licensing:Fonts">페도라의 추천
라이선스</a>이기도 하다.</p>

<p>한국 회사에서 만든 글꼴에서도 꽤 사용되고 있다. 네이버가 2010년
<a href="https://hangeul.naver.com/2017/nanum">나눔글꼴</a>의 라이선스를 OFL로 정하면서
한국의 글꼴에도 많이 사용되기 시작했다. 우아한형제들의 <a href="https://www.woowahan.com/#/fonts">배달의민족
글꼴</a>, 리디주식회사의
<a href="https://www.ridicorp.com/branding/fonts/ridibatang/">리디바탕</a>도 있다.</p>

<h2 id="왜-글꼴에-특별히-라이선스가-필요한가">왜 글꼴에 특별히 라이선스가 필요한가</h2>

<p>글꼴의 경우에 발생할 수 있는 골치아픈 라이선스 문제는 문서에 글꼴을 포함하는
임베딩 상황이다. 어떤 문서를 배포할 때 (특히 인쇄를 고려한 문서의 경우)
문서에서 사용한 글꼴이 문서를 받아 본 사람의 컴퓨터에 설치되어 있지 않은 경우
그 문서를 제대로 표현할 수 없기 때문에 MS 오피스, ODF, PDF와 같은 문서
포맷에는 사용한 글꼴을 문서에 포함하는 기능이 들어 있다. 하지만 글꼴을 문서에
포함해 배포한다면, 그 순간 글꼴을 복사해서 문서와 합쳐 배포하는 것이므로
저작권법에 따라 해석한다면 글꼴의 2차 저작물을 재배포하는 셈이다. 글꼴의
저작권자들도 이런 식의 해석을 원하지 않기 때문에 글꼴 라이선스에는 임베딩을
명시적으로 허용하는 조항을 넣는다.</p>

<p>특히 글꼴이 GPL일 경우 문서 전체가 GPL이 되어 버리는 묘한 상황이 되기 때문에
<a href="https://en.wikipedia.org/wiki/GPL_font_exception">GPL 글꼴 예외</a>처럼 부가
조항이 생겨나기도 했다.</p>

<p>OFL 역시 임베딩을 명시적으로 허용하는 조항이 들어가 있다.</p>

<h2 id="ofl-라이선스에-포함된-타협">OFL 라이선스에 포함된 “타협”</h2>

<p>OFL은 회사들, 특히 자기 회사의 브랜딩을 위해 글꼴을 공개하는 회사들이 제약
없이 사용할 수 있는 글꼴을 공개하게 유도하는 목적으로 만들어졌다. 그래서
라이선스에 통상적으로 포함되는 제한 (저작권자 명시/attribution, 라이선스
텍스트 포함, 저작권자 이름을 광고/홍보하는데 사용하는 것 금지) 외에 다음과
같은 특별한 제약이 있다.</p>

<ol>
  <li>단독으로 판매할 수 없다. 판매하려면 다른 소프트웨어와 함께 번들 형태로만
판매할 수 있다. 이 제약은 글꼴 디자인 회사의 경쟁사가 OFL 글꼴을 복사해
손쉽게 상업적인 글꼴 판매 시장으로 진입하지 못하도록 한다.</li>
  <li>같은 이름으로 글꼴을 수정해 재배포할 수 없다. 수정하려면 예약된 이름이
(라이선스에서 “Reserved Name”으로 지정) 아닌 다른 이름으로 바꾼 다음에
수정해야 한다. 이 제약은 글꼴 저작권자에게 브랜딩에 대한 독점적 권한을
부여하기 위해 들어가 있다.</li>
  <li>수정한다면 수정한 버전도 같은 OFL 라이선스로 배포해야 한다. GPL과
마찬가지이고, 이러한 제약을 수정 버전에서도 계속 유지하기 위해서 필요하다.</li>
</ol>

<p>이런 제약을 생각해 보면 OFL은 폰트 임베딩을 허락할 뿐 GPL보다 제약이 많은
라이선스이다. 파생 소프트웨어가 계속 자유롭게 공개되기를 바라는 GPL과는 다르게
이런 제약은 글꼴을 공개하는 회사의 권리를 보호하기 위한 제약이다. OFL은 위와
같은 타협을 통해 충분히 자유롭게 사용하고 재배포할 수 있는 글꼴 라이선스를
선택하도록 유도하고 있다.</p>

<h2 id="ofl-라이선스의-부작용">OFL 라이선스의 부작용</h2>

<p>같은 이름으로 글꼴을 수정 재배포할 수 없다는 OFL 제약은 버그를 수정해야 할 때
문제가 된다. 즉 버그를 수정한 버전을 같은 이름으로 재배포할 수 없다.</p>

<p>결국 회사에서 수정사항을 반영해야 한다. 하지만 회사에서 브랜딩을 위해 만드는
글꼴은 지속적으로 관리하기 보다는, 한번 릴리스하고 몇 번 수정한 다음 몇 년이
지나면 또 다른 글꼴을 만드는 경우가 흔하기 때문에 글꼴의 버그나 개선사항을
반영하기가 쉽지 않다. 저작권자는 글꼴을 제작한 디자인 회사와 계약을 통해
제작하는 경우가 보통이기 때문에 장기간의 후속 작업을 기대하기 쉽지 않다.
아무래도 글꼴의 발표가 일종의 이벤트로 기획되는 탓이 크다.</p>

<p>대표적으로 한국에서 나오는 거의 모든 글꼴은 백슬래시에 원화 기호 글리프가 들어
있다. (당장 키보드의 백슬래시 자리에 원화 기호가 적혀 있기 때문이다. EUC-KR
인코딩의 영문 인코딩을 ASCII에서 백슬래시를 원화 기호로 만든 KS X 1003을
표준으로 사용하면서 유니코드가 나오기도 전부터 단추를 잘못 끼운 결과이다.)</p>

<p>또 나눔고딕, 나눔명조, 나눔바른고딕에는 U+22CE CURLY LOGICAL OR (⋎) 글리프와
U+22CF CURLY LOGICAL AND (⋏) 글리프가 서로 뒤바뀌어 있는 너무도 명백한
<a href="https://bugs.launchpad.net/ubuntu/+source/fonts-nanum/+bug/1441603">버그</a>가
있다. 하지만 네이버는 나눔고딕/나눔명조에 대한 관심을 끊은 지가 오래전이라
문제를 수정하길 기대하기 쉽지 않다. 나눔바른고딕이 후속작이지만, 최근에는 <a href="https://hangeul.naver.com/">또
다른 글꼴</a>을 제작하고 있다. 게다가 네이버의 글꼴
프로젝트는 여느 오픈소스 프로젝트처럼 사용자와 개발자의 피드백을 받아들이는
체계가 없기 때문에 의견이나 개선 방향을 전달하기부터 쉽지 않다. <a href="https://tracker.debian.org/pkg/fonts-nanum">나눔글꼴의
데비안 패키지</a>를 관리하는 내
입장에서도 문제를 발견했을 때 뭔가 할 수 있는 자유도가 없다고 느껴진다.</p>

<p>버그를 수정해야 하는데 글꼴 저작권자가 움직이지 않을 때 오픈소스 다운 해법은
라이선스에 규정된 대로 이름을 바꿔서 fork를 하는 게 정석적인 방법이다. 하지만
기존 글꼴을 사용하는 소프트웨어와의 호환성은 물론, 글꼴을 사용하는 사람들의
커뮤니티를 다시 만들다시피 해야 해 사실상 하기 힘든 선택이다. <a href="https://github.com/changwoo/jebudo/">나 개인적으로
실제로 fork 시도를 하기도 했지만</a> 그리
성공적이지는 못했다. (Source Han Sans/Noto Sans CJK라는 본문 글꼴의 더 나은
대안이 생기기도 했고.)</p>

<p>또한 데비안과 같은 배포판의 경우에는 가능한 한 바이너리를 통째로 넣기 보다는
소스에서부터 빌드하는 편을 선호하는데, 글꼴에서는 사용하는 툴의 버전과 설정에
따라 결과물이 달라질 수 있으므로 SIL OFL을 준수하려면 소스 빌드는 어렵다.</p>

<h2 id="해결-방법">해결 방법?</h2>

<p>구글/어도비가 함께 제작한 Source Han Sans (어도비 브랜딩, 본고딕) 또는 Noto
Sans CJK (구글 브랜딩) 글꼴은 2014년 처음 릴리스할 때는 Apache 라이선스를
채택했었지만, 2015년에 SIL OFL로 라이선스를 변경했다. 역시 이슈에 대해
대응하지 않았다면 위에서 말한 것과 같은 문제가 있었겠지만, 이 경우는 한국
글꼴이 공통으로 가지고 있던 문제를 대부분 해결한데다가 (처음부터 다국어
버전으로 기획된 이유가 크다), 현재까지 꾸준하게 메인테인하고 있고
<a href="https://github.com/adobe-fonts/source-han-sans/issues">피드백도</a> 계속
받아들이고 있어 (아직까지는) 비교적 문제가 적은 편이다. 단 소스 빌드한 버전의
배포는 현재도 앞으로도 어렵다.</p>

<p>웹에서 많이 쓰는 Font Awesome도 마찬가지이다. 역시 OFL 라이선스지만 2012년
릴리스 이후 <a href="https://github.com/FortAwesome/Font-Awesome/issues">피드백을
받으면서</a> 꾸준히 버전업을
하고 있다.</p>

<p>OFL은 저작권자인 회사에 더 많은 통제권이 있기 때문에 그 회사가 잘 하면 모든 게
해결되고 회사가 관심을 끊으면 문제가 생기는 셈이다. 한국 회사들이 공개하는
글꼴에서도 꾸준히 잘 관리되는 모습을 기대할 수 있을까? 글꼴을 만들어 공개하는
일이 한글날에 맞춰 거창한 홈페이지를 만들고 보도자료를 뿌리는 홍보 이벤트에
묶여 있는 한 쉽지 않을 것이다.</p>



  <small>tags: <em>font</em> - <em>ofl</em> - <em>나눔글꼴</em> - <em>본고딕</em> - <em>Source</em> - <em>Han</em> - <em>Sans</em> - <em>Noto</em> - <em>Sans</em> - <em>CJK</em></small>


      </section></div>

Changwoo Hacks

OFL이란
SIL Open Font
License는
(SIL OFL, OFL) 여러 오픈소스 글꼴에 사용되는 라이선스이다. 여러 글꼴에
사용되고 있고, 페도라의 추천
라이선스이기도 하다.
한국 회사에서 만든 글꼴에서도 꽤 사용되고 있다. 네이버가 2010년
나눔글꼴의 라이선스를 OFL로 정하면서
한국의 글꼴에도 많이 사용되기 시작했다. 우아한형제들의 배달의민족
글꼴, 리디주식회사의
리디바탕도 있다.
왜 글꼴에 특별히 라이선스가 필요한가
글꼴의 경우에 발생할 수 있는 골치아픈 라이선스 문제는 문서에 글꼴을 포함하는
임베딩 상황이다. 어떤 문서를 배포할 때 (특히 인쇄를 고려한 문서의 경우)
문서에서 사용한 글꼴이 문서를 받아 본 사람의 컴퓨터에 설치되어 있지 않은 경우
그 문서를 제대로 표현할 수 없기 때문에 MS 오피스, ODF, PDF와 같은 문서
포맷에는 사용한 글꼴을 문서에 포함하는 기능이 들어 있다. 하지만 글꼴을 문서에
포함해 배포한다면, 그 순간 글꼴을 복사해서 문서와 합쳐 배포하는 것이므로
저작권법에 따라 해석한다면 글꼴의 2차 저작물을 재배포하는 셈이다. 글꼴의
저작권자들도 이런 식의 해석을 원하지 않기 때문에 글꼴 라이선스에는 임베딩을
명시적으로 허용하는 조항을 넣는다.
특히 글꼴이 GPL일 경우 문서 전체가 GPL이 되어 버리는 묘한 상황이 되기 때문에
GPL 글꼴 예외처럼 부가
조항이 생겨나기도 했다.
OFL 역시 임베딩을 명시적으로 허용하는 조항이 들어가 있다.
OFL 라이선스에 포함된 “타협”
OFL은 회사들, 특히 자기 회사의 브랜딩을 위해 글꼴을 공개하는 회사들이 제약
없이 사용할 수 있는 글꼴을 공개하게 유도하는 목적으로 만들어졌다. 그래서
라이선스에 통상적으로 포함되는 제한 (저작권자 명시/attribution, 라이선스
텍스트 포함, 저작권자 이름을 광고/홍보하는데 사용하는 것 금지) 외에 다음과
같은 특별한 제약이 있다.
단독으로 판매할 수 없다. 판매하려면 다른 소프트웨어와 함께 번들 형태로만
판매할 수 있다. 이 제약은 글꼴 디자인 회사의 경쟁사가 OFL 글꼴을 복사해
손쉽게 상업적인 글꼴 판매 시장으로 진입하지 못하도록 한다.
같은 이름으로 글꼴을 수정해 재배포할 수 없다. 수정하려면 예약된 이름이
(라이선스에서 “Reserved Name”으로 지정) 아닌 다른 이름으로 바꾼 다음에
수정해야 한다. 이 제약은 글꼴 저작권자에게 브랜딩에 대한 독점적 권한을
부여하기 위해 들어가 있다.
수정한다면 수정한 버전도 같은 OFL 라이선스로 배포해야 한다. GPL과
마찬가지이고, 이러한 제약을 수정 버전에서도 계속 유지하기 위해서 필요하다.
이런 제약을 생각해 보면 OFL은 폰트 임베딩을 허락할 뿐 GPL보다 제약이 많은
라이선스이다. 파생 소프트웨어가 계속 자유롭게 공개되기를 바라는 GPL과는 다르게
이런 제약은 글꼴을 공개하는 회사의 권리를 보호하기 위한 제약이다. OFL은 위와
같은 타협을 통해 충분히 자유롭게 사용하고 재배포할 수 있는 글꼴 라이선스를
선택하도록 유도하고 있다.
OFL 라이선스의 부작용
같은 이름으로 글꼴을 수정 재배포할 수 없다는 OFL 제약은 버그를 수정해야 할 때
문제가 된다. 즉 버그를 수정한 버전을 같은 이름으로 재배포할 수 없다.
결국 회사에서 수정사항을 반영해야 한다. 하지만 회사에서 브랜딩을 위해 만드는
글꼴은 지속적으로 관리하기 보다는, 한번 릴리스하고 몇 번 수정한 다음 몇 년이
지나면 또 다른 글꼴을 만드는 경우가 흔하기 때문에 글꼴의 버그나 개선사항을
반영하기가 쉽지 않다. 저작권자는 글꼴을 제작한 디자인 회사와 계약을 통해
제작하는 경우가 보통이기 때문에 장기간의 후속 작업을 기대하기 쉽지 않다.
아무래도 글꼴의 발표가 일종의 이벤트로 기획되는 탓이 크다.
대표적으로 한국에서 나오는 거의 모든 글꼴은 백슬래시에 원화 기호 글리프가 들어
있다. (당장 키보드의 백슬래시 자리에 원화 기호가 적혀 있기 때문이다. EUC-KR
인코딩의 영문 인코딩을 ASCII에서 백슬래시를 원화 기호로 만든 KS X 1003을
표준으로 사용하면서 유니코드가 나오기도 전부터 단추를 잘못 끼운 결과이다.)
또 나눔고딕, 나눔명조, 나눔바른고딕에는 U+22CE CURLY LOGICAL OR (⋎) 글리프와
U+22CF CURLY LOGICAL AND (⋏) 글리프가 서로 뒤바뀌어 있는 너무도 명백한
버그가
있다. 하지만 네이버는 나눔고딕/나눔명조에 대한 관심을 끊은 지가 오래전이라
문제를 수정하길 기대하기 쉽지 않다. 나눔바른고딕이 후속작이지만, 최근에는 또
다른 글꼴을 제작하고 있다. 게다가 네이버의 글꼴
프로젝트는 여느 오픈소스 프로젝트처럼 사용자와 개발자의 피드백을 받아들이는
체계가 없기 때문에 의견이나 개선 방향을 전달하기부터 쉽지 않다. 나눔글꼴의
데비안 패키지를 관리하는 내
입장에서도 문제를 발견했을 때 뭔가 할 수 있는 자유도가 없다고 느껴진다.
버그를 수정해야 하는데 글꼴 저작권자가 움직이지 않을 때 오픈소스 다운 해법은
라이선스에 규정된 대로 이름을 바꿔서 fork를 하는 게 정석적인 방법이다. 하지만
기존 글꼴을 사용하는 소프트웨어와의 호환성은 물론, 글꼴을 사용하는 사람들의
커뮤니티를 다시 만들다시피 해야 해 사실상 하기 힘든 선택이다. 나 개인적으로
실제로 fork 시도를 하기도 했지만 그리
성공적이지는 못했다. (Source Han Sans/Noto Sans CJK라는 본문 글꼴의 더 나은
대안이 생기기도 했고.)
또한 데비안과 같은 배포판의 경우에는 가능한 한 바이너리를 통째로 넣기 보다는
소스에서부터 빌드하는 편을 선호하는데, 글꼴에서는 사용하는 툴의 버전과 설정에
따라 결과물이 달라질 수 있으므로 SIL OFL을 준수하려면 소스 빌드는 어렵다.
해결 방법?
구글/어도비가 함께 제작한 Source Han Sans (어도비 브랜딩, 본고딕) 또는 Noto
Sans CJK (구글 브랜딩) 글꼴은 2014년 처음 릴리스할 때는 Apache 라이선스를
채택했었지만, 2015년에 SIL OFL로 라이선스를 변경했다. 역시 이슈에 대해
대응하지 않았다면 위에서 말한 것과 같은 문제가 있었겠지만, 이 경우는 한국
글꼴이 공통으로 가지고 있던 문제를 대부분 해결한데다가 (처음부터 다국어
버전으로 기획된 이유가 크다), 현재까지 꾸준하게 메인테인하고 있고
피드백도 계속
받아들이고 있어 (아직까지는) 비교적 문제가 적은 편이다. 단 소스 빌드한 버전의
배포는 현재도 앞으로도 어렵다.
웹에서 많이 쓰는 Font Awesome도 마찬가지이다. 역시 OFL 라이선스지만 2012년
릴리스 이후 피드백을
받으면서 꾸준히 버전업을
하고 있다.
OFL은 저작권자인 회사에 더 많은 통제권이 있기 때문에 그 회사가 잘 하면 모든 게
해결되고 회사가 관심을 끊으면 문제가 생기는 셈이다. 한국 회사들이 공개하는
글꼴에서도 꾸준히 잘 관리되는 모습을 기대할 수 있을까? 글꼴을 만들어 공개하는
일이 한글날에 맞춰 거창한 홈페이지를 만들고 보도자료를 뿌리는 홍보 이벤트에
묶여 있는 한 쉽지 않을 것이다.

OFL 글꼴의 흔한 문제

댓글