1.
페어 소스.
처음 본 단어입니다. 무슨 뜻인지 찾아보았습니다. Software Sharing for Modern Businesses가 정의하는 정의입니다.
Fair Source Definition
Fair Source is an alternative to closed source, allowing you to safely share access to your core products. Fair Source Software (FSS):
- is publicly available to read;
- allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model; and
- undergoes delayed Open Source publication (DOSP).
한국저작권위원회가 발간하는 [제2024-21호] 페어소스(Fair Source) 라이선스의 등장는 다음과 같이 번역합니다.
① 코드를 누구나 볼 수 있어야 하고,
② 제3자가 ‘최소한의 제한’을 두고 사용, 수정, 재배포할 수 있어야 하며,
③ 미리 정해진 기간이 지나면 오픈소스 라이선스로 전환되는 지연된 오픈소스 공개(delayed open sourcepublication, DOSP)* 규정이 있어야 함
위 보고서는 Fair Source에 대해 자세하게 소개하고 있습니다.
2.
GitButler의 창업자중 하나인 Scott Chacon은 페어 소스운동에 참여하고 있습니다. “왜 참여하는지”에 대하여 The Future of Open Source에서 자세히 소개하고 있습니다. 우리 말로 정리한 글은 오픈 소스의 미래에서 자세히 읽을 수 있습니다. 아래는 일부 번역입니다.
오픈소스의 간략한 역사
경업 금지 조항이 포함된 일반적으로 허용되는 라이선스 하에서 공개 소프트웨어에 “오픈 소스”라는 표현을 사용하는 것에 대해 사람들이 왜 그렇게 화를 냈는지 설명하기 위해, 오늘날의 상황을 살펴보기 전에 “오픈 소스”라는 표현의 역사를 간략히 살펴봅시다.
자유 소프트웨어의 초기
50년대와 60년대 반접근형 컴퓨팅의 태동기에 소프트웨어는 대부분 방 전체를 차지하는 고가의 컴퓨팅 하드웨어와 함께 번들로 제공되었습니다. 소프트웨어는 하드웨어와 불가분의 관계에 있었기 때문에 분리하는 것이 사실상 의미가 없었습니다. 거의 모든 소프트웨어가 오픈 소스였던 마법 같은 시대였으니까요.소프트웨어는 그 자체로는 가치가 없었기 때문에 하드웨어 회사에서 공개적으로 사용할 수 있고 자유롭게 배포할 수 있었습니다. 수정이 이루어진 후 다시 하드웨어 회사로 보내져 재배포되는 경우가 많았는데, 이는 오늘날 우리가 보게 될 협업의 초기 선구적인 모습입니다.
코드의 폐쇄와 소프트웨어 회사의 부상
70년대와 80년대에 하드웨어가 더욱 보편화되고 상호 운용이 가능해지면서 소프트웨어는 그 자체로 가치를 인정받기 시작했습니다. 소프트웨어 전문 회사가 생겨났고 사람들은 전문 소프트웨어를 구매하기 시작했습니다. 소프트웨어는 그 자체로 고유한 가치를 가지기 시작했습니다. 이러한 가치로 인해 IBM, AT&T 등 대형 하드웨어 회사들은 값비싸게 생산한 소스 코드를 무료로 배포하는 대신 소스 코드에 대한 접근을 차단하기 시작했습니다.
자유 소프트웨어의 탄생
이로 인해 더 이상 운영 체제 및 기타 도구를 배우고 실험할 수 없게 된 리차드 스톨만과 같은 애호가와 학자들은 이와 같은 기업의 이익으로부터 보호되는 자체 운영 체제와 도구를 구축하기 시작했습니다. 실제로 이들은 GPL과 같은 상호 라이선스를 만들어 IBM과 AT&T가 자신들이 만든 것을 사용할 수 없도록 하고, 그렇지 않으면 자신들이 사용하는 모든 것을 자유 소프트웨어로 만들도록 강요하기까지 했습니다. 우리가 여러분의 장난감을 가지고 놀지 못하면 여러분도 우리의 장난감을 가지고 놀 수 없습니다.그들은 이 운동을 “자유 소프트웨어”라고 명명하고, 오늘날에도 대부분의 현대 컴퓨팅의 기본이 되는 도구인 Emacs와 GNU 컴플라이어 시스템과 같은 놀라운 도구를 많이 만들었습니다.자유 소프트웨어 운동의 근본적인 초점은 사용자가 소프트웨어를 실행, 복사, 배포, 연구, 변경 및 개선할 수 있는 자유를 보장하는 것이었습니다. 당시 소프트웨어를 둘러싼 기업의 이해관계에 의해 빼앗긴 자유를 되찾자는 것이었습니다.
GNU/Linux의 부상
하지만 90년대 초, 라이너스 토발즈가 허드(Hurd) GNU 커널을 대체할 수 있는 리눅스 커널을 선보이기 전까지 완전한 운영체제는 없었습니다. 이제 GNU/Linux와 이 소프트웨어를 지속적으로 공개적으로 개선하는 재능 있는 개발자들이 늘어나면서 지난 10년 동안 컴퓨팅을 지배했던 독점 운영체제에 대한 진정한 대안이 생겼습니다.
(여기서 시간 감각을 익히기 위해 1991년 이 무렵에 최초의 웹사이트가 온라인에 등장했습니다.)
90년대 후반에는 개인은 물론 기업에서도 놀라운 것을 만들 수 있는 무료 소프트웨어 도구의 전체 생태계가 형성되었습니다. LAMP(Linux, Apache, MySQL, PHP/Perl) 스택이 점점 더 많이 사용되었고 의존도가 높아졌습니다. 자유 소프트웨어는 점점 더 많은 성공적이고 성장하는 기업의 기반이 되기 시작했습니다.
오픈소스의 탄생
1997년에 에릭 레이몬드는 “대성당과 바자르”라는 제목의 에세이를 발표하여 Linux와 같은 자유 소프트웨어 프로젝트가 구축되는 방식이 하향식 독점 개발 방식보다 본질적으로 더 나은 소프트웨어 개발 모델이라는 주장을 펼쳤습니다. 그 후 넷스케이프는 이 글을 인용하여 모질라 프로젝트가 된 네비게이터 스위트의 소스 코드를 공개하는 정당성을 주장했습니다.넷스케이프가 소스 코드를 공개하기로 결정했을 때, 팔로알토에서 열린 전략 세션에서 레이몬드와 몇몇 저명한 Linux 및 자유 소프트웨어 개발자들은 “오픈 소스”라는 새로운 용어를 만들어 사용하기로 합의했습니다.
회의 참석자들은 넷스케이프가 코드를 공개하도록 동기를 부여한 실용적이고 비즈니스적인 근거가 잠재적인 소프트웨어 사용자 및 개발자와 소통하고 커뮤니티에 참여하여 소스 코드를 만들고 개선하도록 설득할 수 있는 가치 있는 방법이라고 믿었습니다. 회의 참석자들은 또한 이러한 접근 방식을 철학적, 정치적으로 초점을 맞춘 “자유 소프트웨어”라는 라벨과 구별할 수 있는 단일 라벨이 있으면 유용할 것이라고 믿었습니다. – (오픈 소스의 역사)
중요한 것은 “자유 소프트웨어”와 “오픈 소스” 사이에는 실질적인 법적 또는 실용적인 차이가 없으며, 대부분의 라이선스는 두 정의 모두에서 호환되고 받아들여진다는 점입니다. “오픈 소스”는 넷스케이프와 같은 더 많은 회사가 전문 소스 코드의 개방을 수용하도록 하기 위한 스톨만과 그의 운동의 보다 정치적인 목표와 소프트웨어 개방의 실용성을 분리하기 위해 비즈니스 친화적으로 브랜드를 변경한 것일 뿐입니다.
또는 자유 소프트웨어 사람들의 표현을 빌리자면:
“오픈소스는 개발 방법론이고 자유 소프트웨어는 사회 운동입니다.”오픈 소스와 깃허브 시대
“오픈 소스”라는 문구가 정의되고 마케팅에 사용된 것은 1998년으로 지금으로부터 25년 전입니다. 그렇다면 컴퓨팅의 지난 25년 동안 오픈 소스와 소프트웨어 개발의 세계에서는 어떤 일이 일어났을까요?물론 저는 편견이 심한 편에 속하지만(공동 창립자 중 한 명이었습니다), 지난 10년 동안 오픈 소스 소프트웨어 세계에서 GitHub와 GitHub 스타일의 소프트웨어 개발이 경이로운 영향을 미쳤다는 의견에 객관적으로 동의하기는 어렵다고 생각합니다.
가장 큰 변화는 1998년의 사고방식에서 점진적으로 변화하고 있다는 점입니다. 당시에는 퍼머시브 라이선스 소프트웨어를 개발하는 개발자들이 기업이 오픈 소프트웨어를 수용하도록 설득하는 데 도움이 되는 문구를 만들려고 애쓰고 있었습니다. 오늘날 거의 모든 오픈 소스 소프트웨어는 기업이 작성하거나 기업에서 자금을 지원합니다.
예전에는 자유 소프트웨어가 ‘사람’에게만 의존하는 것이었지만 오늘날에는 거의 모든 자유 소프트웨어를 ‘사람’이 생산합니다.
한 가지 큰 변화는 개발 워크플로우의 표준화라고 생각하는데, 이는 주로 GitHub가 주도하고 정의하고 전파한 것입니다. GitHub 이전에는 공개 소프트웨어 프로젝트에서 작업하는 방식과 기업의 독점 소프트웨어 프로젝트에서 작업하는 방식에 항상 큰 차이가 있었습니다. 방법론, 도구 및 워크플로도 두 가지 개발 유형 간에 크게 달랐죠.
하지만 오늘날에는 내부 폐쇄형 프로젝트와 오픈 소스 프로젝트의 팀 작업 방식에 거의 차이가 없는 경우가 많습니다.
-모두가 Git을 사용합니다.
-거의 모든 사람들이 Pull 리퀘스트(또는 Merge 리퀘스트 또는 이 기능을 복제하는 다른 경쟁사)를 사용합니다.
-대부분의 팀은 어떤 형태의 GitHub 플로우(트렁크 기반 개발, Gitlab 플로우 등)를 사용합니다.오늘날에는 리포지토리의 공개 비트가 설정되어 있는지, 설정되어 있지 않은지가 거의 유일한 차이점입니다. 25년 전에는 전혀 그렇지 않았고, 프로세스 간에 많은 마찰이 있었으며 프로세스가 크게 달랐습니다. 이제 오픈소스를 사용하려면 프로세스에는 거의 변화가 없고 가시성만 달라집니다.
오픈 소스의 다음 단계
‘오픈 소스’ 마케팅 접근 방식이 매우 성공적이어서 거의 모든 기업이 오픈 소스 소프트웨어를 사용하고 생산하고 있는 지금, 오픈 소스(그리고 자유 소프트웨어) 운동은 승리한 것일까요? 싸움은 끝난 걸까요? 더 싸울 것이 남아 있을까요?글쎄요, 현재 오픈소스 세계에는 두 가지 큰 이슈가 있습니다. 두 가지 이슈는 모두 기업 오픈소스 운동의 성공으로 인해 생겨난 문제입니다. 오픈소스의 성공은 완전히 새로운 도전을 가져왔습니다.첫 번째는 개발자의 지속 가능성에 관한 문제이고, 두 번째는 상용 오픈소스의 실행 가능성 문제입니다. 자세히 살펴보겠습니다.
개발자의 지속 가능성 문제
거의 모든 영리 기업이 오픈소스에 크게 의존하고 있는 지금, 우리는 지속 가능성과 유지 관리 문제에 직면하고 있습니다.이러한 문제는 이전에는 실제로 대규모로 존재하지 않았던 문제입니다. 최근의 유명한 사례로는 오픈 소스 관리자가 악의적인 공격자의 미묘하지만 중대한 타협을 받아들인 XZ Utils 백도어 익스플로잇이 있는데, 이는 부분적으로는 관리자의 번아웃과 괴롭힘으로 인해 발생했습니다.
하지만 제가 만나는 거의 모든 관리자에게서 이런 일이 벌어지고 있습니다.여러 가지 요인으로 인해 오픈소스 소프트웨어를 작성하고 유지 관리하여 돈을 버는 것은 거의 불가능합니다. 누구나 공짜를 원하고 기대하지만, 이 모든 것을 가능하게 하는 사람들을 지원해야 한다고 생각하는 사람은 아무도 없습니다.
이상하게도 대부분의 오픈 소스 개발자와 유지 관리자가 대기업의 후원을 받고 있다는 새로운 사실이 밝혀졌습니다.Linux, Git, Ruby, React 등 거의 모든 중요한 오픈 소스 프로젝트를 보면 기여자의 상당수 또는 대부분이 GitHub, Microsoft 또는 Red Hat과 같은 기업의 후원자에 의해 전문적으로 고용되어 있습니다.
소프트웨어 개발자가 XZ Utils와 같은 프로젝트를 유지 관리하여 생계를 유지할 수 있는 좋은 메커니즘은 거의 없습니다.더 이상적인 것은 기업의 KPI와 경영진의 변덕에 따라 달라지는 한 회사가 각 개발자에게 돈을 지불하는 것이 아니라, 수천 명의 개발자가
최근의 유명한 예로, 오픈소스 관리자가 악의적인 공격자의 미묘하지만 중대한 타협을 받아들인 XZ Utils 백도어 익스플로잇이 있는데, 이는 부분적으로는 관리자의 번아웃과 괴롭힘으로 인한 것이었습니다.하지만 제가 만나는 거의 모든 관리자에게서 이런 일이 벌어지고 있습니다. 여러 가지 요인으로 인해 오픈소스 소프트웨어를 작성하고 유지 관리하여 돈을 버는 것은 거의 불가능합니다.누구나 공짜를 원하고 기대하지만, 이 모든 것을 가능하게 하는 사람들을 지원해야 한다고 생각하는 사람은 아무도 없습니다.
이상하게도 대부분의 오픈 소스 개발자와 유지 관리자가 대기업의 후원을 받고 있다는 새로운 사실이 밝혀졌습니다. Linux, Git, Ruby, React 등 거의 모든 중요한 오픈 소스 프로젝트를 보면 기여자의 상당수 또는 대부분이 GitHub, Microsoft 또는 Red Hat과 같은 기업의 후원자에 의해 전문적으로 고용되어 있습니다.
소프트웨어 개발자가 XZ Utils와 같은 프로젝트를 유지 관리하여 생계를 유지할 수 있는 좋은 메커니즘은 거의 없습니다. 더 이상적인 것은 한 회사가 각 개발자에게 비용을 지불하는 것이 아니라, 기업의 KPI와 경영진의 변덕에 따라 수천 개의 회사가 전문 유지 관리자에게 아주 적은 금액을 지불하는 것입니다.가장 큰 문제는 현재로서는 이를 수행할 수 있는 좋은 방법이 없다는 것입니다. 기업이 이를 수행할 인센티브가 거의 없으며 이러한 자금을 모으고 분산할 수 있는 방법도 거의 없습니다.
GitHub 스폰서, Thanks.dev, Liberapay, Tidelift와 같은 유망한 이니셔티브가 있지만, 아직 기업이 기여할 수 있는 적절한 인센티브를 제공하는 문제를 실제로 해결한 것은 없습니다. 대부분 “이것은 옳은 일입니다”라는 자선 단체의 호소만 있을 뿐, 이런 운동에 필요한 동력을 얻지 못할 것 같습니다.센트리는 OSS 서약이라는 새로운 이니셔티브를 준비 중이며, 10월에 시작되면 깃버틀러도 참여할 계획이지만, 오픈소스 생태계에서 개발자의 지속 가능성이라는 크고 점점 커지는 문제를 해결할 수 있을지는 아직 미지수입니다.
상용 오픈소스의 문제
오픈소스 생태계에서 두 번째로 커지고 있는 문제는 차세대 상용 오픈소스의 문제입니다.
개발자들은 수십 년 동안 오픈소스와 오픈 커뮤니티를 사랑하며 성장해 왔고, 회사나 프로젝트를 시작할 때 기본적으로 오픈소스를 원합니다.그러나 오픈소스에는 개인 관리자와 마찬가지로 기업의 지속 가능성 문제가 있습니다. 그러나 오픈 소스에는 개인 유지 관리자와 마찬가지로 기업의 지속 가능성 문제가 있습니다.Elasticsearch와 Redis와 같은 사례에서 보았듯이, Amazon이 호스팅하거나 다른 대형 플레이어가 자신의 작업을 사용하여 직접적으로(그리고 어떤 면에서는 불공정하게) 경쟁할 수 있는 ‘제프’가 될 위험이 있을 때 전문적으로 소프트웨어를 개발하는 데 시간과 돈, 경우에 따라서는 투자금을 쏟아붓는 것은 위험합니다.직원과 투자자를 걱정해야 하는 많은 전문 제작자는 소프트웨어에 시간과 피와 보물을 투자하고 나중에 이를 빼앗겨 자신에게 불리하게 사용되지 않도록 하기를 원합니다. 많은 사람들에게 이는 라이선싱에 대해 창의력을 발휘하는 것을 의미하며, 더 많은 사람들에게는 단순히 소스 코드를 비공개로 유지하는 것을 의미합니다.다소 아이러니하게도 더 맨은 이제 오픈 소스 라이선스를 사용하여 개발자에게 이를 고수하고 있습니다!
저는 페어 소스 운동이 지난 몇 년 동안 점점 더 많은 문제와 혼란을 야기했던 오픈 소스 생태계의 공백을 메울 수 있는 훌륭하고 필요한 해결책이라고 믿습니다. 이는 대부분 허용되고 소스를 사용할 수 있으며 GitHub 커뮤니티가 참여하는 전문 프로젝트를 지칭하는 새로운 용어를 제공하며, 이전에 비공개로 진행되었던 더 많은 프로젝트가 공개적으로 공개되도록 장려하는 절실히 필요한 해결책이라고 생각합니다.
상업용 오픈소스의 문제
오픈소스 생태계에서 두 번째로 커지고 있는 문제는 새로운 세대의 상용 오픈소스의 문제입니다.
개발자들은 수십 년 동안 오픈소스와 오픈 커뮤니티를 사랑하며 성장해 왔고, 회사나 프로젝트를 시작할 때 기본적으로 오픈소스를 원합니다. 그러나 오픈소스에는 개인 관리자와 마찬가지로 기업의 지속 가능성 문제가 있습니다.
Elasticsearch와 Redis 같은 사례에서 보았듯이, Amazon이 호스팅하거나 다른 대형 플레이어가 자신의 작업물을 사용해 직접적으로(그리고 어떤 면에서는 불공정하게) 경쟁할 수 있는 ‘제프’가 될 수 있는 위험이 있을 때 전문적으로 소프트웨어를 개발하는 데 시간과 돈, 경우에 따라 투자금을 쏟아붓는 것은 위험할 수 있습니다.직원과 투자자를 걱정해야 하는 많은 전문 제작자는 소프트웨어에 시간과 피와 보물을 투자하고 나중에 이를 빼앗겨 자신에게 불리하게 사용되지 않도록 하기를 원합니다. 많은 사람들에게 이는 라이선싱에 대해 창의력을 발휘하는 것을 의미하며, 더 많은 사람들에게는 단순히 소스 코드를 비공개로 유지하는 것을 의미합니다.
다소 아이러니하게도 더 맨은 이제 오픈 소스 라이선스를 사용하여 개발자에게 이를 고수하고 있습니다!
저는 페어 소스 운동이 지난 몇 년 동안 점점 더 많은 문제와 혼란을 야기했던 오픈 소스 생태계의 공백을 메울 수 있는 훌륭하고 필요한 해결책이라고 믿습니다. 이는 대부분 허용되고, 소스를 사용할 수 있으며, GitHub 커뮤니티가 참여하는 전문 프로젝트를 지칭하는 새로운 용어를 제공하며, 이전에 비공개로 진행되었던 더 많은 프로젝트가 공개적으로 공개되도록 장려하는 절실히 필요한 해결책이라고 믿습니다.
The Future of Open Source중에서
소프트웨어 개발을 주업으로 하는 개인이나 회사는 오픈소스와 페어소스 혹은 비공개소스로 다양한 선택을 할 수 있을 듯 합니다. 다만 이를 도입하여 사용하는 회사들은 이래저래 복잡하네요. 관리가 늘어나지 않을까요? 아직은 페어소스에 참여하는 회사가 적은데 획기적으로 늘어나면…
