라이선스의 급증

License proliferation

라이선스의 급증은 FOSS 생태계에서 이미 존재하는 소프트웨어 및 소프트웨어 패키지의 새로운 소프트웨어 라이선스가 계속 생성되고 있는 현상입니다.라이선스의 급증은 복잡해지는 라이선스 선택, 라이선스 상호 작용 및 라이선스 호환성 고려사항에 [1]대한 부담으로 인해 전체 FOSS 생태계에 부정적인 영향을 미칩니다.

영향

소프트웨어 개발자가 서로 다른 소프트웨어 프로그램의 일부를 병합하려는 경우 라이센스가 호환되지 않기 때문에 병합할 수 없는 경우가 많습니다.2개의 다른 라이선스의 소프트웨어를 대규모 소프트웨어 워크에 통합할 수 있는 경우 라이선스는 호환성이 있다고 합니다.라이선스의 수가 증가함에 따라 프리 및 오픈소스 소프트웨어(FOSS) 개발자가 호환되지 않는 라이선스로 사용 가능한 소프트웨어를 통합할 가능성이 높아집니다.또한 [1]사용하는 소프트웨어 패키지에 대한 모든 FOSS 라이센스를 평가하고자 하는 기업에게는 더 많은 비용이 듭니다.엄밀히 말하면, 면허증 확산에 찬성하는 사람은 아무도 없다.이 문제는 조직이 소프트웨어 릴리스에 대한 실제 또는 인식된 요구에 대응하기 위해 새로운 라이선스를 작성하는 경향에서 비롯됩니다.

라이선스 호환성

라이선스가 다른 라이선스와 라이센스 호환성 관계가 제한적이거나 복잡한 경우 라이선스의 확산은 특히 문제가 됩니다.따라서 David A와 같이 널리 사용되는 GNU General Public License(GPL)와의 호환성을 중요한 특징으로 간주하는 사람도 있습니다.Wheeler는[2][3] 또한 [4]GPL과 호환되는 라이센스 목록을 유지하는 Free Software Foundation(FSF)이기도 합니다. 반면 일부에서는 더 많은 [6][7]라이센스와의 호환성이 뛰어나기 때문에 카피레프트 [5]라이센스 대신 Permitive 라이센스를 권장합니다.예를 들어 Apache Foundation은 Apache 라이선스는 카피레프트 GPLv3와 호환되지만 GPLv3는 허용 Apache 라이선스와 호환되지 않는다는 사실을 비판합니다. Apache 소프트웨어는 GPLv3 소프트웨어에 포함될 수 있지만 그 [8]반대는 아닙니다.또 하나의 관련 예로서 GPLv2는 그 자체로는 [9]GPLv3와 호환되지 않습니다.2007년에 출시된 GPLv3는 FOSS [10][11][12][13][14][15][16]생태계에 호환되지 않는 라이선스를 추가했다는 이유로 여러 저자에 의해 비판을 받았습니다.

배니티 라이선스

배니티 라이선스는 회사나 개인이 자신의 라이선스를 작성하기 위해 작성한 라이선스입니다(「NIH 증후군」).[17]다른 일반적인 FOSS 라이선스에 비해 뚜렷한 개선이나 차이가 없는 새로운 라이선스가 생성되면 종종 배니티 라이선스로 비난받을 수 있습니다.2008년 현재, 많은 사람들이 FOSS 라이선스의 요건도 모르고, 비표준 라이선스를 사용하면 그 프로그램이 [18]다른 사람들에게 거의 쓸모없게 될 수도 있다는 것을 깨닫지 못한 채, 새로 출시된 프로그램의 새로운 커스텀 라이선스를 만들고 있습니다.

솔루션 어프로치

GitHub의 입장

2013년 7월, GitHub는 choosealicense라는 [19]라이선스 선택 마법사를 시작했습니다.GitHub의 선택적인 첫 페이지에는 MIT 라이선스, Apache 라이선스, GNU General Public License의 3가지 라이선스만 빠르게 선택할 수 있습니다.일부 추가 라이선스는 서브페이지 및 [20]링크를 통해 제공됩니다.2015년에 이어 GitHub에 대한 모든 라이센스 프로젝트 중 약 77%가 이 세 가지 라이센스 [21]중 적어도 한 가지 이상의 라이센스로 라이센스를 받았습니다.

구글의 입장

2006년부터 Google Code는 다음 7가지 [22]라이센스로만 라이센스가 부여된 프로젝트만 수락했습니다.

1년 후인 2008년경에는 GNU General Public License 3.0이 추가되어 허가된 Apache [23]라이선스와 함께 강력히 권장되었습니다.특히 라이선스의 [24]확산을 줄이기 위한 AGPLv3는 제외되었습니다.

2010년에 Google은 이러한 제한을 철폐하고 OSI가 승인한 라이센스(아래 [25]OSI의 입장 참조)를 프로젝트에 사용할 수 있도록 하겠다고 발표했지만, 퍼블릭 도메인 프로젝트는 단일 케이스 결정으로만 허용된다는 제한이 있습니다.

OSI의 입장

OSI(Open Source Initiative)는 승인된 [26]라이선스 목록을 유지합니다.초기 OSI는 허영 라이선스와 재사용 불가능한 라이선스를 승인함으로써 라이선스의 확산에 기여했습니다.2004년 OSI 라이선스 확산 프로젝트가 시작되어[27] [28]2007년 라이선스 확산 보고서가 작성되었습니다.이 보고서에서는 라이선스의 클래스를 다음과 같이 정의했습니다.

  • 널리 사용되거나 강력한 커뮤니티에서 사용되는 라이센스
  • 국제 라이선스
  • 특수목적 라이선스
  • 기타/기타 라이선스
  • 보다 일반적인 라이선스와 중복된 라이선스
  • 재사용할 수 없는 라이선스
  • 대체 라이선스
  • 자발적으로 폐기된 라이선스
  • 분류되지 않은 라이선스

「인기 있는」라이선스 그룹에는, 다음의 9개의 라이센스가 있습니다.Apache License 2.0, New BSD License, GPLv2, LGPLv2, MIT License, Mozilla Public License 1.1, Common Development and Distribution License, Common Public License, Eclipse Public Lic Lic License.

FSF의 입장

자유 소프트웨어 재단의 전 사장 Richard Stallman과 전 전무이사 Bradley M. Kuhn은 2000년 FSF 라이선스 목록을 제정하면서 라이선스 확산에 반대해 왔습니다.이 목록은 개발자들에게 GPL 호환 자유 소프트웨어 라이선스로 소프트웨어를 라이선스하도록 촉구하지만 여러 GPL 호환 자유 소프트웨어 라이선스로 라이선스하도록 촉구합니다.e 라이선스는 해당 라이선스에 이미 포함되어 있는 소프트웨어를 사용하거나 작업하는 데 문제가 없음을 나타내는 코멘트와 함께 리스트의 독자들에게 자신이 [29]작성한 소프트웨어에서 이러한 라이선스를 사용하지 말 것을 권장합니다.

FSF 유럽의 Ciarn O'Riordan은 GPLv3가 라이선스의 [30]확산에 대처하는 방법이라는 제목의 사설에서 FSF가 라이선스의 확산을 방지하기 위해 할 수 있는 가장 중요한 것은 애초에 새로운 라이선스를 만드는 이유를 줄이는 것이라고 주장한다.일반적으로 FSF 유럽에서는 가능한 한 GNU GPL을 사용할 것을 권장합니다.그것이 불가능할 때는 GPL 호환 라이선스를 사용할 것을 권장합니다.

다른이들

2005년에 인텔은 오픈 소스 라이선스의 OSI 목록에서 인텔 오픈 소스 라이선스를 자발적으로 철회하고 라이선스의 [31]확산을 줄이기 위해 이 라이선스의 사용 및 권장도 중지했습니다.

451 그룹은 2009년 6월에 「오픈 소스 라이센스 [32]확산의 신화」라고 하는 확산 리포트를 작성했습니다.Washington University of Law School의 2009년판 '오픈 소스 라이선스 확산: 유용한 다양성 또는 절망적인 혼란?이 해결책으로 "A Wizzier Wichard"(라이선스 선택용), "Best Practices and Legacy Licenses", "More Legal Services For Hackers"[33]의 3가지를 요구했습니다.OSSCC(OpenSource Software Collaboration Counseling)에서는 당초 권장했던9개의 OSI 라이선스를 바탕으로 Apache License 2.0, New BSD License, CDDL, MIT License 및 MPL의 5가지 라이선스를 콜라보레이션, 특허 사용 및 특허 보호를 지원하므로 권장하고 있습니다.특히 GPL은 [34]"이 라이선스는 다른 라이선스로 다른 작업 내에서 사용할 수 없습니다."로 되어 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Martin Michlmayr의 OSI와 라이선스 확산은 fossbazar.com에 있습니다.라이선서는 너무 많은 라이선스를 선택할 수 없기 때문에 프로젝트에 적합한 라이선스를 선택하기가 어렵습니다. 일부 라이센스는 서로 잘 연동되지 않습니다. 일부 오픈 소스 라이센스는 다른 오픈 소스 라이센스와 상호 운용이 원활하지 않으므로 다른 프로젝트의 코드를 통합하기가 어렵습니다. 라이선스가 너무 많으면 여러 라이선스의 배포에서 동의한 내용을 이해하기 어렵습니다.일반적으로 FOSS 어플리케이션에는 다른 라이선스의 코드가 포함되어 있으며, 사용자는 1개 또는 여러 라이선스가 포함된 많은 어플리케이션을 사용하기 때문에 사용자의 의무가 무엇인지 파악하기 어렵습니다.(2008년 8월 21일)
  2. ^ David A의 Free-Libre/Open Source Software(FLOSS) 라이센스 슬라이드.2007년 9월 27일 휠러
  3. ^ "Make Your Open Source Software GPL-Compatible. Or Else". www.dwheeler.com.
  4. ^ 라이선스 리스트 gnu.org의 Wayback Machine에서 아카이브된2000-08-15
  5. ^ Laurent, Philippe (September 24, 2008). "The GPLv3 and compatibility issues" (PDF). European Open source Lawyers Event 2008. University of Namur – Belgium. p. 7. Archived from the original (PDF) on March 4, 2016. Retrieved May 30, 2015. Copyleft is the main source of compatibility problems
  6. ^ Hanwell, Marcus D. (January 28, 2014). "Should I use a permissive license? Copyleft? Or something in the middle?". opensource.com. Retrieved May 30, 2015. 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.
  7. ^ "Licence Compatibility and Interoperability". Open-Source Software - Develop, share, and reuse open source software for public administrations. joinup.ec.europa.eu. Archived from the original on June 17, 2015. Retrieved May 30, 2015. The licences for distributing free or open source software (FOSS) are divided in two families: permissive and copyleft. Permissive licences (BSD, MIT, X11, Apache, Zope) are generally compatible and interoperable with most other licences, tolerating to merge, combine or improve the covered code and to re-distribute it under many licences (including non-free or “proprietary”).
  8. ^ Apache foundation (May 30, 2015). "GPL compatibility". Retrieved May 30, 2015. Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
  9. ^ "Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?". gnu.org. Retrieved June 3, 2014. 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.
  10. ^ Landley, Rob. "CELF 2013 Toybox talk". landley.net. Retrieved August 21, 2013. GPLv3 broke "the" GPL into incompatible forks that can't share code.
  11. ^ Asay, Clark D. "Michigan Telecommunications and Technology Law Review Volume 14 - Issue 22008 The General Public License Version 3.0: Making or Breaking the Foss Movement". law.umich.edu. In the end, GPLv3 constitutes license proliferation.
  12. ^ Nikolai Bezroukov (2000). "Comparative merits of GPL, BSD and Artistic licences (Critique of Viral Nature of GPL v.2 - or In Defense of Dual Licensing Idea)". Archived from the original on December 22, 2001. Viral property stimulates proliferation of licenses and contributes to the "GPL-enforced nightmare" -- a situation when many other licenses are logically incompatible with the GPL and make life unnecessary difficult for developers working in the Linux environment (KDE is a good example here, Python is a less known example). I think that this petty efforts to interpret GPL as a "holy text" are non-productive discussion that does not bring us anywhere. And they directly contributed to the proliferation of different "free software" licenses.
  13. ^ Byfield, Bruce (November 22, 2011). "7 Reasons Why Free Software Is Losing Influence: Page 2". Datamation.com. Retrieved August 23, 2013. At the time, the decision seemed sensible in the face of a deadlock. But now, GPLv2 is used for 42.5% of free software, and GPLv3 for less than 6.5%, according to Black Duck Software.
  14. ^ James E.J. Bottomley, Mauro Carvalho Chehab, Thomas Gleixner, Christoph Hellwig, Dave Jones, Greg Kroah-Hartman, Tony Luck, Andrew Morton, Trond Myklebust, David Woodhouse (September 15, 2006). "Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3". LWN.net. Retrieved March 11, 2015. [...]since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely.{{cite web}}: CS1 maint: 작성자 파라미터 사용(링크)
  15. ^ Ronacher, Armin (July 23, 2013). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved November 18, 2015. The License Compatibility Clusterfuck - When the GPL is involved the complexities of licensing becomes a non fun version of a riddle. So many things to consider and so many interactions to consider. And that GPL incompatibilities are still an issue that actively effects people is something many appear to forget. For instance one would think that the incompatibility of the GPLv2 with the Apache Software License 2.0 should be a thing of the past now that everything upgrades to GPLv3, but it turns out that enough people are either stuck with GPLv2 only or do not agree with the GPLv3 that some Apache Software licensed projects are required to migrate. For instance Twitter's Bootstrap is currently migrating from ASL2.0 to MIT precisely because some people still need GPLv2 compatibility. Among those projects that were affected were Drupal, WordPress, Joomla, the MoinMoin Wiki and others. And even that case shows that people don't care that much about licenses any more as Joomla 3 just bundled bootstrap even though they were not licenses in a compatible way (GPLv2 vs ASL 2.0). The other traditional case of things not being GPL compatible is the OpenSSL project which has a license that does not go well with the GPL. That license is also still incompatible with the GPLv3. The whole ordeal is particularly interesting as some not so nice parties have started doing license trolling through GPL licenses.
  16. ^ GPL을 사용하시겠습니까? Armin Ronacher(2009)
  17. ^ 의료 소프트웨어 공유: Fred Trotter(2007-06-14)의 freesoftwaremagazine.com 의학 관련 FOSS 라이선스
  18. ^ "David A. Wheeler's Blog". dwheeler.com.
  19. ^ GitHub은 마침내 2013년 7월 Simon Phipps의 Infowold 오픈 소스 라이선스를 진지하게 받아들인다.
  20. ^ 오픈 소스 라이선스를 선택하는 것이 번거로울 필요는 없습니다.다음 중 고객의 상황을 가장 잘 설명한 것은 무엇입니까?choosealicense.com (2015-11-29)
  21. ^ 2015년 3월 9일 벤 발터가 GitHub.com의 오픈 소스 라이센스 사용률 "MIT 44.69%, [...]GPLv2 12.96%, Apache 11.19%, GPLv3 8.88%
  22. ^ Ed Burnette (November 2, 2006). "Google says no to license proliferation". Archived from the original on February 24, 2007. Retrieved September 11, 2010.
  23. ^ Greg Stein (May 28, 2009). "Standing Against License Proliferation". Archived from the original on June 1, 2008. Retrieved September 11, 2010.
  24. ^ 2009년 1월 27일, Ernest M. Park의 License Proposition - Less is More, One is Best 」는, 「Google의 Chris DiBona가 Google Code Repository의 AGPLv3 라이선스를 거부했을 때에, OSS 커뮤니티로부터 큰 충격을 받았습니다.」라고 하는 이유의 1개가 되고 있습니다.
  25. ^ Chris DiBona (September 10, 2010). "License Evolution and Hosting Projects on Code.Google.Com". Retrieved September 11, 2010.
  26. ^ opensource.org의 OSI 승인 라이선스
  27. ^ opensource.com 라이선스 확대 프로젝트 (2004)
  28. ^ opensource.com의 Wayback Machine에서 2012-12-12년에 아카이브된 라이선스 확산 보고서(2007)
  29. ^ 라이센스 목록의 가장 오래된 아카이브 버전은 이 위치를 반영합니다.Bradley M. Kuhn (August 15, 2000). "Various Licenses and Comments about Them". Free Software Foundation. pp. 37–39. Archived from the original on August 15, 2000. Retrieved November 29, 2015.
  30. ^ linuxdevices.com에서의 GPLv3 라이선스 확산에 어떻게 대처하는가
  31. ^ Marson, Ingrid (March 31, 2005). "Intel to stop using open-source license". cnet.com. CNet. Retrieved October 6, 2014.
  32. ^ the451group.com의 오픈 소스 라이선스 확산 신화
  33. ^ 오픈 소스 라이선스 확산: 유용한 다양성 또는 절망적인 혼란?법률에 의거해서washington.edu by Robert W. Gomulkiewicz (2009년)
  34. ^ osscc.net 라이선스 호환성

외부 링크