오픈 소스를 공개 할 계획 인 Java로 작성된 유용한 유틸리티의 작은 유틸리티 라이브러리가 있습니다. 어떤 라이센스를 사용할지 고민하고 있습니다. 나는 짧고 이해하기 쉬운 BSD 라이센스를 좋아 하지만 제품 설명서에 고지 사항을 포함시키는 것에 대한 조항을 원하지 않습니다. 그 비트를 버리는 것을 고려하십시오.
그렇다면 MIT 라이센스가 더 적합할까요? BSD와 같은 보증 금지 조항이 없습니다. BSD에 대해 좋아하는 것입니다. 또한 소프트웨어의 상당 부분에 대한 저작권 고지를 유지하는 것에 관한 MIT의 조항은 바이너리 형식이나 제작 한 문서가 아닌 소스 코드만을 참조합니까?
주제에 대한 다른 SO 질문을 조사한 결과 소수의 사람들이 Apache 라이센스를 추천하는 것을 보았습니다 . 그래도 빠른 스캔을하면 실제로 원하는 것을 대부분 잘 수행 할 수 있지만, 그 정도의 합법적 인 사람들조차도 머리를 아프게합니다 (특히 오전 2시 30 분에 SO 대신 침대에 있어야 할 때 ).
기본적으로 나는 다음과 같은 것을 원합니다.
- 이해하기 쉬운,
- 원하는대로 코드를 사용할 수 있지만 소스 코드에 대한 저작권 및 권한 고지를 유지하십시오.
- 귀하는 귀하가 생산하는 문서, 매뉴얼 등에 본인 또는 제 제품의 이름 또는 저작권 고지 사항 등을 기재 할 필요가 없습니다.
- 나 또는 내 제품을 귀하의 제품에 대한 판매 지점으로 사용하려고 시도하지 마십시오 (어쨌든 내 보증은 그다지 중요하지 않습니다!)
- 그리고 내 엉덩이를 합리적으로 덮습니다. :-)
편집 : 와우, 30 분 및 이미 좋은 반응! 답으로:
도움이된다면 "혼합과 일치"를하지 않고 또 다른 오픈 소스 라이센스를 생성하고 싶습니다 . 표준 라이센스를 사용하면 우리 모두가 더 쉬워집니다.
엉덩이 취재 코멘트는 약간 혀입니다. 언급 된 모든 라이센스에 포함 된 보증 면책 조항은 제가 말하는 것입니다.
편집 : MIT 라이센스 의 Wikipedia 페이지를 읽은 결과 , ncurses 가 FSF 가 승인 한 수정 버전을 사용하여 보증하지 않는 단락을 추가 한다는 것을 알았습니다 . 나는 그것이 그들에게 충분하다면 나에게 충분하다고 생각합니다.
Apache 라이센스를 고려하고 있었지만 GPLv2 와의 호환성 문제 는 소개하고 싶지 않은 문제였습니다.