오픈 소스 규정에는 성공을 위한 특별한 요구 사항이 있습니다. 오픈 소스 변호사가 고용주가 실행 가능한 진로를 찾는 데 어떻게 도움을 줄 수 있는지 알아보세요.
2부로 구성된 이 시리즈 중 1부 에서 공유 했듯이 저는 Red Hat의 오픈소스 변호사입니다. 내 업무에서 중요한 부분은 Red Hat이 엔터프라이즈급 제품을 구축하기 위해 완전 오픈소스 개발 모델을 채택하는 방법에 대한 정보를 사내 변호사를 포함하여 다른 회사에 제공하고 오픈소스 라이선스에 대한 일반적인 질문에 답변하는 것입니다. Red Hat의 성공 소식을 들은 후 이들 변호사들은 조직이 어떻게 오픈소스를 더 잘 인식하고 역량을 갖춘 조직으로 발전할 수 있는지에 관해 대화를 나누며, 오픈소스 제공에 더욱 능숙해지기 위해 어떻게 업무를 개선할 수 있는지 자주 묻습니다. 해당 조직의 직원에게 법적 조언을 제공합니다. 이 두 기사에서는 이러한 주제에 관해 사내 변호사에게 일반적으로 말하는 내용을 공유하겠습니다.
항상 가능한 길을 찾아라
저의 고용주인 Red Hat이 오픈 소스 소프트웨어를 사용하는 방식이 독특한 이유는 우리의 개발 모델이 수천 명의 기여자가 있는 오픈 소스 커뮤니티에서 시작하여 시험, 테스트 및 신뢰할 수 있는 최종 제품이 탄생한다는 것입니다. 보다 구체적으로, 우리는 고유한 개발 모델을 통해 커뮤니티에서 만든 오픈 소스 소프트웨어로 시작하여 각 프로젝트에 대해 작업하여 보안을 강화하고, 버그를 수정하고, 취약점을 패치하고, 새로운 기능을 추가합니다. 그런 다음 이러한 개선 사항을 각 프로젝트에 다시 제공하여 전체 오픈 소스 커뮤니티에 도움이 되도록 합니다. 이 접근 방식의 이점은 중요하며 다음과 같습니다.
- 내부 팀과 조직 외부 사람들 간의 협업을 통해 외부 혁신을 활용합니다.
- 기존 또는 잠재적 커뮤니티가 귀하와 동일한 문제를 해결하고 협력할 수 있으면 오픈 소스 솔루션을 직접 개발하고 유지 관리하는 데 따른 비용과 비효율성을 피할 수 있습니다.
- 파트너 및 업스트림 프로젝트 커뮤니티와의 생산적인 협업을 통해 메인 프로젝트의 다운스트림 분기에 대한 비용이 많이 드는 유지 관리를 피할 수 있습니다.
- 일부 회사에서는 특정 사용 사례를 해결하는 빠른 방법이거나 커뮤니티에서 협력할 의사가 없기 때문에 업스트림 코드의 비공개 분기를 만들고 싶은 유혹을 느낍니다. 그러나 이러한 분기의 장기적인 유지 관리 부담은 개발 비용 증가, 상호 운용성 손실 및 기타 이유로 인해 감당하기 어려울 수 있습니다. 대조적으로, 원래의 업스트림 커뮤니티에서 개발을 중앙 집중화하면 개발 비용이 모든 참가자에게 분산됩니다.
몇 가지 예외(예: Red Hat)를 제외하고 오픈 소스 소프트웨어를 사용하는 대부분의 조직은 독점 소프트웨어 라이센싱 모델(또는 이에 상응하는 SaaS)을 보유하고 비즈니스의 일부로 독점 소프트웨어 라이센스를 보유할 가능성이 높습니다. 이러한 조직은 경쟁 우위를 제공하는 소프트웨어 구성 요소가 있다고 믿고 있으며 이러한 구성 요소가 오픈 소스 조건에 따라 다른 사람에게 제공되는 것을 원하지 않습니다. 이것은 이해할 수 있습니다. 그러나 나는 그러한 문제에 대해 상담을 받은 오픈 소스 변호사가 고객에게 특히 차별화되지 않고 일반적인 모든 소프트웨어에 대해 오픈 소스 개발 모델을 채택하도록 촉구할 것을 권장합니다.
예를 들어, 회사에서 휴대폰용 애플리케이션을 개발하고 PNG 이미지 파일을 읽고 쓰기 위한 소프트웨어 모듈이 필요한 경우 GitHub에서 인기 있는 오픈 소스 PNG 소프트웨어 모듈 중 하나를 사용하는 것이 훨씬 저렴할 것입니다. PNG 이미지를 인코딩하고 디코딩하는 것은 귀하의 비즈니스에서 구별하기 어려울 수 있습니다. 그렇다면 자신만의 버전을 작성하는 데 귀중한 엔지니어링 시간을 소비할 이유가 무엇입니까? 또한 이 기능을 위해 자체 모듈을 작성하면 일반적으로 사용 가능한 오픈 소스 모듈을 사용하는 다른 소프트웨어와의 호환성 문제가 발생할 수도 있습니다. 왜 이런거야? 게시된 PNG 사양을 인코딩 및 디코딩하기 위해 모듈과 오픈 소스 모듈이 작성되었을 수 있지만 때로는 사양이 다르게 해석되어 구현 오류가 발생할 수 있습니다. 이 기능을 수행하기 위해 동일한 모듈을 사용하는 모든 사람은 대다수 사용자의 호환성을 보장하고 개발 및 유지 관리 비용을 절감합니다.
일부 소프트웨어는 독점 상태를 유지하고 오픈 소스 조건의 적용을 받지 않기 위해 필요할 수도 있다는 점을 인식하는 것도 중요합니다. 시스템의 소프트웨어 아키텍처 및 사용된 오픈 소스 라이선스에 따라, 독점으로 유지되도록 의도된 소프트웨어 코드는 특정 조치(이 문서의 범위를 벗어나는)를 취하지 않는 한 오픈 소스 라이선스 조건의 적용을 받을 수 있습니다. 라이선스 선택 및 아키텍처와 관련하여 고객에게 일부 컨설팅 서비스를 제공하는 것이 유용한 곳입니다.
유연한 솔루션 찾기
이전에 독점 소프트웨어 라이선스를 주로 사용했던 조직에서는 오픈 소스 소프트웨어의 사용이 점차 증가하고 있지만 검토 및 승인에 대한 요구 사항은 증가할 가능성이 높습니다(내 경험으로는 기하급수적으로 증가할 수도 있음). 이러한 조직은 리소스 제약으로 인해 어려움을 겪을 수 있습니다. 채택할 수 있는 몇 가지 유연한 솔루션은 다음과 같습니다.
다른 사람에게 승인 및 위임
변호사는 문지기가 될 수도 없고, 그래서도 안 됩니다. 이는 비효율적이며 개발 및 출시 시간에 병목 현상이 발생하여 좌절감과 수익 손실이 발생하게 됩니다. 대신, 제품이나 프로젝트 관리 및 엔지니어링 분야의 유능한 개인에게 승인 권한이 부여되어야 합니다. 이를 통해 조직은 효과적으로 유연성을 유지할 수 있습니다. 이를 성공적으로 달성하려면 고객을 교육하는 것이 중요합니다(다음 섹션 참조).
제가 취하는 한 가지 접근 방식은 전체 엔지니어링 조직에 오픈 소스 교육을 제공하여 기본 라이선스 모델 및 아키텍처를 선택할 수 있도록 하는 동시에 소프트웨어 개발자에게는 보다 복잡한 지침과 결정을 제공할 수 있도록 보다 전문적인 교육을 제공하는 것입니다. 또한 오픈 소스 변호사에게 에스컬레이션해야 하는 문제 및 결정 유형을 포함하여 각 수준의 권한에 대한 명확한 제한을 고려하세요. 조직의 특정 인증 수준은 오픈 소스에 대한 팀의 경험과 특정 오픈 소스 문제에 대한 민감도에 따라 달라집니다.
고객 교육
저는 교육이 귀하의 조직을 보다 오픈 소스 지향적인 조직으로 마이그레이션하는 데 가장 효과적인 도구 중 하나라는 것을 알았습니다. 소프트웨어 엔지니어와 제품 관리자를 교육하는 것이 중요합니다. 자세히 설명하겠습니다.
소프트웨어 엔지니어가 최첨단에 있고 일반적으로 오픈 소스 문제 및 소프트웨어 라이선스에 대해 매우 잘 알고 있을 수 있지만 조직의 특정 요구 사항에 따라 교육하는 것은 여전히 중요합니다. 예를 들어, 귀하의 회사는 허용된 오픈 소스 라이선스의 사용만 허용할 수 있으며 저작권 고지 및 소스 코드 가용성에 대한 특정 요구 사항이 있을 수 있습니다. 나중에 수정해야 하는 개발 문제(비용과 시간이 많이 소요됨)를 방지하려면 특히 개발 프로세스 초기에 부적절한 행동이 발생할 가능성을 최소화하도록 엔지니어를 교육하는 것이 가장 좋습니다(다음 섹션 참조).
제품 관리자도 교육을 받아야 합니다. 많은 기업에서 제품 관리자는 마케팅의 전통적인 4가지 측면(제품, 가격, 포지셔닝, 판촉)을 담당하고 요람에서 무덤까지 제품의 전체 수명 주기를 담당합니다. 제품 관리자 업무의 모든 측면은 오픈 소스 소프트웨어 사용에 의해 영향을 받을 수 있습니다. 위에서 언급한 것과 같은 이유로 오픈 소스 소프트웨어 사용에 대한 요구 사항을 이해하는 것이 유용합니다. 또한, 더 중요한 것은 제품 관리자가 조직 내에서 상당한 영향력을 발휘한다는 것은 그들이 종종 프로세스와 정책에 필요한 변경을 할 수 있다는 것을 의미합니다. 제품 관리자는 개방성을 위한 프로세스 변경을 가장 강력하게 옹호하는 사람 중 한 명이 될 수 있습니다.
조기 발견
개발 프로세스가 끝날 무렵 오픈 소스 라이선스 문제를 해결하는 것은 어렵고 비용이 많이 듭니다. 소프트웨어 출시일이 가까워짐에 따라 아키텍처와 오픈 소스 소프트웨어 모듈이 선택되고 변경이 어렵습니다. 독점 소프트웨어 모듈에 내장된 "카피레프트" 소프트웨어(해당 독점 모듈이 오픈 소스 용어를 따르지 않는 경우)와 같은 문제가 감지되면 이 개발 단계에서 아키텍처나 모듈을 수정하는 것이 어렵고 비용이 많이 들 수 있습니다. 값비싼. 대신, 아키텍처 분석 및 오픈 소스 모듈 선택 프로세스가 개발 프로세스 초기에 이루어져야 비용이 적게 들고 보다 효과적인 수정이 이루어질 수 있습니다.
오픈소스 규제의 “보상”
오픈 소스 규제를 실천하는 것은 "개방형" 방향으로 조직에 영향을 미치는 능력이 큰 이점을 갖기 때문에 보람 있는 직업입니다. 성공은 조직이 성장하고 성숙함에 따라 실행 가능하고 유연한 솔루션을 찾는 능력에 달려 있습니다.
저자 소개: Jeffrey R. Kaufman은 세계 최고의 오픈 소스 소프트웨어 솔루션 제공업체인 Red Hat의 오픈 소스 법률 팀의 수석 비즈니스 법률 고문이며, 노스캐롤라이나 대학교의 법학 겸임 교수이기도 합니다. Red Hat에 합류하기 전에 Jeffrey는 Qualcomm에서 특허 및 오픈소스 자문위원으로 근무했습니다.
번역가 프로필: Jihuizhijia Intellectual Property Consulting Company의 인터넷 비즈니스 부서 이사인 Xue Liang은 특허 분석, 특허 레이아웃, 경쟁사 추적, FTO 분석 및 오픈 소스 소프트웨어 지적 재산권 위험 분석에 능숙합니다. 그는 인터넷 회사에 서비스를 제공하기 위해 최선을 다하고 있습니다. 지적재산권 컨설팅 서비스를 제공하는 하이테크 기업입니다.
