허가 소프트웨어 라이선스

Permissive software license

허용 소프트웨어 라이센스는 BSD 유사 라이선스 또는 BSD 스타일 [1]라이선스라고도 불리며 카피레프트 보호 대신 소프트웨어의 사용, 변경 및 재배포 방법에 대한 최소한의 제한만 수반하는 자유 소프트웨어 라이선스입니다.보통 보증 면책 사항도 포함됩니다.예를 들어 GNU All-permitive License, MIT License, BSD License, Apple Public Source License, Apache License 등이 있습니다.2016년 현재 가장 인기 있는 자유 소프트웨어 라이센스는 허용 MIT [2][3]라이센스입니다.

퍼블릭 도메인 및 동등한 것 허가 라이선스 카피레프트(보호 라이선스) 비상업 라이선스 소유권 라이선스 영업비밀
묘사 모든 권한을 부여합니다. 잔존권 등 사용권 부여(소유권 부여, 라이선스 호환성 허용) 사용 권한 부여, 소유 금지 비상업적인 용도로만 권한을 부여합니다.카피레프트와 결합될 수 있습니다. 저작권의 종래의 사용.권 공개된 정보 없음
소프트웨어 PD, CC0 BSD, MIT, Apache GPL, AGPL JRL, AFPL 전용 소프트웨어, 퍼블릭라이선스 없음 프라이빗, 내부 소프트웨어
기타 크리에이티브 작품 PD, CC0 참조 CC-BY-SA CC-BY-NC 저작권, 퍼블릭 라이선스 없음 미공개

다음은 간단한 GNU All-permitive License 전문입니다.

저작권 <YEAR>, <AUTHORTS>

저작권 공지와 이 공지가 유지되는 한, 이 파일의 복사 및 배포는 변경 여부와 관계없이 로열티 없이 모든 매체에서 허용됩니다.이 파일은 보증 없이 그대로 제공됩니다.

--

정의들

오픈 소스 이니셔티브에서는 허용 소프트웨어 라이선스를 "사용, 변경 및 재배포의 자유를 보장하는 [6]비복사 라이선스"로 정의하고 있습니다.GitHubselecticense 웹사이트는 허용적인 MIT 라이선스를 "사람들이 당신의 코드로 원하는 것은 무엇이든 할 수 있도록 허락한다"고 설명하고 [7]있다.California Western School of Law's newmediarights.com은 다음과 같이 정의했습니다. "BSD, MIT 및 Apache 라이센스와 같은 'BSD와 유사한' 라이센스는 매우 관대하며 라이센스 코드 중 원래 부분을 자체 코드 [1]및/또는 문서에 있는 개발자에게 귀속시키는 것만으로 충분합니다."

카피레프트와의 비교

일반적으로 카피레프트 라이선스는 원본 저작물의 카피레프트 [8][9]라이선스에 따라 수정된 버전의 소스 코드를 상호 공개해야 합니다.이와는 대조적으로 허가 라이선스는 수정된 버전의 소프트웨어가 무료이고 공개적으로 이용 가능한 상태로 유지되도록 보장하지 않으며, 일반적으로 원본 저작권 고지만 [1]유지하면 됩니다.그 결과, 불법 라이선스를 취득한 소프트웨어의 파생 저작물 또는 향후 버전을 독점 [10]소프트웨어로 출시할 수 있습니다.

그러나 라이선스의 자유도를 정의하는 것은 쉽게 수량화할 수 없으며 최종 사용자의 목표에 따라 좌우되는 경우가 많습니다.만약 후자의 있는 개발 업자들, 어떤 사람은의 권리를 박탈하면서 다른 개발자들에 더 많은 그 혹 아는 것이 귀중할지도 모르고 이용하고 독점적 코드로, 그것과 함께 돈을 버가 소스 코드 다른 사람들에 의해 쓰여진(에 이러한 그들에게"바로"제공하는 등 관대한 면허를 참조하십시오)[11]을 수정할 수 있는 중요할 수 있다.ody님은, 지금까지의 대부분의 작업을 자본화할 것입니다(따라서, 카피레프트 라이센스는 「권리」를 제공하는 것으로 간주됩니다).또한 최종 사용자는 개발자가 아닐 수 있습니다.또한 이 경우 카피레프트 라이선스는 소프트웨어를 자유 소프트웨어로 액세스할 수 있는 영속적인 권리를 제공합니다.또한 이 라이선스는 개발자가 아닌 최종 사용자에게 전혀 권리를 제공하지 않으며 소프트웨어도 허용 라이선스로 출시됩니다.ld는 이론적으로 사용자가 알지 못하는 사이에 폐쇄적인 소스 멀웨어가 됩니다.

허용 라이선스는 카피레프트 라이선스보다 광범위한 라이선스 호환성을 제공합니다.카피레프트 라이선스는 상호 요건이 서로 [12][13][14][15][16]상충하기 때문에 일반적으로 자유롭게 조합하거나 혼합할 수 없습니다.

퍼블릭 도메인과의 비교

Computer Associates Int'l v. Altai는 퍼블릭 도메인에 의도적으로 들어간 작업이 아니라 허가 하에 널리 공유되고 배포된 작업을 지칭하기 위해 "퍼블릭 도메인"이라는 용어를 사용했습니다.그러나 허용 라이선스는 실제로 퍼블릭도메인에 저작물을 공개하는 것과 동등하지 않습니다.

허가 라이선스는 종종 원저작자(속성)를 인정해야 하는 것과 같은 몇 가지 제한된 요건을 규정한다.저작물이 실제로 공공영역에 있는 경우, 이는 일반적으로 법적으로 요구되지 않지만, 미국의 저작권 등록은 [17]이전에 공개된 자료를 공개해야 하며, 학계에서 귀속은 여전히 윤리적 요구로 간주될 수 있다.

허가 라이선스를 옹호하는 사람들은 일부 [18][19]국가에서는 법적으로 문제가 될 수 있다는 이유로 소프트웨어를 공용 도메인에 공개하지 말 것을 권장합니다.퍼블릭 도메인에 상당하는 라이선스는 이 문제를 해결하기 위한 시도입니다.법적으로 저작권의 포기가 불가능한 경우에 대해 폴백 허용 라이선스를 제공하고, 경우에 따라서는 대부분의 허용 라이선스와 유사한 보증에 대한 거부도 포함합니다.

라이선스 호환성

David A에 따르면 공통 자유 소프트웨어(FOSS) 라이센스와 오픈 소스 소프트웨어(FOSS) 라이센스 간의 라이센스 호환성.Wheeler (2007) : 벡터 화살표는 단방향 호환성을 나타내므로 오른쪽('복사 라이선스')보다 왼쪽('허용 라이선스')[20]의 호환성이 우수합니다.

일반적으로 허가 라이선스는 대부분의 [12][13]경우 다른 소프트웨어 라이선스와 호환성이 우수합니다.

이러한 제한이 없기 때문에 대부분의 허용 소프트웨어 라이센스는 다른 대부분의 라이센스와 호환되지 않는 카피레프트 라이센스와도 호환됩니다.4절 BSD 라이선스, PHP 라이선스, OpenSSL 라이선스 등 일부 오래된 허가 라이선스에는 저작권자의 신용을 보증하는 광고 자료가 필요한 조항이 있어 카피레프트 라이선스와 호환되지 않습니다.단, MIT 라이선스, 3절 BSD 라이선스, zlib 라이선스 등 일반적인 현대의 허가 라이선스는 광고 조항이 포함되어 있지 않으며 일반적으로 카피레프트 라이선스와 호환성이 있습니다.

일부 라이선스는 파생된 작업에 재배포자가 제한을 추가할 수 없음을 나타내는 제한을 추가하는 것을 허용하지 않습니다.를 들어 CDDL과 MsPL이 있습니다.그러나 이러한 제한으로 인해 라이선스는 허용되는 자유 소프트웨어 [citation needed]라이선스와 호환되지 않습니다.

접수 및 도입

1980년대 [21]중반부터 사용되었지만, 일부 [22][23][24][25]저자는 2010년대 동안 허가 라이선스의 인기가 증가했다고 지적했다.

2015년 현재, 허용 라이선스인 MIT 라이선스가 가장 인기 있는 자유 소프트웨어 라이선스이며, GPLv2가 [2][3]그 뒤를 잇고 있습니다.

기타 조건

버클리에는 '카피 센터'라는 것이 있었는데, 그것은 '카피 센터로 가져가서 원하는 만큼 많은 복사본을 만든다'는 것입니다.

--

복사 센터

Copycenter수정된 BSD 라이센스, 즉 허용되는 자유 소프트웨어 라이센스를 설명하기 위해 원래 사용된 용어입니다.이 용어는 컴퓨터 사이언티스트이자 버클리 소프트웨어 배포(BSD)의 기고가인 Marshall Kirk McKusick의해 1999년 BSD 컨퍼런스에서 발표되었습니다.저작권, 카피레프트, [26][27]카피센터관한 단어장난이다.

푸슈버 라이선스

Richard Stallman은 라이선스 호환성 및 잔존성에 관한 Free Software Foundation의 가이드에서 허용 라이선스를 "푸셔버 라이선스"로 정의하며 "아니오"라고 말할 수 없는 라이선스와 비교합니다.이는 라이선스가 [28]"다른 사람에게 자유를 거부할 권리"를 부여하는 것으로 간주되기 때문입니다.Foundation은 300줄 미만의 소규모 프로그램에만 쉽게 라이선스를 사용할 수 있도록 권장하고 있습니다.이 프로그램에서는 일반적으로 카피레프트가 제공하는 이점이 너무 작아서 라이선스의 복사본을 항상 소프트웨어에 첨부해야 하는 불편함을 정당화할 수 없습니다.[29]

Cuck 라이선스

(아내와 바람을 피워는 유사성 정확하게에서)[32][를 표창 필요한]으로 그들이 기업 bene고 싶어 어떻게 인식하는 개발자들에 카피 레프트 라이선스에서 관대한 사람들에게 유리하게 움직이도록 압력을 가하는 기업에 대해 일부 개발 업체들이"cuck 면허"[30][검증 실패한][31일][신뢰할 수 없는 공급원인가?]란 가지고 있다.공동 연구에서 아무지 않습니다 하지 않고 이익을 민영화를 씌우라ck.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c New Media Rights (2008-09-12). "Open Source Licensing Guide". California Western School of Law.
  2. ^ a b "Top 20 licenses". Black Duck Software. 19 November 2015. Archived from the original on 19 July 2016. Retrieved 19 November 2015. 1. MIT license 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-clause, New or Revised) License 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public License 2%, 10. Eclipse Public License (EPL) 2%
  3. ^ a b Balter, Ben (2015-03-09). "Open source license usage on GitHub.com". github.com. Retrieved 2015-11-21. "1 MIT 44.69%, 2 Other 15.68%, 3 GPLv2 12.96%, 4 Apache 11.19%, 5 GPLv3 8.88%, 6 BSD 3-clause 4.53%, 7 Unlicense 1.87%, 8 BSD 2-clause 1.70%, 9 LGPLv3 1.30%, 10 AGPLv3 1.05%
  4. ^ 자유 소프트웨어 재단, 다양한 라이선스와 코멘트, GNU All-permitive License
  5. ^ GNU 소프트웨어 관리자에 대한 정보, 기타 파일에 대한 라이센스 알림
  6. ^ opensource.org에 대한 허용 "허용" 라이센스는 단순히 비복사 오픈 소스 라이센스로, 사용, 수정 및 재배포의 자유를 보장하지만 소유권 파생상품은 허용됩니다."
  7. ^ choosealicense.com에서 오픈 소스 라이선스를 선택하는 이 두려울 필요는 없습니다.다음 중 귀사의 상황을 가장 잘 설명한 것은 무엇입니까?- 단순하고 관대한 것을 원합니다."
  8. ^ "What is Copyleft". GNU. Retrieved 21 April 2011.
  9. ^ "Categories of free and nonfree software". gnu.org.
  10. ^ Amadeo, Ron (21 July 2018). "Google's iron grip on Android: Controlling open source by any means necessary". Ars Technica.
  11. ^ 점을 염두에 두고 FreeB는SD프로젝트는 기업 및 상업용 사용 사례에 대한 허용 라이선스를 옹호하고 있습니다.이러한 프로젝트에서는, 기업은 「미래의 행동에 최소한의 제한」만을 부과하고 있습니다.또, 카피레프트 라이센스는 「법적 시한폭탄이라고 주장하고 있습니다.참고 Montague브루스(2013-11-13)."왜 당신의 오픈 소스 프로젝트를 위해 BSD형 라이선스를 사용해야 하".FreeBSD의.2015-11-28. 9.GPL변화와 요인 분석과 단점으로는[..]12Retrieved.결론GPL은 오픈 소스 코드의 독점적 상업화 막기 위한 것이다에 대조적으로, BSD라이센스의 미래 행동에 최소한의 제한을 두고 있습니다.로 프로젝트나 회사의 요구 변화 이 BSD코드로 계속 오픈 소스 또는 상업적인 해결책들로 통합될 수 있습니다.다시 말하면 개발 과정에는 어떤 지점에서, BSD라이센스 되지 않는 법적 time-bomb.이후 BSD라이선스는 GPL또는 LGPL 면허 법적 복잡성과 오지 않는다 게다가, 만약 코드가 허가를 침해하는 개발자와 회사를 증진시키고보다는 걱정하는 좋은 소스 코드를 만들며 시간을 보낼 수 있습니다.
  12. ^ a b "Licence Compatibility". European Union Public Licence. joinup.ec.europa.eu. Archived from the original on 2015-06-17. Retrieved 2015-05-30. The licenses for distributing free or open source software (FOSS) are divided in two families: permissive and copyleft. Permissive licenses (BSD, MIT, X11, Apache, Zope) are generally compatible and interoperable with most other licenses, tolerating to merge, combine or improve the covered code and to re-distribute it under many licenses (including non-free or “proprietary”).
  13. ^ a b Hanwell, Marcus D. (2014-01-28). "Should I use a permissive license? Copyleft? Or something in the middle?". opensource.com. Retrieved 2015-05-30. Permissive licensing simplifies things One reason the business world, and more and more developers [...], favor permissive licenses is in the simplicity of reuse. The license usually only pertains to the source code that is licensed and makes no attempt to infer any conditions upon any other component, and because of this there is no need to define what constitutes a derived work. I have also never seen a license compatibility chart for permissive licenses; it seems that they are all compatible.
  14. ^ "Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?". gnu.org. Retrieved 2014-06-03. No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2. However, if code is released under GPL "version 2 or later," that is compatible with GPLv3 because GPLv3 is one of the options it permits.
  15. ^ Landley, Rob. "CELF 2013 Toybox talk". landley.net. Retrieved 2013-08-21. GPLv3 broke "the" GPL into incompatible forks that can't share code.
  16. ^ "Interpreting, enforcing and changing the GNU GPL, as applied to combining Linux and ZFS". fsf.org. Retrieved 2020-06-08.
  17. ^ US Copyright Office Form CO. "Ashton-Tate v. Fox" 참조
  18. ^ "OpenBSD Copyright Policy". The OpenBSD project. Retrieved 2020-06-09. In some jurisdictions, it is doubtful whether voluntarily placing one's own work into the public domain is legally possible. For that reason, to make any substantial body of code free, it is preferable to state the copyright and put it under an ISC or BSD license instead of attempting to release it into the public domain.
  19. ^ Hipp, D. Richard. "Why SQLite succeeded as a database". The Changelog. Also at the time I did not realize, having lived my whole life in the United States, which is, you know, under British common law, where the public domain is something that’s recognized. I did not realize that there were a lot of jurisdictions in the world where it’s difficult or impossible for someone to place their works in the public domain. I didn’t know. So that’s a complication.
  20. ^ David A의 Free-Libre/Open Source Software(FLOSS) 라이센스 슬라이드.2021년 10월 4일 휠러
  21. ^ Haff, Gordon. "The mysterious history of the MIT License". opensource.com. Retrieved 2020-06-08. [There's] a good argument to be made that the MIT License, also called the X Consortium or X11 License at the time, crystallized with X11 in 1987, and that's the best date to use. You could argue it was created in 1985 with possible adjustments over the next couple of years.
  22. ^ Vaughan-Nichols, Steven J. "The fall of GPL and the rise of permissive open-source licenses". zdnet.com. Retrieved 2015-11-28. The GPL is still the world's most popular open-source license but it's declining in use, while permissive licenses are gaining more fans, and some developers are choosing to release code without any license at all.
  23. ^ Ronacher, Armin (2013-07-23). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved 2015-11-18.
  24. ^ Aslett, Matthew (2011-06-06). "The trend towards permissive licensing". the451group.com. Archived from the original on 2015-10-13. Retrieved 2015-11-28.
  25. ^ 당신의 코드에는 라이선스가 필요합니까?Jason Hibbets가 2013년 5월 2일 게재한 "Q: 특정 오픈 소스 라이선스를 다른 라이선스보다 선호하는 소프트웨어 개발 회사가 있습니까?커뮤니티의 경향은 어떻습니까?A: 확실히 카피레프트 라이선스에서 벗어나 대부분 허용 라이선스로 향하는 경향이 있습니다."
  26. ^ a b "Add Kirk's comment about "copycenter"; it's just too good to pass up". Historical FreeBSD fortune(6) database. Retrieved 2020-06-08.
  27. ^ Raymond, Eric S. "copycenter". The Jargon File.
  28. ^ Stallman, Richard (2016-02-08). "License Compatibility and Relicensing". Free Software Foundation. Retrieved 2019-09-29. In general, lax permissive licenses (modified BSD, X11, Expat, Apache, Python, etc.) are compatible with each other. That's because they have no requirements about other code that is added to the program. They even permit putting the entire program (perhaps with changes) into a proprietary software product; thus, we call them "pushover licenses" because they can't say "no" when one user tries to deny freedom to others.
  29. ^ 자신의 작업에 필요한 라이선스를 선택하는 방법– Free Software Foundation
  30. ^ "Re-assessing Copyleft vs Cuck Licenses". DAI-SOS Brigade. 2 February 2022.
  31. ^ "Cuck license". InstallGentoo Wiki. A Cuck License is a permissive software license that that does not enforce the freedom of derivative works. This means that anyone can take software licensed under a Cuck License and turn it into proprietary software, effectively cucking the original author. Examples of Cuck Licenses are the MIT license and BSD license.
  32. ^ Smith, Luke, Why I Use the GPL and Not Cuck Licenses, Why be mean and bully BSD and MIT licenses calling them "Cuck Licenses"? Quite simply, using them is precisely analogous to being cuckolded. When you really look at it, the similarity is uncanny.

외부 링크