공개 SW 라이센스(GPL, LGPL, BSD)
<본 포스팅은 다음을 참고하였습니다>
오픈소스를 사용하다보면 GPL, LGPL, BSD, MIT 등 다양한 라이센스가 있는데 이에 대해 알아두어야 할 것 같아서 정리합니다.
대부분의 라이센스는 [wiki](https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
)에 표로 정리되어 있습니다.
이 사이트에는 조금 더 보기 편하게 정리되어 있습니다.
관련 링크
GLP/LGPL 전문은 읽어봐도 내용이 어려워서 무슨 말인지 알기가 쉽지 않네요. 하지만 KLDP 가이드를 보면 여러 오픈소스 SW 라이센스(GPL/LGPL/BSD 등)들이 잘 비교 정리되어 있습니다.
1. GNU GPL(General Public License)
GPL은 Free Software Foundation(FSF)에서 만든 Free 소프트웨어 라이센스로 1989년 1차 버전, 1991년 2차 버전, 2007년 3차 버전까지 발표되었습니다.
기본적으로 어떤 프로그램을 개발할 때, GPL 코드를 일부라도 사용하게 되면 그 프로그램은 GPL이 됩니다. GPL을 가진 프로그램을 유료로 판매하는 것은 가능하지만, 반드시 전체 소스코드는 무료로 공개해야 합니다.
GPL 코드를 사용한 SW를 내부적인(개인, 기관, 단체 등) 목적으로만 사용할 때에는 소스코드를 공개할 필요가 없지만 어떤 형태로든(유료든 무료든) 외부에 공표/배포할 때에는 전체 소스코드를 공개해야 합니다.
예를 들어, GPL 코드를 수정하거나 일부 사용하여 프로그램을 개발했습니다. 이제 개발된 프로그램을 개인적으로 혹은 기관, 단쳬 내부적으로만 사용하자고 하면 코드를 공개할 의무는 없으며 그냥 사용하면 됩니다. 그런데 이 프로그램을 외부에 공개하거나 판매하고자 할 경우에는 반드시 GPL 규정에 따라서 프로그램의 전체 소스코드를 무료로 공개해야 합니다.
전체 소스코드를 무료로 공개하면서 프로그램을 유료로 판매하는 것이 얼핏 이해가 안가지만, 개발자가 아닌 일반 소비자 입장에서는 충분히 구매할 수 있다고 생각됩니다. 그리고 기관 등에 프로그램을 판매할 때에는 단순한 소스코드가 아닌 시스템 구축, 관리, 유지보수 등 토탈 솔루션을 판매한다고 생각할 수 있습니다. 이러한 것들은 아무리 소스가 공개되어 있어도 비전문가가 하기 힘든 일이기 때문입니다.
그런데, 코드를 공개하면 다른 개발자가 이를 기반으로 좀더 개선된 버전의 제품을 개발하여 판매할 수도 있을 것입니다. 일견 억울할 수도 있겠네요..
GPL 관련하여 한가지 햇갈리기 쉬운 점이 있는데, 그건 자신이 개발한 SW에서 GPL 코드를 일부만 사용한 경우입니다.
GPL 전문에 보면, ‘만일 배포하고자 하는 프로그램의 특정 부분이 GPL 코드로부터 파생된 것이 아닌 독립적인 저작물일 경우에는 독립 저작물 모듈의 개별적인 배포에는 GPL이 적용되지 아니한다 (즉, 코드를 공개할 필요가 없다). 하지만 프로그램을 전체(GPL코드에서 파생된 모듈 + 독립 저작물 모듈)적으로 배포할 때에는 GLP을 따라야 한다.’ 고 되어 있습니다.
결론적으로, ‘GPL과 관련되지 아니한 부분만 독립적으로 팔거나 배포하는 경우는 관계가 없다. 하지만 GPL 코드를 일부라도 사용한 프로그램 전체를 배포할 때에는 GPL을 적용(즉, 프로그램의 전체 소스코드 공개)해야 한다’는 말이겠네요.. 상당히 강도가 세군요..
기타 세부적인 내용에 대해서는 GPL 전문과 GPL FAQ를 참조하시면 좋습니다. 특히 GPL FAQ를 읽어보면 GPL을 이해하는데 도움이 많이 됩니다.
GPL 전문에 있는 ‘보통의 소프트웨어 라이센스들이 SW에 대한 공유와 수정의 자유를 제한하려는 목적을 가진 반면에 GPL은 공유와 수정의 자유를 보장하기 위한 규정이다’라는 말이 꽤나 인상적이네요..
2. GNU LGPL(Lesser General Public License)
LGPL은 GPL보다는 훨씬 완화된(lesser) 조건의 공개 소프트웨어 라이센스입니다.
가장 큰 차이점은 LGPL 코드를 정적(static) 또는 동적(dynamic) 라이브러리로 사용한 프로그램을 개발하여 판매/배포할 경우에 프로그램의 소스코드를 공개하지 않아도 된다는 점입니다. LGPL 코드를 사용했음을 명시만 하면 됩니다.
단, LGPL 코드를 단순히 이용하는 것이 아니라 이를 수정한 또는 이로부터 파생된 라이브러리를 개발하여 배포하는 경우에는 전체 코드를 공개해야 합니다.
3. BSD (Berkeley Software Distribution) License
소스코드 공개의 의무가 없으며 상용(상업적) 소프트웨어에서도 무제한 사용 가능한 라이센스라고 하는데.. 그렇다면 아무런 제한이 없는 라이센스라는 의미겠네요.
참고로 OpenCV는 BSD 라이센스를 따릅니다. GPL 정신에는 맞지 않겠지만 쓰는 사람 입장에서는 정말 편하네요..
4. MIT License
MIT license는 copyright와 license에 대한 정보만 표기하면 자유롭게 사용할 수 있는 라이센스인데, 상업적인사용, 배포, 수정 및 개인적인 사용이 모두 가능합니다. BSD와 MIT는 매우 유사한 조건이라고 볼 수 있을 것 같습니다.
GNU
문득 GNU는 무엇의 약자일까? 하는 궁금증이 생겨서 같이 찾아보았습니다.
“GNU’s Not Unix”의 약자라는군요. gnu는 unix가 아니다..
이런 것을 재귀약자라고 한다네요.
참고로 아프리카 영양중에 gnu(누~ 라고 발음)라는 것이 있는데, 이것과 구분하여 GNU는 ‘그누~’라고 발음한답니다. 그리고 GNU 홈페이지에 가보면 이 영양 머리모양을 마크로 하고 있음을 알 수 있습니다.
이미지 확장자에 대해 설명
오디오 컨테이너가 가장 기술적으로 잘 알려진 컨테이너라 하면 이미지 컨테이너는 가장 많이 사용되고 있는 컨테이너일 것이다. 윈도로 대표되는 GUI(Graphic User Interface) 기반의 OS와 웹브라우저 기반 인터넷이 대중화하고 보급되면서 인류의 디지털 라이프는 온갖 종류의 이미지로 채워지게 되었기 때문이다. 이처럼 우리의 생활과 매우 밀접한 존재이기 때문에 단순 소비를 위한 편의성에서는 오디오 컨테이너와 마찬가지로 거의 신경 쓸 필요 없이 일반적으로 사용되는 시스템에서 그대로 사용하면 된다. 하지만 오디오 컨테이너에 비해 사용되는 종류가 압도적으로 다양하며 당연히 이로 인해 호환성이 조금은 떨어지는 것은 사실이다.
동영상은 비슷한 정지 이미지의 연속이라는 점에서 이미지와 무관할 수 없으며 제한적이나마 이미지 시퀀스란 형태로 서로 호환되기도 하기 때문에 동영상 작업을 하는 작업자라도 정지 이미지에 대해 기본적인 내용은 숙지할 필요가 있다.
비트맵 이미지와 벡터 이미지
비트맵 이미지(bitmap image)는 전체 그림을 구성하는 픽셀 데이터의 배열을 통해 이미지를 형성 및 저장하는 방식으로, 대부분의 디지털 이미지가 사용하는 방식이다. 하지만 본래 규정된 크기 이상으로 확대하면 곡선과 대각선에서 앨리아싱(aliasing)이라 불리는 계단 현상이 일어날 수 있다. 반면 벡터 이미지(vector image)는 기준점에서 수학적인 벡터 좌표법으로 이미지를 형성 및 저장하는 방식으로, 수학적 계산에 근거한 상대좌표 데이터이기 때문에 확대 및 축소를 해도 이미지가 깨지는 현상이 없다. 하지만 이러한 특징 때문에 실사 사진에는 적합하지 못하다.
1. AI
가장 대표적인 벡터 드로잉 소프트웨어인 어도비 일러스트레이터(Adobe Illustrator)에서 사용하는 벡터 이미지를 저장하기 위한 파일 컨테이너로 ‘어도비 일러스트레이터’의 머리글자다. 대다수의 이미지 파일 컨테이너가 비트맵 방식인 것에 비해 상대적으로 그 사용량이 적은 벡터 방식이기 때문에 지원하는 하드웨어와 소프트웨어 역시 상대적으로 적다.
2. BMP
마이크로소프트에서 개발한 무손실 비트맵(bitmap) 이미지 파일 컨테이너로 윈도 시스템에서 주로 사용된다. 주로 반복 문자열 제거라는 압축 기법을 이용한 무손실 압축 상태로 사용되기 때문에 압축 효율은 그리 높지 못하다. 당연히 이미지 크기에 비해 용량이 매우 큰 편이라는 단점이 있지만 반대로 호환성은 매우 높다.
3. GIF
1987년 컴퓨서브(CompuServe)에서 발표한 무손실 압축, 인덱스 컬러 기반의 비트맵 이미지 파일 컨테이너로 그래픽스 인터체인지 포맷(Graphics Interchange Format)의 줄임말이다. 지원 가능한 색상이 최대 256색으로 제한되기 때문에 사진과 같이 색상이 많은 이미지가 원 소스인 경우 색상 부분에서 심각한 손실이 발생할 수 있기 때문에 권장하지 않는다. ‘애니메이션 GIF(Animation GIF)’로 만들면 동영상으로도 만들 수 있지만 오디오는 지원하지 않는다. GIF89a 형식은 단색 알파채널(alpha channel)을 지원하기 때문에 투명 배경을 지원한다.
4. JPG, JPEG, JPE, JFIF
합동사진전문가단체(JPEG, Joint Photographic Exports Group)에서 지정한 정지화상을 위한 표준으로 용량대비 화질이 뛰어나다. 현재 가장 많은 분야에서 가장 많이 사용되고 있는 손실 압축 기반의 비트맵 이미지 파일 컨테이너로 RGB 신호를 그대로 사용하지 않고 비디오에서 많이 사용하는 YCbCr 방식으로 변환해 처리하는 것이 특징이다. 하지만 이러한 특성 때문에 화질 설정을 최대치로 설정해도 RGB와 YCbCr를 오가며 변환하는 과정에서 미미하지만 이미지 손상이 발생하며 수정을 반복하면 할수록 화질 손상이 증폭된다는 단점이 있기 때문에 작업용으로 사용할 때는 주의해야만 한다.
5. JP2, J2C
JPEG보다 화질과 압축률을 모두 향상시키는 것은 물론 JPEG에서 불가능했던 무손실 압축도 지원하는 개량형인 JPEG2000이 사용하는 파일 컨테이너지로 웨이블릿 변환이란 기술을 사용한다. 기술적으로는 많은 발전을 이루었으나 지원하는 장비와 소프트웨어는 적은 상황이다.
6. PCX
제트소프트(Zsoft)에서 개발한 무손실 압축 비트맵 이미지 파일 컨테이너로 도스(DOS) 기반의 페인트브러시(Paint Brush)라는 비트맵 이미지 제작 소프트웨어에서 작업한 이미지를 저장하기 위해 만들어졌다. PCX(Personal Computer eXchange)는 주로 인덱스 컬러 모드로 사용되지만 트루 컬러 모드도 지원한다. 도스와 윈도 95가 주로 사용되던 무렵까지 높은 호환성을 바탕으로 많이 사용되었으나 인터넷이 대중화되는 시점을 기준으로 뒤 이어 나온 GIF와 JPEG, PNG에 밀려 지금은 거의 사용되지 않는다.
7. PNG
PNG(Portable Network Graphics)는 W3C(World Wide Web Consortium)에서 GIF의 법적인 문제와 단점을 극복하기 개발된 무손실 압축 비트맵 이미지 파일 컨테이너로 트루 컬러와 8비트 알파채널을 지원하면서 대부분 GIF보다 좋은 압축률을 보여 준다. 하지만 GIF처럼 애니메이션은 지원하지 않는다. 무손실 압축을 사용하기 때문에 JPEG보다는 압축 효율이 나쁘기 때문에 일반적으로 더 큰 용량을 갖게 된다.
8. PSD
어도비 포토샵(Adobe Photoshop)에서 사용하는 비트맵 이미지 파일 컨테이너로 ‘포토샵 도큐멘트(photoshop document)’의 줄임말이다. 마스크(mask), 레이어(layer)와 알파채널 등 이미지 파일로서는 매우 다양한 기능들을 지원하면서 무손실 압축을 사용한다. 대신 그만큼 용량이 크기 때문에 최종본이 아닌 작업이 진행되고 있는 데이터의 저장용으로 주로 사용한다.
9. TGA, TAGA
트루비전(Truevision)에서 개발한 무손실 압축 기반의 비트맵 이미지 파일 컨테이너로 알파채널도 지원해 자막파일과 동영상 프레임을 각각의 연속된 이미지 파일로 만들어 사용하는 이미지 시퀀스에서 많이 사용된다.
TGA로 이뤄진 이미지 시퀀스(image sequence)를 ‘타가 시퀀스’라고 부른다. 타가(TARGA)는 ‘트루비전 어드밴스드 래스터 그래픽스 어댑터(Truevision advanced raster graphics adapter)’의 줄임말이다. 압축률은 그리 좋지 못해서 저장용량을 많이 차지하지만 맥, 윈도, 리눅스는 물론 매우 다양한 OS에서 사용할 수 있기 때문에 거의 모든 컴퓨터 기반의 영상 장비에서 지원한다는 장점이 있다.
10. TIF
앨더스(Aldus)와 마이크로소프트가 스캐너용으로 공동 개발한 비트맵 이미지 파일 컨테이너로 ‘태그드 이미지 파일 포맷(Tagged Image File Format)’의 줄임말이다. 무압축은 물론 다양한 압축률을 선택할 수 있으나 압축 방식을 사용하면 구형 이미지 뷰어에서 정상적으로 인식되지 않는 경우도 있기 때문에 사용에 주의가 필요하다. 포토샵의 PSD처럼 레이어도 지원한다. 등장 시기는 PCX와 비슷하지만 아직까지도 꾸준히 사용되고 있는 규격이다.
Markdown을 이용하여 포스팅 시 HTML 코드를 그대로 포스팅하는 방법
Jekyll을 이용하여 포스팅을 하면서 코드를 올리는 경우가 종종 있다. C 나 python 혹은 기타 코드를 code block에 넣으면 코드가 그대로 보이지만 HTML을 넣을 경우 실제 데이터로 convert가 되어 표기가 되어 원하는 코드를 재대로 보여줄 수 없다. 이때는 code block에 { % raw % } 와 { % endraw % }를 넣어줌으로써 code의 raw를 변환없이 아래와 같이 포스팅 할 수 있다. 실제 입력 시 { 와 % 사이에는 공백이 없어야 한다.
---
layout: default_post
---
<article class="post" itemscope itemtype="http://schema.org/BlogPosting">
<header class="post-header single-post-header" style="background-image:url('{{ site.url }}{{ page.image }}')">
<div>
<h1 class="post-title single-post-title" itemprop="name headline">{{ page.title }}</h1>
<p class="post-meta single-post-meta">
<time datetime="{{ page.date | date_to_xmlschema }}" itemprop="datePublished">{{ page.date | date_to_long_string }}</time>
•
{% assign words = page.content | number_of_words %}
{% if words < 360 %}
1 min
{% else %}
{{ words | divided_by:180 }} mins
{% endif %}
read
</p>
</div>
</header>
<div class="wrapper">
<div class="single-post-summary">
<code> {{ page.summary }} </code>
</div>
<div class="post-content single-post-content" itemprop="articleBody">
<code> {{ content }} </code>
</div>
{% if page.comments %}
<-- add your code here -->
{% endif %}
</div>
</article>
우분투 14.04에서 NTFS형식으로 되어있는 윈도우 파티션을 자동 마운트 하는 방법 소개
윈도우 파티션의 파일시스템은 NTFS(New Technology File System)으로 보통 구성되어 있다. 예전에는 Ubuntu에서 NTFS 시스템을 읽거나 사용하기 어려웠는데 근래에는 Reverse Engineering을 통해 Ubuntu에서도 사용 가능할 수 있게 되었다. 기본적으로 가장 오래된 시스템은 FAT(File Allocate Table)이며 안정성 면에서는 FAT32가 가장 좋다. 하지만 FAT32는 32bit 시스템을 사용하기 떄문에 4Gbyte 이상의 파일을 저장할 수 없다. 왜냐하면 32bit 방식은 표현할 수 있는 주소의 갯수가 2의 32승 = 4.2950e+09 이고 한개의 주소값으로 1Byte를 표현 할 수 있으므로 32bit 시스템으로 표현할 수 있는 최대 메모리는 4.2950e+09 Byte, 약 4GByte이다. 마찬가지로 32bit 운영체제에서 최대 사용가능한 메모리 용량이 4GByte인것도 같은 이유이다. 32bit 시스템에서 4GByte이상의 하드디스크를 사용할 수 있는 것은 하드시스크의 data를 RAM으로 이동 후 처리하기 때문에 가능한 것이다. 이러한 한계 때문에 개발 된 것이 exFAT시스템이다. exFAT시스템은 용량의 제한이 매우 커서 따로 신경쓸 필요가 없다. 하지만 exFAT 시스템으로 설정된 USB 및 디스크를 안전하게 제거하지 않는다거나 여러 경우에 불안한 모습을 보일 때가 있다고 한다. 마지막으로 NTFS 방식은 Windows에서 개발된 방식이기 때문에 블랙박스라던지 기타 디바이스에서 인식이 안되는 문제가 있다고 한다.
다시한번 정리하면
FAT32 : 안전성에서는 가장 좋음, 저장 용량의 한계가 있음
exFAT : 안정성이 떨어짐, 저장용량의 한계는 없음
NTFS: 확장성이 떨어짐
따라서 디스크 포멧 시 본인의 맞는 방식에 맞춰서 사용하면 된다. 기본적으로 Windows가 설치된 디스크는 NTFS 방식으로 되어 있기 때문에, 윈도우가 설치된 디스크를 Ubuntu에 자동으로 mount 시키기 위해서는 다음과 같은 절차가 필요하다.
1. directory 생성
우선 원하는 위치에 directory를 설정한다.
2. fstab file수정
/etc 경로의 fstab file을 수정한다.
우선 fstab file을 열고 다음을 추가한다.
UUID=16D219F9D219DE35 /media/win ntfs auto,defaults,rw 0 2
또는
/dev/sda1 /media/win ntfs-3g auto,defaults,rw 0 2
위의 두가지 방식으로 설정 가능하다(device 이름 혹은 UUID)
/media/win : mount 위치
ntfs-3g : file type
rw : read and write
fstab까지 설정이 완료 후 재부팅하면 windows의 파티션이 자동으로 mount되는 것을 확인 가능하다.
추가
어느순간 잘 되다가 윈도우 파티션을 mount할 수 없다고 뜨는 경우가 있다. 이런경우는 종종 윈도우가 정상적으로 종료되지 않았을 경우이기 때문에 윈도우로 갔다가 돌아오면 정상적으로 mount가 되는데, 한번씩 윈도우 파티션이 hibernated 파티션이라고 뜨면서 안되는 경우가 있다. 이런경우에는 윈도우를 켰다가 끄고 재 접속을 해도 auto mount가 되지 않는다. 이런경우는 위의 설정은 변경하지 않고 아래의 명령어를 이용하여 hibernated를 풀어주면 된다.
sudo mount -t ntfs-3g -o remove_hiberfile /dev/sda1 /media/win
그래도 안되는 경우에는 Window에서 hibernate 옵션을 강제로 꺼준다. 윈도우를 키고 cmd 창을 관리자 모드로 실행 시킨 후 다음 명령어를 실행시킨다.
