기본 콘텐츠로 건너뛰기

오픈소스 라이센스

*이하 설명하고 있는 오픈소스 라이선스는 소스코드에 적용되는 라이선스이며 일반적으로 소스코드에 대한 문서나 콘텐츠에 대한 라이선스는 CCL 등 별도의 라이선스를 적용합니다.

라이선스 종류

  • Apache License

    – 아파치 라이선스는 아파치소프트웨어재단이 자기네 SW에 적용하기 위해 자체적으로 만든 라이선스다. 소스코드 공개 의무 같은 의무사항은 없지만, 아파치 라이선스 소스코드를 수정해 배포하는 경우 아파치 라이선스 버전 2.0을 꼭 포함시켜야 하며 아파치재단에서 만든 소프트웨어임을 밝혀야 한다.
    – 적용 사례 : 안드로이드(v2.0), 하둡(v2.0)
  • GNU(Gnu is Not Unix) General Public License(GPL)

    – 자유소프트웨어재단에서 만든 라이선스다. GNU 프로젝트로 배포하는 소프트웨어(Emacs, GNU 디버거(GDB), GNU 컴파일러 모음(GCC) 등)에 적용하기 위해 리처드 스톨만이 만들었다. 가장 큰 특징은 자유소프트웨어재단답게 가장 강력한 제약 조건을 포함하고 있는 카피레프트 조항이다. GPL 프로그램은 어떤 목적으로, 어떤 형태로든 사용할 수 있지만 사용하거나 변경된 프로그램을 배포하는 경우 무조건 동일한 라이선스 즉, GPL로 공개해야 한다.
    – 적용 사례 : 모질라 파이어폭스(v2.0), 리눅스 커널(v2.0), (v2.0), 마리아DB(v2.0), 워드프레스(v2.0), 드루팔(v2.0)
  • GNU Affero GPL(AGPL)

    – GPL을 기반으로 만든 라이선스로 버전1, 2는 아페로, 가장 최신 버전인 버전3은 자유소프트웨어재단에 의해 개발됐다. 수정한 소스코드를 서버에서만 사용하는 개발자가 그 프로그램을 배포하지 않을 경우 사용자는 소스코드를 가질 수가 없는 문제를 해결하기 위해 마련됐다. 서버에서 프로그램을 실행해 다른 사용자들과 통신하면, 실행되고 있는 프로그램의 소스코드를 사용자들이 다운로드할 수 있게 해야 한다는 독특한 조항을 담고 있다.
    – 적용 사례 : 몽고DB(v3.0)
  • GNU Lesser GPL(LGPL)

    – 자유소프트웨어재단의 강력한 철학이 담긴 GPL의 카피레프트 조항을 보완하기 위해 만든 라이선스다. GPL은 단순히 소프트웨어를 사용하기만 하더라도 해당 소스코드를 GPL로 공개해야 하는 부담감 때문에 상용 소프트웨어로 쓰기 부담스럽다는 단점이 있다. 그래서 좋은 자유 소프트웨어 제품이 더 많이 쓰이고 표준이 되도록 유도하기 위해 단순한 라이브러리·모듈 링크를 허용한 라이선스이다. 원래는 한정된 라이브러리에만 적용하려는 의도로 ‘Library GPL’이라는 이름을 붙였으나, 모든 라이브러리에 적용된다는 오해를 사 ‘Lesser GPL’로 변경됐다.
    – 적용 사례 : 모질라 파이어폭스(v2.1)
  • MIT License

    – MIT 라이선스는 미국 매사추세츠공과대학교(MIT)에서 해당 대학 SW 공학도들을 돕기 위해 개발한 라이선스다. 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스로, 가장 느슨한 조건을 가진 라이선스 중 하나이기 때문에 인기가 많다.
    – 적용 사례 : 부트스트랩 , Angular.jsBackbone.jsjQuery
  • Artistic License

    – 펄 프로그래밍 언어를 사용하던 래리 월이 표준 펄 기능을 위해 만든 라이선스다. 이 단어의 어원은 문학에서 문법상 틀린 표현이라도 시적인 효과를 위해 허용한다는 걸 의미하는 ‘Articstic License'(시적 허용)를 참조해 만들어졌다.
    – 적용 사례 : NPM(Node Package Manager)(v2.0)
  • Eclipse License

    – 이클립스사에서 비즈니스 환경에 적합하도록 만든 기업 친화적인 라이선스로, 강력한 카피레프트 조항이 담긴 GPL보다 제약 조건이 완화된 라이선스이다.
    – 적용 사례 : 이클립스(v1.0)
  • Berkeley Software Distribution(BSD) License

    – 버클리의 캘리포니아대학에서 배포하는 공개 SW 라이선스다. BSD 자체가 공공기관에서 만들어낸 것이므로 공공의 몫으로 돌려주자는 의미가 강하므로, 라이선스 자체에는 아무런 제한 없이 누구나 자신의 용도로 사용할 수 있다. 라이선스 및 저작권 표시 조건 외엔 제약이 없는, 굉장히 자유로운 라이선스 중 하나이다.
    – 적용 사례 : Nginx(The BSD 2-Clause License)
  • Mozilla Public License(MPL)

    – 모질라 공용 허가서는 과거 넷스케이프 웹브라우저의 소스코드를 공개하기 위해 개발된 라이선스다. 초기 1.0버전은 넷스케이프 커뮤니케이션의 변호사였던 밋첼 베이커가 작성했고, 1.1과 2.0버전은 모질라재단이 작성했다. MPL의 특징은 소스코드와 실행파일의 저작권을 분리했다는 점이다. 수정한 소스코드는 MPL로 공개하고 원저작자에게 수정한 부분에 대해 알려야 하지만, 실행파일은 독점 라이선스로 배포할 수 있다. 즉 사용한 MPL 소프트웨어와 수정한 MPL 소프트웨어에 대한 공개 의무만 가지며, 별도의 소스코드와 실행파일은 독점 라이선스를 가질 수 있다.
    – 적용 사례 : 모질라 파이어폭스(v1.1), 모질라 썬더버드(v1.1)

조건표

라이선스필수 사항(Required)허락 조건(Permitted)금지 조건(Forbidden)
Apache License
제약조건:하
  • 라이선스 및 저작권 명시
  • 변경사항 안내
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 특허 신청 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
  • 상표권 침해 금지
GPL
v2.0/v3.0
제약조건:상
  • 수정한 소스코드 혹은 GPL 소스코드를 활용한 소프트웨어 모두 GPL로 공개
  • 라이선스 및 저작권 명시
  • 변경사항 안내
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 특허 신청 가능
  • 사적 이용 가능
  • 보증책임 없음
  • 2차 라이선스
GNU AGPL
(Affero GPL)
v3.0
제약조건:최상
  • 수정한 소스코드 혹은 AGPL 소스코드를 활용한 소프트웨어 모두 AGPL로 공개
  • 라이선스 및 저작권 명시
  • 변경사항 안내
  • 네트워크상 소프트웨어 사용자에게 소스코드 공개
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 특허 신청 가능
  • 사적 이용 가능
  • 보증책임 없음
  • 2차 라이선스
GNU LGPL
(Lesser GPL)
v2.1/v3.0
제약조건:중
  • 수정한 소스코드 LGPL로 공개(단순 활용시 공개 의무 없음)
  • 라이선스 및 저작권 명시
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 특허 신청 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
MIT
License
제약조건:하
  • 라이선스 및 저작권 명시
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
Artistic
License
제약조건:하
  • 라이선스 및 저작권 명시
  • 변경사항 안내
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
  • 상표권 침해 금지
Eclipse
License
제약조건:중
  • 수정한 소스코드 Eclipse로 공개(단순 활용시 공개 의무 없음)
  • 라이선스 및 저작권 명시
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 특허 신청 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
BSD
License
제약조건:하
  • 라이선스 및 저작권 명시
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
MPL v2.0
(Mozilla Public License)
제약조건:중
  • 수정한 소스코드 MPL로 공개(단순 활용시 공개 의무 없음)
  • 라이선스 및 저작권 명시
  • 특허기술이 구현된 프로그램의 경우 관련 사실을 ‘LEGAL’파일에 기록하여 배포
  • 상업적 이용 가능
  • 배포 가능
  • 수정 가능
  • 특허 신청 가능
  • 사적 이용 가능
  • 2차 라이선스
  • 보증책임 없음
  • 상표권 침해 금지
Beerware
제약조건: 최하
  • 맥주 사주기
뭐가 이리 복잡해! 그냥 나중에 만나면 맥주나 한 잔 사줘! – Beerware License 적용하기. CC BY-NC-SA, Image from @slworking2 – https://flic.kr/p/bEj5mo

댓글

이 블로그의 인기 게시물

유닉스 & 리눅스 가계도. Unix&Linux Family

- Unix Family - Shell History

라즈베리파이 커널 컴파일

- 라즈베리파이의 부트절차 1. Power on 2. SoC Rom의 첫번째 부트로더(Firmware)을 읽음. 3. 첫번째 부트로더가 MicroSD의 두번째 부트로더( bootcode.bin )을 호출 4. 두번째 부트로더가 MicroSD의 config.txt 파일을 읽고 실행. 5. 두번째 부트로더가 세번째 부트로더 ( start.elf )을 호출 실행 ARM core 활성화 6. ARM core가 네번째 부트로더( kernel.img )을 호출 실행 7. module load 8. init 실행 (daemon 실행) 부팅에 필요한 최소한의 세가지 : bootcode.bin, start.elf(start_cd.elf / start_x.elf), kernel.img - 라즈베리파이 커널 크로스 컴파일 - 커널 소스 내려받기 : 커널 소스가 필요한 이유? 임베디드 환경에 맞게 커널을 축소하기 위해서. git : sw 버전관리& 페키지를 쉽게 다운받기 위해 사용. #atp-get install git -y #git init #mkdir /raspberrypi 필요한 커널 소스 다운 및 크로스컴파일러 다운. : www.kernel.org 에서도 다운 가능. #cd /raspberrypi #apt-get update #apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libc6-dev-i386 lib32z1 #git clone --depth=1 https://github.com/raspberrypi/linux #export KERNEL=kernel7 make를 이용해 크로스 컴파일 시켜줌. #apt-get install gcc-arm-linux-gnueabi make #cd linux #make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2709_

모든 프로그래머가 알아야 할 것들 목록.

Every Programmer Should Know Algorithms Big O Cheatsheet 📖   Grokking Algorithms Sorting Algorithms Numbers 📄   Floating Point Guide 📄   Basic Number Theory Every Programmer Should Know... 📄   Falsehoods Programmers Believe About Phone Numbers Strings Big List of Naughty Strings 📄   Unicode and Character Sets Homoglyphs Unicode Common Locale Data Repository Falsehoods Programmers Believe About Names Latency Interactive Latency Infographics 📄   Latency Numbers Every Programmer Should Know Time 📄   Falsehoods programmers believe about time 📄   More falsehoods programmers believe about time; “wisdom of the crowd” edition 📄   Some notes about time 📄   Falsehoods programmers believe about time and time zones Memory 📄   What every Programmer should know about memory Distributed Systems 📖   Designing Data-Intensive Applications 📜   Designs, Lessons and Advice from Building Large Distributed Systems 📜   Time, Clocks and the Orderi