권장: 기본 라이센스를 선택하지 마십시오.

묘사

Eclipse 라이센스가 아닌 "TODO: Pick a license"로 라이센스를 변경하시겠습니까?나는 내가 그것을 바꿀 수밖에 없다는 것을 발견했다. (혹은 자주 잊어버린다.)내가 업무 프로젝트를 시작했을 때.

토론 #1

솔직히 말하면 어떤 허가증도 임무로 삼으면 대부분의 개발자들이 선택하지 않는다.아니오, 지역 사회에 우호적인 것을 선택해야 합니다.만약 네가 그것을 좋아하지 않는다면, 너는 그것을 바꿀 수 있다.

토론 #2

그러나 상업 프로젝트 포인트는 유효하다.비즈니스 프로젝트를 더욱 나아지게 하고 미래의 Clojure OSS 프로젝트의 절반을 실제로 허가받지 못하게 할 수 있는 다른 생각은 무엇입니까?@xp914 허가증 템플릿을 직접 만들 수 있습니다.내가 이렇게 하는 것은 더 많은 기능 (그리고

토론 #셋

파일의 허가증) 을 원하기 때문이다. 어쨌든, 나는 항상 그것들을 프로젝트에 추가한다.LICENSE 사용자를 위해 허가증을 선택하는 문제는 당신이 독심술자라고 주장하지 않는 한 잘못된 허가증을 선택할 확률이 매우 높다는 것이다.일단 네가 잘못 선택하면 그것은 체크 인될 수도 있다.이것은 하나의 문제가 되었다.(커뮤니티에서는 언제든지 작성자에게 어떤 라이센스를 좋아하는지 물어볼 수 있습니다.)
나는 우리 중 누구도 데이터 구동의 답이 있다고 생각하지 않는다. 즉, "만약 당신이 그것을 대기 사항으로 간주한다면 대부분의 개발자들은 어떠한 허가증도 선택하지 않을 것이다."이것은 라이닝겐 조사에 적합할 수 있는 경험적인 문제이다.
만약 적당한 허가증이 매우 중요하다면, 나는

토론 #4

검사를 건의합니다.약속을 어겨서는 안 된다고 생각합니다.(당신은 프로젝트 설명을 알아맞힐 수 없습니다. 왜 라이언도 허가증을 알아맞혀야 합니까?)
Github는 사용자가 허가증을 선택하도록 하지 않는다는 것을 지적하고 싶습니다.이것은 현명하고 비가설적인 방법이다.얘가 먼저 물어봐.나는 레닌건이 왜 면허증을 가지러 갔는지 모르겠다.밖에 좋은 게 많아요.
동시에 나는 템플릿을 사용할 것이다.lein deploy

I don't think any of us have a data-driven answer to "most developers won't pick any license if you make that a TODO".

사실상 GitHub은 14%만이 허가증을 신고했다.http://www.theregister.co.uk/2013/04/18/github_licensing_study/

토론 #5

나는 나의 대부분의 생각을 정리할 것이다.
1. 허가증이 없는 것이 문제라고 가정하면 (제4조의 반논점 참조) 문제 자체보다 더 나쁜 해결 방안을 제시하지 않도록 조심해야 한다.
2. 주의: 윌리엄슨은 Github의 새로운 허가증 수집기보다 먼저 조사했다.
3. 나는 Github의 새로운 방법을 좋아한다. 사용자가 기본 허가증으로 선택하지 않고 선택할 수 있도록 한다.기본값은 없음입니다.나는 이것이 가장 나쁘지 않은 선택이라고 생각한다.
4. 개원 제창의 측면에서 볼 때'문제'는 코드가 어느 곳에 배치되었을 때만 나타난다. 프로젝트를 초기화할 때가 아니다.
5. 한 항목이 허가증 없이 발표되면 저작권은 기본적으로 창설자이다.나중에 바꿔서 제한을 줄일 수 있는 것으로 알고 있습니다.그래서 만약 이것이 문제라면 이것은 바로잡기 쉽다.
6. 한 항목에 대한 라이센스가 올바르지 않으면 어떻게 됩니까?발표된 허가증이 정확하지 않기 때문에 이전의 코드가 여전히 사용할 수 있는지 알고 싶습니다.나는 확실하지는 않지만, 잘 들리지 않는다.엉망이 될 수도 있어.
7. 저는 개인적으로 구축 도구를 강제 또는 위약 허가에 사용해서는 안 된다고 생각합니다.(Leiningen은 다양한 도구의 완벽한 조합인 구축, 의존 관계 관리, 코드 생성, 배치 등) 이것이 바로 이 문제가 복잡해진 이유라고 생각합니다.
8. 나는 이러한 관점을 받아들이고 싶다. 코드 생성과/또는 배치 도구는 허가증이 없는 사용자에게 경고하는 데 사용해야 한다.
9. 허가증을 체불하지 않는 것이'게으름'소프트웨어 개발의 정신에 더 부합된다. 그렇지?개발자로서 왜 입력

토론 #6

만으로 자신을 위해 허가 결정을 내리려고 합니까?설마 코드를 좀 쓴 후에 결정하고 싶지 않으세요? "헤이, 나는 누구와 이 코드를 공유하고 싶은데, 왜?"
10. 모든 상황에 적용되는'최고'(예를 들어 우리가 동의할 수 있는) 허가증이 없다. 설령 개원 세계에서도 마찬가지다.
11. 기본적으로 하나의 허가증을 사용하는 것은 하나의 허가증을 우선적으로 사용하는 것이다.
12. 나는 누군가가 의식적으로 허가증의 의미를 생각할 때까지 허가증이 없는 프로젝트를 원한다.
13. 나는 프로젝트가'행운으로'EPL에만 들어가는 것을 원하지 않는다. 설령 그것이 올바른 선택일지라도 Leiningen이 그것을 기본값으로 하기 때문이다.나는 차라리 사람들이 고려해 보는 것이 낫다.
14. 나는'보이지 않는다'는 것은'마음이 딴 데 있다'는 것을 의미한다고 생각한다.기본 설정을 선택하면 사용자의 허가 의식이 떨어집니다.의식이 강하지 않다는 것은 잘못을 저지를 가능성이 더 크다는 것을 의미한다.
15. 만약에 목표가 어떤 방식으로 EPL을 더 많은 항목에 잠입시키는 것이라면 현재의 위약은 효과적인 방식이다.
16. 이 모든 것은 Clojure 커뮤니티가 실천에서 EPL을 지원하는 것을 좋아한다는 것을 보여준다.이것은 일을 더욱 쉽게 한다.
만약 우리가 불리한 요소에 대해 이야기한다면, 우리는 반드시 이 모든 요소를 언급해야 한다.
- lein new가 lein new로만 추가된 경우 다음과 같은 단점이 있습니다.
- 사용자가 라이센스를 선택하고 배치하는 것을 잊었습니다.(이것은 나중에 바로잡을 수 있지만 상처와 곤혹이 가장 적다. 상기 5조 참조)
- EPL을 원하는 사용자는 의도적으로 EPL을 입력해야 합니다.(오, 무서워!)
- TODO: pick license(현재 비헤이비어)가 기본적으로 Eclipse 공용 라이센스인 경우 단점:
- 사용자가 라이센스를 선택하지 않은 경우 그/그녀는 팀의 다른 사람에게 잘못된 라이센스 코드를 제공할 수 있습니다.이것은 아마도 큰 문제일 것이다.위 6조 참조)
- 비EPL 프로젝트의 템플릿 및/또는 수동 편집을 작성해야 합니다.
나는 이 문제들이 사람들이 잘못을 저지르는 데서 비롯된 것임을 깨달았다.그러나 지금 우리는 사람들이 저지른 여러 가지 잘못에 대해 논의했고, 그들을 보호할 수 있는 현명한 결정을 내려야 할지도 모른다.만약 개인의 의사에 따라 코드를 보호하는 것이 목표라면 허가증 없이 사용하는 것이 더 정확한 선택이다.만약 사람들이 EPL을 사용하도록 추진하는 것이 목표라면 현재의 행동은 더욱 정확하다.
설령 네가 동의하지 않더라도 나는 이미 나의 관점과 문제를 명확하게 표현했으면 한다.lein new 나는 네가 어디에서 왔는지 알고 있지만 도서관이 다른 것이 아닌 EPL에 따라 허가를 받는 실패 사례는 대부분의 도서관이 허가를 받지 않은 것을 유지하는 것보다 내 목표에 부합된다.보통 최초의 관리자와 연락하기 어렵거나 반응이 없기 때문에 지역사회는 그들 없이 계속 전진해야 한다.
Clojure 프로젝트는 다른 허가증도 사용했지만 그 중 많은 (마성이공대학과 대부분의 다른 슈퍼 허가증) 은 우리 같은 불쌍한 해커들에게 적용되지 않는다. 그들은 특허법이 파괴된 국가에 갇혀 특허 보호 허가증이 필요하다.GPL은 Clojure 자체의 허가증과 호환되지 않으며, Apache 허가증 (미국 afaik에서 유일하게 해커에 대해 특허 조항을 받아들일 수 있는 비저작권 허가증) 은 모든 문서에 일련의 샘플 파일을 요구한다.

토론 #7

나는 Clojure의 허가와 Leiningen이 새로운 프로젝트에 대한 EPL 위약 배후의 이유를 연구하면서 이 단서를 발견했다.GNU 관리자로서 가능한 경우 GPL을 강력히 지원합니다.이런 상황에서 이 게시물은 GPL에 대해 약간의 의심을 갖게 될 수도 있고 구글에 나타날 수도 있기 때문에 다른 사람들이 놀라지 않도록 댓글을 달고 싶다.

The GPL is incompatible with Clojure's own license

비록 이것은 사실이지만, 그것은 유사한 GNU classpath 방식으로 호환될 수 있다.나는 FSF의 승인 팀과 어떠한 질문도 해결하기 위해 이중 점검을 수행했습니다.그들의 대답은 (AGPL에 대해 물어봤지만 GPL에도 적용된다):

One easy option for the code you write yourself would be to license it under the [A]GPL with an extra permission:

https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

You may also want to review this answer:

https://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat

그리고 하나 더 있습니다.

[...] and the Apache license (the only non-copyleft license with acceptable patent terms for hackers in the US afaik) requires a bunch of boilerplate in every single file.

이것은 결코 나쁜 일이 아니다. 만약 원본 파일이 독립적으로 분배되거나 인용된다면 허가 문제를 명확하게 해결할 수 있다.어쨌든 이것은 좋은 생각이다.GNU도 GPL의 사용을 권장하지만 (Apache의 경우에도 마찬가지) 이것은 법률적인 요구가 아니다. 판권 소유자로서 당신이 하고 싶은 일을 할 수 있다.
어쨌든, EPL은 자유 소프트웨어 허가증이고, 지역 사회에서 생산되는 대부분의 다른 Clojure 라이브러리와 호환되는 것을 감안하면, 기본 설정이 합리적이라는 것을 알 수 있습니다. 많은 사용자들이 허가증을 선택하는 데 시간을 들이지 않기 때문에, 최종적으로 더 많은 자유 소프트웨어를 발표하는 데 도움을 줄 것입니다.비록 사용자가 좋은 의도를 가지고 있지만, 적당한 허가가 없는 상황에서, 그것은 여전히 전유물이다.

토론 #8

해명해 주셔서 감사합니다.기본값이 변하지 않더라도 모든 사람이 대체안을 알고 있어야 한다.

if a source file is independently distributed or referenced, it unambiguously resolves licensing concerns; it's a good idea regardless. GNU also encourages it for the GPL

GNU에 의미가 있다고 생각합니다. 주로 C 언어에서 일하고 C 언어는 광범위하게 사용되는 의존 관계 관리 도구가 없기 때문에 사람들이 하나의 파일을 복사할 가능성이 높다는 것을 의미합니다.그러나 Leiningen의 모든 목적은 전체 프로젝트를 하나의 단원으로 처리하는 것이기 때문에 Clojure에서 이런 파일이 프로젝트와 격리되는 경우는 매우 드물다.