▲

Open Source Resistance: 회사 업무 시간에 OSS를 계속 살려두기

 (ossresistance.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • Open Source Resistance는 회사가 의존하는 OSS 유지보수를 야간·주말 취미가 아니라 업무 시간의 인프라 작업으로 다루자고 제안함
  • 유지보수자는 회사와 연결된 OSS에서 PR 리뷰, 의존성 업데이트, 수정 배포를 하되 계약·기밀·IP 소유권을 먼저 확인해야 함
  • Open Source Pledge의 개발자당 연 US$2,000 지급, Open Source Friday의 금요일 2시간 기부보다 더 직접적인 실행을 내세움
  • “시간 절도”라는 반론에는 회사가 이미 무료 OSS 보조금을 받아 왔고, 의존 OSS 유지보수는 공유 인프라 작업이라고 답함
  • Mike McQuaid는 Homebrew 유지보수를 계속하며 IP 계약을 협상했고, 자녀가 생긴 뒤 OSS 작업의 90% 이상을 업무 시간에 했다고 밝힘

OSS 유지보수는 업무 시간의 인프라 작업

  • Open Source Resistance는 회사가 의존하는 오픈소스 소프트웨어(OSS) 유지보수를 야간·주말 취미로 밀어내지 말고, 조용하고 전문적으로 업무 시간에 수행하자는 직접 행동 제안임
  • 회사는 OSS에서 매시간 가치를 얻지만, 유지보수자는 금요일 오후 시간, 기부 버튼, 전사 미팅의 칭찬에 의존하게 되는 구조가 만들어졌다고 봄
  • 회사가 이미 의존하는 OSS 작업은 인프라와 기술 부채 작업처럼 다룰 수 있으며, 별도 서류·내부 프로그램·관리자 허락을 기다릴 필요가 없다는 입장임
  • 많은 오픈소스는 회의, 스프린트, 제품 관리자 지시 없이도 유지보수자들이 인터넷의 기반을 지켜 온 방식으로 굴러왔음

행동 원칙

  • 자신을 보호하기

    • 고용계약을 확인하고, 기밀 정보는 회사 안에 두며, 공개하려는 오픈소스 지식재산권(IP)을 자신이 소유하는지 확인해야 함

  • 필요한 일을 하기

    • 업무와 이미 연결된 OSS에서 PR 리뷰, 의존성 업데이트, 수정 배포를 수행함

  • 무리하지 않기

    • 업무 시간의 100%를 OSS에 쓰고 해고된 뒤 남 탓하지 말아야 하며, 핵심은 균형이지 회사 시간 남용이 아니라고 못박음

기존 대안과 차이

  • Open Source Pledge는 회사가 유지보수자에게 개발자 1명당 연 US$2,000을 지급하도록 요구함
  • Open Source Friday는 회사가 매주 금요일 최소 2시간을 오픈소스에 기부하도록 요구함
  • 정중한 경로를 택해 먼저 고용주를 설득하는 방식도 가능하며, 모두 생태계에 긍정적이고 지지할 가치가 있다고 봄
  • Open Source Resistance는 그 다음 단계로, 의존성 체인 유지보수가 경영진이 이름 붙이기를 거부하더라도 이미 업무의 일부라고 선언함
  • 회사가 예산을 어떻게 쓰는지는 개인이 통제하기 어렵지만, 자신이 업무 시간을 어떻게 쓰는지는 통제할 수 있다고 봄

예상 반론과 답변

  • “시간 절도, 해적질, 주주에게서 훔치는 일이다”

    • 회사는 매일 오픈소스 유지보수자에게서 가치를 얻고 있으며, 주주들은 수십 년 동안 무료 오픈소스 보조금을 받아 왔다고 봄
    • 고용주가 OSS에 의존한다면 이를 유지보수하는 일은 공유 기반에 대한 인프라 작업이지 절도가 아니며, 회사의 핵심 OSS는 유지보수자의 삶의 지속 가능성과도 연결됨

  • “허락을 받아야 한다”

    • 허락을 구하는 방식은 권력 불균형을 유지하며, 고용주가 의존하는 인프라를 유지하는 데 관리자 축복이 필요하지 않다고 봄

  • “조용한 퇴사일 뿐이다”

    • 조용한 퇴사는 일을 덜 하는 것이지만, 여기서는 인터넷이 기반으로 삼는 OSS 인프라를 생산한다고 구분함
    • 문제는 작업 자체가 아니라 회사가 이를 업무로 분류하기를 거부하는 데 있다고 봄

  • “좋은 고용주도 피해를 본다”

    • 좋은 고용주는 업무 시간의 오픈소스 유지보수를 허용하거나, 유지보수자에게 자금을 지원하거나, Open Source Pledge에 참여해 문제를 피할 수 있음
    • 이런 방식은 생태계에 좋지만, 오늘 자신의 프로젝트가 유지보수되지 않을 수 있으므로 직접 할 수 있다고 봄

Mike McQuaid의 배경과 실천

  • Mike McQuaid는 GitHub에서 Open Source Friday와 GitHub Sponsors를 공동 창안했고, Homebrew Project Leader이자 2009년부터 Homebrew 유지보수자였음
  • 그는 어떤 직장에서도 Homebrew 같은 자신의 오픈소스 프로젝트를 주 업무로 하도록 급여를 받은 적은 없지만, 매 고용주 아래에서 계속 유지보수했다고 밝힘
  • 이를 정당하게 만들기 위해 IP 계약을 협상했고, 업무 약속도 지켰다고 밝힘
  • 자녀가 생긴 뒤 그의 오픈소스 작업 중 90% 이상은 업무 시간에 이루어졌음
  • Open Source Maintainers Owe You Nothing에서처럼, 어떤 회사의 비즈니스 모델이 자신의 코드에 의존한다는 이유로 누구도 유지보수자의 무급 야간·주말·가족 시간을 요구할 권리는 없다고 봄

주의점과 법적 한계

  • 법률 조언이 아님

    • 이 내용은 법률 조언이 아니며, 계약·고용주·이민 신분·라이선스 의무·개별 상황에 대한 조언이 아니라고 명시함
    • 위험이 크다면 행동하기 전에 자격 있는 사람과 상담해야 함
    • 대부분의 오픈소스 라이선스처럼 어떠한 보증도 없으며, “있는 그대로” 제공됨

  • 계약, 정책, 소유권

    • 고용계약, 핸드북 정책, 발명 양도 조항은 고용 중 생성된 작업, 고용주 장비에서 만든 작업, 담당 업무 범위 안의 작업에 대해 권리를 주장할 수 있음
    • 일부 주에서는 개인 시간과 개인 장비로 만든 작업에 대한 이런 권리 주장을 제한하지만, 세부사항이 중요함
    • 실행하기 전에 고용계약을 읽고, 공개하려는 오픈소스 IP를 고용주가 소유하지 않는지 확인해야 함
    • 기기, 네트워크, 계정이 소유권 위험을 바꾼다면 자신의 것을 사용해야 함

  • IP 계약 협상

    • IP 양도는 종종 협상 가능하며, 채용 제안을 받을 때 서명 전에 오픈소스 예외 조항을 서면으로 요청하라고 권함
    • 먼저 직원 IP 계약을 읽어 어떤 부분에 반대해야 할지 알아야 함
    • Mike McQuaid는 거의 모든 고용주와 표준 계약에서 벗어난 변경을 협상했으며, 대부분 예상보다 훨씬 적게 반발했다고 밝힘
    • GitHub의 Balanced Employee IP Agreement를 잠재 고용주에게 보여줄 수 있음
    • 이 계약은 CC0로 오픈소스화됐고, 대형 상장사가 실제 사용했으며, 고용주는 비용을 지불한 것을 보유하고 직원은 사업과 경쟁하지 않는 오픈소스 작업을 보유하도록 설계됨

  • 기밀성과 보안

    • 비공개 저장소, 자격 증명, 사고, 고객 데이터, 로드맵, 공개 전 취약점, 내부 논의를 공개해서는 안 됨
    • 원래 허용되지 않은 접근 권한을 사용하거나 보안 통제를 우회해서는 안 됨
    • 직접 행동은 비공개 회사 정보를 공개할 핑계가 아니라, 공개 작업을 공개 상태로 유지하고 영업상 비밀과 분명히 분리할 이유임

  • 조용함은 부주의가 아님

    • 공개하지 않고 한다는 것이 무모하게 한다는 뜻은 아님
    • 정책, 계약, 고객 의무, 안전 규칙이 위험을 바꾸는 경우 자신의 판단을 사용해야 함
    • 필요하다면 자신의 기기, 계정, 네트워크에서 작업해야 함
    • 목적은 회사에서 “훔치는” 것이 아니라, 일이 오픈소스에서 가져가는 것과 자신이 오픈소스에 돌려줄 수 있는 것 사이의 균형을 맞추는 데 있음
    • 회사 기계에 보이는 모든 시간을 바치는 동료보다 성과평가가 나빠질 수 있지만, 내일 해고하고 AI가 대체했다고 주장할 수 있는 회사에서 A 등급을 위해 삶을 태우는 것보다 지속 가능한 B 등급이 건강하다고 봄

  • 적용 한계

    • 시간이 특정 고객, 보조금, 정부기관, 방위 프로젝트, 규제 환경에 청구되는 경우 이 주장은 가장 약해짐
    • 불이익을 감당할 영향력이 없는 주니어 또는 불안정한 엔지니어에게도 가장 약함
    • 고용주가 이미 사용하는 공개 의존성을 고치는 시니어 유지보수자에게 가장 강함
    • 가장 깔끔한 형태는 “업무 시간에 하고 싶은 일을 하라”가 아니라, 오픈소스 유지보수를 엔지니어링 업무의 일부로 다루는 것임
    • 이미 유지보수하는 프로젝트를 유지보수하고, 업무가 닿는 공유 도구를 개선하며, 관련 없는 일·독점 코드·실제 약속을 놓치게 만드는 일은 피해야 함

출처와 프로젝트

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 회사들이 특정 오픈소스 프로젝트에 기여하는 것에 대해 포괄적 허가를 주는 경우가 대체로 많았음
    표현 방식이 중요함. “기분 좋아지려고 자선 활동 좀 해도 될까요?”가 아니라, “이 분야 전문가들에게 무료로 엄격한 리뷰를 받고, 수정 사항을 업스트림 오픈소스 프로젝트에 반영해서 회사의 향후 유지보수 비용을 없애도 될까요?”라고 말해야 함
    실제로 그게 본질이고, 그렇게 말했을 때 거절한 고용주는 없었음. 회사 이익에 완전히 부합하니 그걸 보이게 도와주면 됨

    • 예전 직장에서 해고된 게 여러모로 아쉬운데, 큰 이유 중 하나는 내가 Kafka Streams 라이브러리에 만든 꽤 큰 변경을 오픈소스로 공개할지 논의 중이었기 때문임
      API는 대부분 호환되게 유지하면서 많은 부분을 다시 썼고, 필요하면 백프레셔 의미론을 쓸 수 있는 비차단 입출력을 강조하는 방향이었음. 상태 저장소와 차단/비차단 입출력을 섞어 쓰면서도 꽤 성능을 유지할 수 있어 흥미로운 것들을 가능하게 했고, 눈에 잘 안 띄는 여러 지점에서 성능을 끌어낸 프로젝트라 특히 자랑스러웠음
      GitHub에 공개하거나 업스트림 Kafka Streams 프로젝트에 PR을 보내게 해달라고 밀어붙였지만, 그 전에 정리해고가 있었고 이후에는 그 일을 밀어줄 챔피언이 없어 독점 코드로 묶여 버림
      아직도 처음부터 다시 만들어 자유 오픈소스로 공개할까 생각함. 시간이 꽤 지났으니 다시 작성해 공개해도 문제는 없을 것 같고, 특허 같은 것도 없었으며, Vert.x 의존성을 없애는 등 바꾸고 싶은 것도 있음. 언젠가 일주일쯤 쉬게 되면 해볼지도 모름
    • 이런 걸 허용해주던 곳에서 일하던 때가 그리움
      어떤 회사들은 단지 법무 검토 절차만으로도 꼬여버림
      한 번은 어떤 프로젝트에 패치를 보내도 되는지 허가를 요청했는데, 흥미로운 이메일 스레드가 이어졌음. 결국 질문은 하나였음: 고객에게 청구되는 시간에, 납품 제품의 버그를 고치기 위해 작성한 패치이고, 패치된 라이브러리를 다시 컴파일해 소스 코드와 함께 납품해야 하며, 계약서에는 제품과 관련된 모든 작업물과 지식재산권이 고객에게 이전된다고 되어 있다면, 그 패치를 퍼블릭 도메인으로 공개할 권한이 우리에게 있는가?
      법무팀은 답하고 싶어 하지 않았음
    • 대체로 좋은 접근이고, 일을 전문적으로 프레이밍하는 훌륭한 예시라고 봄. 다만 문제의 핵심을 해결하진 못함. 특히 공학 중심 회사의 리더십이라면 이런 이점을 즉시 이해해야 하는데 그렇지 않다면 문제임
      어떤 방식으로 접근할 수 있는지는 고용주 운도 크게 좌우함
    • “좋아요, 이걸 컴플라이언스 팀에 한번 돌려볼게요. 지식재산권 침해가 없는지 확인만 하려고요. 정확히 어느 저장소와 이슈인가요?”

  • “그리고 배포하는 오픈소스 지식재산권을 확실히 소유하라”는 말에 대해, 내가 일해본 관할권에서는 근무 시간에 작성해 배포하는 코드는 내가 아니라 고용주 소유였음
    근무 시간에 기여할지 혼자 결정할 수 없고, 오픈소스 코드 작업을 하려면 정식 합의가 필요했음. 요청할 때마다 법무 부서를 거치는 데 몇 달씩 걸려서 결국 포기하거나, 그 사이 다른 기여자가 PR을 이미 올려서 더 이상 요청하지 않게 됐음

    • 아마 “자기 것이 아닌 작업물을 마음대로 기부하려 하면 안 된다”는 뜻이었을 것 같음. 아래에 관련 섹션이 따로 있지만, 위쪽 글머리표만 보면 혼란스러움
      경험 많은 개발자에겐 당연한 내용이지만, 몇몇 회사의 주니어 개발자들에게는 실제 문제가 되었음. 회사가 내부 프로젝트에서 멋진 걸 하고 있으면, 그걸 어떤 오픈소스 프로젝트에 기여하면 좋겠다고 생각하면서도, 비공개 코드 지식을 이용해 실질적으로 유사한 코드를 제출하거나 때로는 복사해 붙여넣는 문제가 생긴다는 점을 고려하지 않음
    • 직접 조사해본 건 아니지만, 독일에서는 기본적으로 근무 시간에 만든 모든 소스 코드를 고용주가 소유한다고 알고 있었음
      IT 중심이 아닌 고용주 대부분은 오픈소스가 무엇인지, 어떻게 작동하는지도 이해하지 못할 것임. 그래서 많은 사람에게 허가를 받는 건 절망적일 수 있음
      링크된 사이트는 우선 고용주를 대상으로 오픈소스의 이점을 설명하고, 고용주용 법적 가이드라인을 옹호하는 데 초점을 맞추는 편이 좋겠음
    • 회사가 프로덕션에 들어가는 부분을 제외하고는 허용적 라이선스 코드로 공개하지 않는다면 그런 직장은 안 갈 것 같음. 나에겐 의욕을 꺾는 일이고 정신적으로 한계까지 몰릴 듯함. 차라리 가난한 편을 택하겠음

  • 좋은 생각이고, 심지어 훌륭한 생각이지만, 이를 저항으로 포지셔닝하는 게 좋은지는 모르겠음
    직무의 목적은 보통 어떤 목표를 달성하는 것임. 그 목표를 어떻게 달성할지는 전문가인 개발자가 결정할 수 있음. 그 결정에 오픈소스 소프트웨어가 포함된다면, 그것을 유지보수하는 일도 그 결정의 일부여야 함
    급진적인 일이 아니라, 업무에 의존하는 것들의 미래 안정성과 유지보수성을 지키며 자기 일을 하는 것일 뿐임

    • 이것은 그냥 좋은 비즈니스 감각이기도 함. 오픈소스를 통한 협업을 장려하는 회사는 자기 사업을 먹여 살리는 생태계를 키우는 셈임
    • 말한 내용에는 모두 동의하지만, 요즘 대부분의 기술 회사 현실은 내가 겪기엔 다름. 강제되지 않는 한 자기들 인프라와 라이브러리 유지보수에도 시간을 투자하지 않는데, 하물며 오픈소스는 더 어려움
      지표 게임용 쓸모없는 기능, 엔시티피케이션, 다크 패턴, 악성코드에 가까운 유행 통합 같은 것이 기반 인프라나 라이브러리 투자보다 우선됨
    • 동의함. 이런 식의 묘사는 누군가가 소셜 미디어에서 더 많은 관심을 끌려는 것처럼 보이게 함. 모든 것이 과장되어야 하는 지점까지 온 게 안타까움

  • 일반론으로는 전적으로 동의하지만, 실제로 해내기는 까다롭다고 봄. 변호사는 아니지만, 일반적으로 고용주가 지식재산권을 소유하므로 오픈소스로 공개하려면 명시적 허가가 필요하다고 알고 있음
    그리고 그 허가를 받는 과정은 종종 어렵고, 끝없는 절차와 법무 부서를 거쳐야 함
    “미국, 영국 및 여러 관할권에서는 직원이 직무의 일부로 저작물을 만들면 고용주가 법적 저자 또는 최초 저작권자로 간주된다”
    https://en.wikipedia.org/wiki/Work_for_hire
    그래도 오픈소스 작업, 즉 유지보수와 개발은 기부를 구걸하는 자원봉사자가 아니라 급여를 받는 전문가가 해야 한다고 생각함. 핵심 질문은 그걸 어떻게 실현할지, 회사들이 오픈소스 기여를 개별 협상이 필요한 예외가 아니라 표준 관행으로 받아들이게 만들 방법임

    • 설명한 문제들은 “실무상의 문제”라기보다 이론적 문제에 가까움
      실제로는 그냥 하면 됨. 컴퓨터 안에 git push를 막는 서브루틴은 없음. 실제로 고용주는 고용계약서에 온갖 내용을 써넣음. 모든 방향에서 책임을 피하려고 가능한 한 많이 적어둠. 그들이 마음대로 적을 수 있다면, 왜 우리는 그냥 할 수 없나? 아무것도 중요하지 않음
      실제로 이런 기술적 이유로 지식재산권에 도전받은 오픈소스 프로젝트는 거의 0에 가까움
    • 그 작업이 직무와 관련되어 있다면 고용주가 지식재산권을 가진다는 말은 맞음
      직무와 관련이 없다면 주마다 다름. 많은 주에는 고용주가 자기 지식재산으로 주장할 수 있는 범위에 제한이 있음. 일반 계약서는 문구를 넓게 잡아 모든 것을 주장하려 하지만, 법은 종종 고용주와 관련 없는 자유 시간 작업까지 회사가 가져갈 수 없다고 함
      근무 시간에 하거나 회사 노트북을 쓰면 회사가 권리를 주장할 여지가 생김. 대부분 회사는 신경 쓰지 않겠지만, 분쟁이 생겼을 때 깔끔하게 유지하려면 방심하면 안 됨
      개인 시간, 개인 장비로 작업하고, 고용된 업무나 회사에서 접한 것과 겹치지 않게 해야 함
    • 변호사는 아니지만, 동료에게 실행해보라고 복사본을 줬다면 그 자체로 오픈소스 라이선스를 사용한 것 아닌가 싶음. 그 동료는 라이선스가 부여한 법적 권리를 갖게 되고, 변경 사항을 재배포할 권리도 갖는 것 아닌가?
      변경 사항을 업스트림에 올리는 것이 유지보수를 보장하는 가장 좋은 방법인데, 이 모든 게 매우 우스워 보임. 내부 독점 포크를 유지하는 데 따르는 법적 불확실성도 마찬가지임
    • 글은 저항이 가장 적은 경로를 따르라고 제안하는 것 같음. 회사 시간에 작업하고, 큰 파장을 만들지 않는 것임. 들키면 용서를 구하면 됨. 회사 입장에서는 용서하는 게 쉬운 길임. 변호사를 끌어들이면 비용이 매우 커지고, 홍보 악몽이 될 수도 있음
    • 현재 프로그래밍 상태가 보여준 게 있다면, 지식재산권과 저작권법은 더 이상 존재하지 않는다는 것임

  • 꽤 큰 회사에서 일함. 우리 회사의 오픈소스 정책은 대략 “먼저 매니저에게 물어보고, 회사 이름으로 하지 말고, 기밀 정보를 공개하지 말라”로 요약됨
    문제가 된 적은 없고, 큰 틀에서 완전히 합리적이라고 느낌

  • 근무 시간에 제3자 오픈소스 프로젝트에 버그 수정 같은 기여를 하는 건 문제없다고 보지만, 자기 오픈소스는 어떻게 처리해야 할지 모르겠음
    예를 들어 개인적으로 만든 작은 라이브러리가 있고, 그걸 회사에서 쓰다가 근무 시간에 버그를 발견했다고 하자. 그 근무 시간에 기여하면 회색지대일 것 같음
    면접 중에 이런 걸 협상해본 사람이 있나? 어떻게 했는지 궁금함

    • 실제로 이걸 신경 쓰는 회사에서 일해본 적은 없음. 그냥 필요한 일을 했음. “제대로” 하려면 어떻게 해야 하냐고 물어봤을 때도 답을 받은 적이 없었음

  • 대기업에서 일할 때는 대체로, 회사 코드베이스에 직접 코드를 쓰는 것 외의 작업 요청은 근거를 제시해도 직속 매니저가 “자유 시간에 하라”고 답했음
    이익 지향 환경에서는 즉각적인 가치만 추구할 만한 것으로 여겨짐. 태도는 꽤 기생적이고, 위에서부터 내려오는 더 높은 효율과 지표 경쟁이 그렇게 만듦

  • 업무 문제를 해결하려고 포크해서 고친 뒤, 그 결과를 업스트림에 PR로 보낸 적이 분명히 있음
    오픈소스를 사용하고 접근할 수 있다는 점에서 좋은 부분 중 하나임. package.json과 cargo.toml에서 git이 거의 일급 선택지인 이유도 여기에 있음. 변경이 업스트림되기 전까지 포크를 직접 가리킬 수 있기 때문임

  • 시니어가 되면 면접 과정에서 “우리에게 질문 있나요?”라는 단계가 왔을 때, “이 회사가 의존하는 오픈소스 프로젝트에 제 시간 일부를 기여하는 것에 대해 어떤 입장인가요?”라고 묻는다
    답을 보고 계속 남을지 결정하면 됨

답변달기