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

예전 직장에서 해고된 게 여러모로 아쉬운데, 큰 이유 중 하나는 내가 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이 거의 일급 선택지인 이유도 여기에 있음. 변경이 업스트림되기 전까지 포크를 직접 가리킬 수 있기 때문임

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