프로젝트에 쓰이는 MIT 라이센스를 무의식적으로 "다들 이걸로 세팅하던데..."하고 업로드 하려는 스스로를 보고 아차 했다!
오픈소스 라이센스를 고를 때 고려해야될 방법과 가장 흔히 쓰이는 MIT 라이선스는 무엇인지도 알아보고 만약 라이선스를 넣지 않을 경우엔 어떻게 되는지도 알아보겠다!
저작권? Copyright
저작권은(Berne 협약 이후) 저작자가 저작물을 만들 때 자동으로 생성된다. 모든 저작물은 저작권에 의해 보호되며, 저작권 보유자에게 저작물에 대한 독점적인 권한이 부여된다. 따라서 당신의 저작물(소스 코드, 텍스트, 이미지, 기타 미디어 등)을 다른 사용자가 사용할 수 있게 하려면 그들에게 라이선스를 부여해야 한다.
라이선스 License
특정 권리를 실행하기 위해 자격이 있는 기관으로부터 받은 허가. 허가 없이 특정 권리를 실행하는 것은 저작권 침해와 같은 불법 행위가 된다.
우리가 다른 사람의 소스 코드를 복사, 수정 등의 작업을 하려면 필요한 권한을 부여받기 위해 라이선스를 받아야 한다. 만약 그 라이선스가 권리 실행 허가 조건으로 특정 의무를 요구한다면, 권리 실행을 위해 의무사항도 따라야만 한다.
저작권법의 기본 요건을 준수하기 위해선 최소 두 가지가 필요하다.
✔️ 저작자 표시 (Attribution)
저작권 보유자 또는 저자를 명시한다.
✔️ 라이선스(License)
라이선스는 저작권 보유자 이외의 다른 사람에게 코드 사용 권한을 부여하는 유일한 방법이다! 때문에 라이선스를 고지하고 전체 라이선스 텍스트를 제공하는 게 좋다. 내보내는 Outbound 라이선스나 다른 이로부터 받는 Inbound 라이선스 모두 해당.
왜 라이선스를 사용해야 하는가?
No License?... No!
라이선스를 선택하지 않을 경우 기본 저작권 법이 적용되는데, 이는 모든 권리를 스스로에게 부여하고 누구도 복제, 배포 또는 2차 저작물을 만들 수 없다는 것을 의미한다. 오픈 소스 라이선스는 소스 코드로 할 수 있는 것과 할 수 없는 것을 명시한다. 사실 라이선스를 꼭 선택해야할 의무는 없지만 진정한 오프 소스가 되려면 권한을 명시하고, 다른 개발자들이 자유롭게 사용 및 변경할 수 있도록 라이선스를 부여해야 하는 것이 오픈 소스의 목적에 맞을 것이다.
Github은 오픈 소스 프로젝트를 만들 경우 라이선스를 포함할 것을 강력하게 권장하고 있다.
오픈 소스 라이선스는 기여자와 사용자를 보호합니다. 기업과 실무 개발자는 이런 보호 장치가 없는 프로젝트에 손대지 않습니다!
No License를 발견했는데 해당 소스 코드를 사용하고 싶다면 이 링크를 참고하자.
오픈 소스에 All rights reserved 표기?
All rights reserved는 명백히 오픈소스 라이선스와 모순된다. 오픈소스 라이선스는 누구나 코드를 사용, 연구, 공유 및 개선할 수 있는 권리를 제공하기 위한 목적인 반면, All rights reserved는 이런 모든 권리가 자신에게만 부여된다는 표현이다. 오픈 소스의 목적과 부딪혀 혼란만 야기할 뿐, 어떤 이점도 가져오지 않기 때문에 오픈소스에서는 사용하지 않아야 한다.
만약 저작권 제한을 완전히 없애기 위해 No license를 택했다면 그 대신 Public domain dedication 퍼블릭 도메인 라이선스를 사용하자!
`The Unlicense`
퍼블릭 도메인으로 저작물을 배포를 위해 지켜야될 조건이 없는 라이센스이다. 개발자가 소프트웨어에 대한 모든 권리를 포기하고 다른 사람들이 해당 소프트웨어를 자유롭게 사용, 수정, 복제 및 배포할 수 있도록 한다.
Choosing the right license
Which of the following best describes your situation?
각자의 목적에 맞춰 가장 적절한 라이선스를 골라야 한다.
1. 내가 소속된 집단, 회사에서 필요하다.
기여하고 있거나 소속된 집단에서 선호하는 라이선스를 사용하자.
기존 프로젝트에 기여하거나 확장하는 경우, 해당 프로젝트의 라이선스를 계속 사용하는 게 좋다. 원본 프로젝트의 라이선스에 따라 사용하는게 가장 쉽거나 필수 조건일 수 있다.
2. 간단하고 관용적인 라이선스를 원한다.
MIT 라이선스는 짧고 간결하다. 사람들이 프로젝트에 대해 비공개 소스 버전을 만들고 배포 하는 등의 원하는 모든 것을 할 수 있다. Babel, .NET, Rails는 MIT 라이선스를 사용하고 있다.
3. 개선사항을 공유하는 데에 관심이 많다.
GNU, GPLv3을 사용하면 비공개 소스 버전 배포를 제외하고는 사람들이 프로젝트에 대해 원하는 거의 모든 작업을 할 수 있다. Bash, Ansible, GIMP가 사용하고 있다.
라이선스 종류
GNU, GPL General Public License
가장 강력한 저작권 라이선스. 이 라이선스가 부여된 저작물의 전체 소스 코드와 라이선스가 부여된 저작물을 사용한 대규모 저작물을 포함한 수정본을 동일한 라이선스에 따라 제공하는 것을 조건으로 한다. 저작권 및 라이선스 고지를 보존해야하고 기여자는 특허권을 명시적으로 부여한다. 수정된 버전을 사용하여 네트워크를 통해 서비스를 제공하는 경우 수정된 버전의 전체 코드를 제공해야 함.
GNU AGPLv3, GPLv3, LGPLv3 등 더 자세한 것은 여기를 참고하자. 상업적인 용도로 사용은 할 수 있지만 코드를 전체 공개해야하기 때문에 회사에서 라이브러리를 채택할 때는 반드시 어떤 라이선스가 있는지 미리 체크해야 한다.
MIT License
미국 매사추세츠 공과대학교(MIT) 해당 대학의 소프트웨어 공학도들을 돕기 위해 개발한 라이선스.
라이선스 및 저작권을 명시해야하고, 상업적, 사적으로 이용이 가능하며 수정/배포/특허 신청이 가능하다. 제약조건이 느슨한 편이라 많은 오픈 소스들이 MIT 라이선스를 선택했다. GNU 일반 공중 라이선스(소프트웨어를 개조한 제품을 반드시 오픈 소스로 배포해야 한다)의 엄격함을 피하려는 사용자들에게 인기가 있다.
React, Angulat, Vue, Svelt 모두 MIT 라이선스다.
MIT License
Copyright (c) [year] [fullname]
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
면책 조항 Disclaimer
Github의 오픈 소스 라이선스의 목표는 사용자가 정보에 입각한 선택을 할 수 있도록 출발 점을 제공하는 것이다. Github에 라이선스 정보를 표시하여 사용자가 오픈소스 라이선스 및 해당 라이선스를 사용하는 프로젝트에 대한 정보를 얻을 수 있게 도와준다.
🌟 하지만 Github은 변호사가 아니며 다른 사람들과 마찬가지로 실수를 할 수 있다는 점을 명심하자! 따라서 Github은 정보를 있는 그대로 제공하며, 이 정보를 통해 제공되는 정보나 라이선스에 대해 어떠한 보증도 하지 않으며, 라이선스 정보 사용으로 인한 손해에 대해 책임을 지지 않는다. 따라서 개인, 기업 모두 라이선스에 대한 충분한 이해와 지식이 필요하다.
라이선스에 따른 Can, Can't를 잘 보여주는 비교표도 있다.
[라이선스 비교표]
HOW?
레포의 root에서 LICENSE.txt, LICENSE.md 의 파일로 기술되어 업로드된다. 혹은 README.md에서 “This project is licensed under the terms of the MIT license.” 를 기술하여 라이선스를 명시하기도 한다.
생각보다 꽤 무거운 주제였고, 오픈 소스를 사용할 때 목적에 따라 여러가지 고려해야될 부분이라고 생각되었다. MIT License의 경우 너무 흔히 볼 수 있는 라이선스여서 당연하게만 생각했는데 어떤 조건을 갖고 있는지 알게되어 좋았다.
여러 라이선스를 비교 해보았을 때 나의 프로젝트로 MIT LICENSE를 적용하기로 결정했다.
[Choose an open source license]
'Problem Drilling' 카테고리의 다른 글
| 브라우저에서 Excel 파일 다운로드하기: Blob과 CORS 해결과정 (0) | 2024.04.22 |
|---|---|
| Axios interceptors로 API Data 목적에 맞게 분류하기 (0) | 2024.03.03 |
| Github Action Test 성공하고 Workflow 복붙했다가 큰 코 다친 이야기 (2) | 2023.11.12 |
| Github Actions 사용, Workflow 테스트 자동화 적용하기, pnpm (0) | 2023.11.11 |
| Vite config파일 수정해서 배포 디렉토리 상대 경로로 변경하기 (0) | 2023.10.29 |