코드에 자신의 이름이나 회사 이름을 쓰는 경향이 있습니까?

저는 집과 직장에서 다양한 프로젝트를 수행해 왔으며 수년 동안 거의 모든 AJAX 기반 웹 사이트에서 사용하는 두 가지 주요 API를 개발했습니다. 이 두 가지를 DLL로 컴파일하고 네임 스페이스 Connell.Database 및 Connell.Json이라고했습니다.

내 상사는 최근 회사의 소프트웨어 문서에서 이러한 네임 스페이스를보고 코드에서 내 이름을 사용해서는 안된다고 말했습니다. (그러나 그것은 내 코드입니다!)

명심해야 할 것은 우리가 소프트웨어 회사가 아니라는 것입니다. 우리는 IT 지원 회사이며 여기서 유일한 풀 타임 소프트웨어 개발자이므로 회사에서 소프트웨어를 작성하는 방법에 대한 절차는 실제로 없습니다.

명심해야 할 또 다른 점은 언젠가이 DLL을 오픈 소스 프로젝트로 발표한다는 것입니다.

다른 개발자는 회사 내에서 네임 스페이스를 어떻게 그룹화합니까? 개인 및 작업 프로젝트에서 같은 클래스 라이브러리를 사용하는 사람이 있습니까?

또한이 다른 방식으로 작동합니까? 직장에서 수업 라이브러리를 작성하면 누가 그 코드를 소유합니까? 라이브러리가 처음부터 끝까지 보이면 디자인하고 프로그래밍했습니다. 집에서 다른 프로젝트에 사용할 수 있습니까?

감사,

최신 정보

나는이 문제에 대해 상사와 이야기를 나 they으며, 그들이 내 사물이라는 것에 동의하고 오픈 소스를 사용하는 것이 좋습니다. 이 대화를 시작하기 전에 어쨌든 객체를 변경하기 시작했습니다. 실제로는 상당히 생산적이며 코드는 이제이 특정 프로젝트에 적합했습니다.

그러나 매우 흥미로운 토론에 참여한 모든 사람에게 감사합니다. 나는이 모든 텍스트가 낭비되지 않고 누군가가 그것을 배우기를 바랍니다. 나는 확실히했다.

건배,

(표준 면책 조항-나는 변호사가 아닙니다 ...)

귀하의 프로필에서 영국에있는 것으로 보입니다.

이 경우 고용 방법에 따라 다릅니다. 당신이 직원의 영구 회원이라면 거의 확실하게 고용주가 작품을 소유하고 있습니다 . 귀하는이를 작성했으며 저자로 식별 될 권리가 있습니다 (즉, 사람들에게 귀하가 작성한 것을 알릴 수 있음). 그러나 코드의 소유권과 지적 재산권은 회사에 있습니다.

계약자 인 경우 일부 클레임이있을 수 있지만 계약의 성격에 따라 달라질 수 있습니다. 일반적으로 대부분의 영국 IT 계약 업체는 고용 근로자로 분류되므로 IP는 개인이 아닌 회사에 있습니다. 분명히 표준 고용 계약에 대해 이야기하면 계약이 영구적인지 여부에 관계가 있습니다.

이러한 상황에서 귀하는 공개 소스로 공개 할 권리가 없으며 (또는 실제로 다음 고용주에게 제공 할) 권리가 없으며 다른 독점 소프트웨어에 대해 생각하고 그에 따라 행동하는 것과 같은 방식으로 생각해야합니다. 다시는 소스 코드에 액세스 할 수 있습니다.

편집 : 당신이 당신의 시간에 그것의 일부를 개발했다는 ​​사실에 관하여. 귀하의 권리를 주장하지 않고 회사에 라이센스를 부여하지 않고 직장에서 사용하기 시작한 순간, 귀하는 언제 무엇을했는지 보여주기가 매우 어려워서 매우 어둡게 만들었습니다. 당신이 말하는 바에 따르면, 코드 라이브러리는 작업 시간 (그리고 회사는 자신의 시간에 수행 한 모든 것을 소유하고 있음)에서 테스트, 디버깅 및 수정되었으며, 그들이 수행 한 작업과 명백한 겹침 (그들이 사실에 의해 입증 됨) 회사가 귀하가 작업하고있는 요구 사항을 충족했다는 것은) 그들이 주장을하고 있고 아마도 꽤 강한 주장을하고 있음을 의미합니다.

Unite Union은 이것에 관한 기사를 가지고 있습니다. 주요 섹션은 다음과 같습니다.

"명시적인 법 조항이 있습니다 :

· 1988 년 저작권, 디자인 및 특허법 (CDPA) 11 조 (2) 및

· 특허법 1977의 섹션 39

직원의 저작물 취급. 이 조항에 따라 고용주는 본질적으로 직원이 만든 저작물과 관련하여 지적 재산권의 소유권을 얻습니다.

· 고용 계약 조건에 따라 생산해야했습니다.

· 계약 조건에 따라 합리적으로 생산 될 것으로 예상 될 수 있습니다.

분명히, 개별 직원의 직무 설명이 넓을수록 위의 11 (2) 및 39 조의 영향을 피하기가 더 어려워집니다.

직원이 자신의 시간에 자신의 자원을 사용하여 저작물을 생성 한 경우에도 고용주가 생성 된 저작물의 특성이 가능한 것으로 판단되는 경우 해당 저작물에 대한 권리를 주장 할 수있는 것은 아닙니다. 직원의 의무의 일부로 합리적으로 고려됩니다. 이는 링크 소프트웨어 누락 v Magee [1989] FSR 361의 경우에 의해 입증됩니다. 법원은 근무 시간 이외의 시간에 직원이 작성한 소프트웨어 프로그램 및 자신의 장비에 대한 저작권이 고용 과정에서 만들어 졌다고 판결했습니다. "Magee 씨가 수행하는 데 사용 된 작업의 범위 내에 들어갔습니다."

기본적으로 이러한 라이브러리는 작업하려는 프로젝트에 대한 특정 요구 사항을 충족했기 때문에 이에 대한 클레임이 있습니다.

편집 2 : 코드의 두 가지 버전이 있다는 사실은 관련이 없다는 것을 이해해야합니다. 이 코드는 회사에서 진행중인 프로젝트에 대한 요구 사항을 충족하며 회사에서 근무하는 동안 (자신의 시간에 있더라도) 작성했습니다. 따라서 프로젝트에서 구현 한 특정 코드 사본이 아니라 코드의 "핵심 IP"에 대한 강력한 주장을 할 수 있습니다. 두 지점을 보더라도 변경되지는 않습니다.

다시 쓰기조차도 파생 작업이라고하며 IP는 여전히 새 버전에서도 회사와 함께 할 것입니다.

나는 당신이 진실하고 싶어하는 것에 대한 아이디어를 가지고 있다고 생각하고 그렇게하기 위해 일을 왜곡하려고 노력하고 있지만 당신이 말하는 것에서 나는 회사가 당신이하지 않을 코드에 대해 꽤 강한 주장을 가지고 있다고 생각합니다 해결할 수 있습니다.

회사에서 코드 비용을 지불하는 경우 코드입니다. 허가가 없으면 오픈 소스 프로젝트로 공개하지 않습니다.

회사에서 일하는 동안 집에서 작성된 코드가 회사 소유인 것으로 간주되는 경우가있었습니다. 나는 그것이 법정에서 테스트되었는지 확실하지 않지만 회사 시간 동안 (즉 , 회사에서 코드를 작성 하기 위해 책상 에 앉아있는 시간) 회사 장비를 사용하여 작성한 코드는 확실합니다. 회사 소프트웨어는 회사에 속해 있습니다. 귀하는 코드 작성에 대한 대가로 귀하에게 돈을 줄 것이라는 계약을 체결했습니다 (고용 계약서 확인). 그들이 당신의 연봉 베큐 아제를 대신하여 자선 단체에 기부하려고한다고 말하면 감동하지 않을 것입니다.

즉, 그것은 당신의 코드가 아닙니다. 당신은 그것을 소유하지 않습니다. 네임 스페이스는 회사 이름이기 때문에 회사 이름이어야합니다. 그들은 그것을 쓰도록 누군가에게 지불했다! (즉, 당신).

• 주의 사항 : 귀하의 계약서 또는 고용 조건을 확인하여 위의 상황이 실제로 해당되는지 확인해야합니다. 어쨌든 그들에게 속한다고 주장합니다. 미래를위한 최선의 조언은 당신이하는 일과 고용주를 위해하는 일을 완전히 분리시키는 것입니다.

당신이 실수 한 곳이 있다고 생각합니다. 문제는 집에서 자신의 시간에 코드를 작성한 다음 코드가 직장에서 유용하다는 것을 발견했기 때문에 코드를 사용하기 시작했다는 것입니다. 이 경우에 적절한 방법은 회사 외부의 코드를 회사 코드에 통합하지 않는 것입니다. 회사 시간을 사용하여 이미 작성한 기능을 다시 작성해야 사용할 수 있습니다. "하지만 그것은 큰 시간 낭비입니다." 따라서 다른 옵션은 코드를 가격 또는 무료로 귀하에게 코드를 라이센스 / 구매하는 것입니다. 나는 고용주 마음에 무슨 일이 일어나고 있는지 생각합니다. 그들은 여전히 ​​그 코드를 사용할 권리가 있습니까?

많은 프로그래머들이 여가 시간에 일을하면 고용주에게 유용 할 수 있지만 회사의 승인없이 코드를 섞어서 시작해서는 안됩니다.

미래의 프로그래머는 문서 수준이 부적절 할 경우 (아주 슬프게도) 코드를 작성한 사람을 알아야합니다.

이런 이유로 나는 항상 내 이름에 서명합니다. 또한 내가 화를내는 동료가 한밤중에 저를 불러 줄 것임을 알기 때문에 훌륭한 일을해야한다는 것을 상기시켜줍니다. :)

거의 모든 사람들이 말했듯이, 아마도 회사가 코드에 대한 주장을하고있는 경우 일 것입니다.

미래에 고려해야 할 사항 중 하나는 고용 계약을 신중하게 검토하고 '자신의 시간, 자신의 키트-> 자신의 소유권'을 얻거나 회사에서 프로젝트 별 면제를 얻는 것입니다. 불행히도 현재로서는 도움이되지 않습니다.

다른 이름을 사용하면 무엇이 잘못 되었습니까? 아들 / 딸 / 고양이 / 개 / 햄스터의 이름은? 그런 다음 이러한 어려움을 겪을 필요가 없습니다. 방금 '친숙한'이름을 선택했습니다.

모든 답변은 소유권에 집중하는 것 같습니다.
그러나 소유권과 저자 (저자와 소유자)는 다른 개념입니다.
저자는 다음과 같은 도덕적 또는 양도 할 수없는 권리와 관련 이 있습니다 .

• 부단한
• 양도 할 수없는
• 이해할 수없는 권리
• Unsizeable (사유화
  할 수 없음) 이미 제작 된 저작물과 그 착취 수익금이 채권자에 의해 압류되기 쉬운 경우, 후자는 저작자가 지불 한 돈을 회수하기 위해 해당 저작물을 공개 할 것을 요구하지 않을 수 있습니다.

대부분의 관할권에서는 도덕적 또는 양도 할 수없는 저자의 권리를 포기할 수 없습니다 .

소유권은 경제, 일명 재산권, 권리와 관련이 있습니다.

근로자가 방문 연구원 / 교수로 자주 일할 때 과학 기사에 서명하는 방법을 따르지 않는 이유는 무엇입니까? 또는 3D 당사자의 독립적 인 자금 조달 : 저자 이름 + 작업이 수행 된 위치 + 작업에 자금을 제공 한 크레딧.

이러한 관계는 다 대다 관계에 있습니다 (한 명의 저자, ​​그의 작품은 여러 관계 및 자금 조달이 가능함).