Skip to content

Commit 43be0e2

Browse files
committed
add a blog, elasticsearch
1 parent 50c138e commit 43be0e2

File tree

3 files changed

+241
-0
lines changed

3 files changed

+241
-0
lines changed
74.7 KB
Loading
Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
date: 2024-09-06
3+
title: "또 다시 Elasticsearch 라이선스 변경, 기업의 대응 방안은?"
4+
linkTitle: "Elasticsearch 라이선스 변경"
5+
description:
6+
author: 장학성
7+
categories: ["blog"]
8+
tags: ["Elastic", "AGPL"]
9+
resources:
10+
- src: "**.{png,jpg}"
11+
title: "Image #:counter"
12+
params:
13+
byline: ""
14+
---
15+
16+
## 서론: Elasticsearch 라이선스 배경
17+
18+
Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 번의 라이선스 정책 변경을 겪었습니다. 처음에는 **Apache 2.0 라이선스** 하에 배포되었지만, 2021년 Elastic은 **Elastic License 2.0****Server Side Public License**로 라이선스를 변경했습니다. 이후 2024년 8월 30일에는 다시 **AGPL-3.0**을 추가하는 발표([Elasticsearch is Open Source, Again](https://www.elastic.co/kr/blog/elasticsearch-is-open-source-again))를 하면서 주목을 받고 있습니다.
19+
20+
21+
![](./featured_original-elastic-logos.png)
22+
23+
이러한 변화는 오픈소스 커뮤니티뿐만 아니라 이를 사용하는 기업들에도 큰 영향을 미치고 있습니다. 이번 글에서는 Elasticsearch가 왜 다시 라이선스 정책을 변경했는지, 그리고 이를 사용하는 기업들이 어떻게 대응해야 하는지 살펴보겠습니다.
24+
25+
---
26+
27+
## 1. Elasticsearch 라이선스 변경의 역사
28+
29+
### 1.1 Apache 2.0에서 Elastic License 2.0으로의 전환
30+
Elasticsearch는 처음에 **Apache 2.0** 라이선스를 사용했으나, 2021년 1월 Elastic은 **Elastic License 2.0****SSPL**로 전환했습니다. Elastic이 이러한 변화를 선택한 이유는 클라우드 제공자, 특히 **AWS**와의 경쟁 때문입니다. AWS는 Elasticsearch를 기반으로 한 자체 서비스를 제공하면서도, 이에 대한 기여나 비용 지불 없이 수익을 창출했기 때문에 Elastic은 이를 견제하고자 라이선스를 변경했습니다.
31+
32+
**Elastic License 2.0**은 소스 코드를 공개하지만 상업적인 클라우드 서비스에서의 사용을 제한하는 라이선스로, Elastic의 기술적 자산을 보호하는 수단으로 활용되었습니다. **AWS**는 이에 대응해 **[OpenSearch](https://opensearch.org/)** 프로젝트를 시작하며 Apache 2.0 라이선스를 계속 유지했습니다.
33+
34+
이에 대해서는 이전 블로그, "**[Elastic License 2.0 그리고 진화하는 오픈소스 라이선스](https://openchain-project.github.io/OpenChain-KWG/blog/2021/03/28/elastic-license-2.0-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%A7%84%ED%99%94%ED%95%98%EB%8A%94-%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EB%9D%BC%EC%9D%B4%EC%84%A0%EC%8A%A4/)**"에서 자세히 다룬 바 있습니다.
35+
36+
### 1.2 Elastic License 2.0는 오픈소스 라이선스가 아니다
37+
그러나 Elastic License 2.0은 **Open Source Initiative (OSI)**에서 인정하는 오픈소스 라이선스가 아니었습니다. 이는 오픈소스 커뮤니티에서 논란을 불러일으켜습니다. Elastic의 결정은 오픈소스의 자유로운 사용과 상업적 이익 사이에서 갈등을 불러일으켰고, 기업들이 오픈소스를 도입할 때 라이선스 문제에 대한 경각심을 높이는 계기가 되었습니다.
38+
39+
---
40+
41+
## 2. Elasticsearch, AGPL-3.0 도입 배경
42+
43+
### 2.1 AGPL-3.0의 주요 특징
44+
45+
2024년 8월, Elastic은 GNU Affero General Public License v3 (AGPL-3.0)를 Elasticsearch와 Kibana의 무료 부분에 대한 라이선스 옵션으로 [추가한다고 발표](https://www.elastic.co/kr/blog/elasticsearch-is-open-source-again)했습니다. AGPL-3.0은 네트워크를 통한 소프트웨어 사용에 대해서도 소스 코드를 공개해야 한다는 점에서 기존 **GPL** 라이선스와 차별화됩니다.
46+
47+
AGPL-3.0의 **주요 특징**은 다음과 같습니다:
48+
- **소스 코드 공개 의무**: 네트워크를 통해 소프트웨어를 제공할 때, 사용자가 요청하면 소스 코드를 제공해야 합니다.
49+
- **강력한 카피레프트**: AGPL-3.0은 소프트웨어의 변경 사항도 동일한 라이선스 하에 배포되도록 요구합니다.
50+
51+
AGPL-3.0에 대한 자세한 가이드는 여기에서 참고하실 수 있습니다.: [AGPL-3.0 가이드](https://sktelecom.github.io/guide/use/obligation/agpl-3.0/)
52+
53+
### 2.2 AGPL-3.0으로 복귀한 이유
54+
55+
Elastic이 **AGPL-3.0**을 선택한 이유는 다음과 같습니다:
56+
57+
- **오픈소스 커뮤니티와의 관계 회복**: 이전의 라이선스 변경으로 인해 커뮤니티의 신뢰를 잃었기 때문에, 이를 회복하고자 OSI가 인정하는 AGPL-3.0으로 돌아섰습니다. Elastic의 창립자이자 CTO인 Shay Banon은 "우리는 항상 오픈소스의 정신과 그것이 가능하게 하는 명확성과 투명성을 강하게 믿어왔습니다"라고 [말했습니다](https://www.elastic.co/pricing/faq/licensing).
58+
- **사용자들에게 더 많은 자유와 유연성 제공**: AGPL-3.0은 OSI가 승인한 라이선스로, 사용자들에게 더 많은 권리를 제공합니다.
59+
- **신뢰도 향상**: OSI가 승인한 라이선스를 사용함으로써 오픈소스 커뮤니티 내에서의 신뢰도를 높이고자 했습니다.
60+
61+
Elastic의 이 결정은 커뮤니티와의 관계 회복을 시도하는 동시에, 여전히 상업적 사용을 통제하려는 전략적 선택으로 볼 수 있습니다.
62+
63+
그러나 일부 전문가들은 이러한 변화가 커뮤니티의 신뢰를 빠르게 회복할 수 있을지에 대해 의문을 제기하고 [있습니다](https://www.infoq.com/news/2024/09/elastic-open-source-agpl/). 또한, OpenSearch의 성공이 Elastic의 이번 결정에 영향을 미쳤을 수 있다는 분석도 [있습니다](https://www.computing.co.uk/news/4352646/elastic-returns-open-source-fold).
64+
65+
66+
---
67+
68+
## 3. 오픈소스 라이선스 변화의 시대, 기업은 어떻게 해야 하나?
69+
70+
이러한 라이선스 변경은 오픈소스를 사용하는 기업들에게 중요한 시사점을 제공합니다. 기업들은 오픈소스 소프트웨어의 라이선스 변경 가능성을 항상 염두에 두고, 이에 대한 대응 전략을 수립해야 할 필요성이 있습니다.
71+
72+
### 3.1 라이선스 변경에 대한 모니터링
73+
오픈소스 라이선스의 잦은 변경은 기업에게 새로운 법적 리스크를 안겨줄 수 있습니다. 이를 예방하기 위해서는 지속적인 **모니터링**이 필요하며, 이를 위한 전담 팀 구성 및 관리 시스템 도입이 중요합니다. **오픈소스 가버넌스**를 통해 기업 전반에서 오픈소스 라이선스를 준수하도록 체계적인 프로세스를 구축해야 합니다.
74+
75+
- **전담 팀 구성**: 법무팀과 기술팀이 협력하여 라이선스 변화를 추적하는 전담 팀을 구성합니다.
76+
- **오픈소스 가버넌스**: 기업 내부적으로 오픈소스 사용에 대한 명확한 정책과 가이드라인을 수립합니다.
77+
- **자동화 도구 활용**: 소프트웨어 구성 분석(SCA) 도구를 사용하여 사용 중인 오픈소스 컴포넌트와 라이선스를 자동으로 추적합니다.
78+
79+
80+
### 3.2 교육과 내부 가이드라인 마련
81+
기업 내부에서 오픈소스를 사용하는 개발자들이 라이선스 변경 사항을 이해하고 대응할 수 있도록 **교육****가이드라인**을 마련해야 합니다. 이를 통해 라이선스 위반으로 인한 법적 분쟁을 줄일 수 있습니다.
82+
83+
- **정기적인 교육 프로그램**: 개발자와 관리자를 대상으로 오픈소스 라이선스에 대한 정기적인 교육을 실시합니다.
84+
- **라이선스 가이드 제공**: 주요 오픈소스 라이선스의 특징과 준수 사항을 정리한 가이드를 제작하여 배포합니다.
85+
- **사내 전문가 양성**: 오픈소스 라이선스 전문가를 양성하여 내부 자문 역할을 수행하도록 합니다.
86+
87+
### 3.3 클라우드 환경에서의 AGPL-3.0 대응
88+
**클라우드 서비스**를 운영하는 기업들은 AGPL-3.0에 대한 법적 의무를 명확히 이해하고, 소스 코드 공개 요청에 대비할 수 있는 체계를 마련해야 합니다. 이러한 대응 전략에는 내부 검토 과정 강화와 대체 라이선스 고려가 포함될 수 있습니다.
89+
90+
- **내부 검토 강화**: 클라우드 서비스에 AGPL-3.0 소프트웨어를 도입하기 전 법적, 기술적 검토를 철저히 수행합니다.
91+
- **대체 솔루션 검토**: AGPL-3.0 라이선스의 제약이 부담스러운 경우, 대체 오픈소스 솔루션이나 상용 솔루션을 고려합니다.
92+
- **라이선스 준수 자동화**: 클라우드 환경에서 사용되는 소프트웨어의 라이선스 준수 여부를 자동으로 확인하는 시스템을 구축합니다.
93+
94+
---
95+
96+
## 결론: 오픈소스 라이선스 변화, 기업의 전략적 대응
97+
98+
99+
Elasticsearch가 다시 AGPL-3.0으로 돌아가는 결정은 오픈소스 생태계 내에서 큰 의미를 지닙니다. 이는 상업적 이익과 오픈소스 정신 간의 균형을 찾으려는 Elastic의 노력일 뿐만 아니라, 오픈소스를 사용하는 모든 기업에게도 중요한 시사점을 제공합니다.
100+
101+
기업은 오픈소스 라이선스의 변화에 적극적으로 대응해야 하며, 이를 통해 법적 리스크를 줄이고, 기술적 기회를 극대화할 수 있는 전략을 마련해야 합니다. AGPL-3.0과 같은 강력한 카피레프트 라이선스는 클라우드 시대에서 더욱 주목받을 것이며, 기업은 이에 맞춰 내부 시스템을 강화하고, 오픈소스 관리 체계를 발전시켜야 할 것입니다.
102+
103+
오픈소스 라이선스의 변화는 피할 수 없는 현실이지만, 이를 기회로 삼아 적절히 대응하는 기업은 경쟁 우위를 확보할 수 있습니다. 체계적인 오픈소스 관리 전략을 통해 법적 리스크를 최소화하고 기술적 이점을 극대화함으로써, 기업은 오픈소스 생태계 내에서 지속 가능한 성장을 이룰 수 있을 것입니다.
104+
105+
106+
---

0 commit comments

Comments
 (0)