모든 개발자는 법적 문제에 대해 무엇을 알아야합니까? [닫은]

오늘 저는 GPL 라이선스의 일부 의미에 대해 알게 된 깜짝 놀랐습니다 . 주로 제가 생각한 것만 큼 자유롭게 사용할 수 없었습니다.

이제 알아.

그 밖에 무엇을 알아야하며, 모든 개발자가 이와 같은 법적 문제에 대해 무엇을 알아야합니까?

직원, 프리랜서, 오픈 소스 프로젝트 기여자 (등)를 분리하거나보다 광범위한 답변을 제공 할 수 있습니다.

소프트웨어 개발을위한 12 가지 법적 고려 사항

1. 일반 대중에게 공개 된 소프트웨어는 저작권이 있습니다. 더 이상 애플리케이션이나 소스 코드에 저작권 표시를 할 필요가 없습니다. 저작권의 소유자는 저자 또는 저자에게 비용을 지불하는 회사입니다.

2. 소프트웨어의 저작권은 저작권 소유자가 할당하거나 소유자가 보유 할 수 있으며 소프트웨어는 소유자가 사용자 또는 사용자에게 라이센스를 부여 할 수 있습니다.

3. 개발에 사용되는 라이브러리는 사용 및 배포에 제한이있을 수 있습니다. GPL은 라이브러리를 공개 도메인으로 만들지 않으며 라이브러리가 개발 플랫폼과 함께 제공된다는 사실도 아닙니다. 애플리케이션을 배포하기 전에 라이센스를 읽고 이해해야합니다. 일부 도서관은 로열티 지불이 필요하지만 최근 몇 년 동안 덜 일반적입니다.

4. 소프트웨어 특허 소송은 헛소리입니다. 물론 소프트웨어 특허를 고의로 위반해서는 안됩니다. 그러나 일부 회사가 특허 위반으로 귀하를 고소 할 가능성은 작지만 실제적입니다. 이는 소프트웨어를 독립적으로 개발하고 특허에 대해 들어 본 적이없는 경우에도 발생할 수 있으며 특허는 직관적으로 명백하고 소프트웨어와 거의 완전히 관련이없는 기술을 포함합니다. 현재 USPTO 정책을 고려할 때 보험 구매 외에이를 방지하기 위해 할 수있는 일은 많지 않습니다. 좋은 소식은 특허 트롤이 일반적으로 많은 돈으로 대기업을 고소한다는 것입니다.

5. 직원 또는 프리랜서를 사용하여 소프트웨어를 개발하는 경우 소스 코드를 포함하여 애플리케이션에 대한 저작권 소유자를 서면으로 명시해야합니다. 일부 프리랜서 및 계약 개발 회사는 소스 코드를 자신의 재산으로 간주하여 회사를 원래 개발자에게 의존하게합니다. 개발 계약에있는 경우 합법적입니다.

6. "일시적으로"소프트웨어를 개발하는 직원이있는 경우 해당 소프트웨어를 소유 한 사람과 직원이 회사 외부에서 작성하고 배포 할 수있는 소프트웨어 종류를 명확히해야합니다.

7. 소프트웨어를 개발하는 직원 또는 프리랜서 인 경우 개발을 시작하기 전에 누가 애플리케이션의 저작권을 소유 할 것인지 명확히해야합니다. 또한 자신의 시간에 작성하는 소프트웨어를 누가 소유하고 있는지 알고 있어야합니다. 일부 회사는 집에서든 직장에서든 고용 기간 동안 개발자가 작성한 소프트웨어에 대한 소유권을 주장하는 고용 계약 조항이 있습니다. 많은 회사는 고용 계약에 직원이 회사 외부에 배포하기 위해 생산할 수있는 소프트웨어를 제한하는 비경쟁 조항을 가지고 있습니다. 때때로 이러한 제한은 매우 광범위합니다.

8. 상표는 소프트웨어 자체가 아니라 이름 또는 상징입니다. 소프트웨어를 배포하는 경우 (a) 응용 프로그램 이름과 "마크"또는 이름의 디자인이 다른 응용 프로그램과 "혼동을 일으킬 정도로 유사"하지 않은지 확인하고 (b) 상표를 등록해야합니다. 최초 사용 날짜는 충돌 해결에 중요하므로 애플리케이션이 상거래에서 처음 사용 된시기를 문서화해야합니다.

9. 응용 프로그램의 이름을 지정할 때 등록 상표를 확인하고 Google도 확인하십시오. 이름을 처음 사용하는 응용 프로그램은 상표를 등록하지 않았고 귀하가 가지고 있더라도 귀하의 신청이 성공한 후에 귀하의 이름과 상표를 취할 수 있습니다.

10. 계약 또는 계약을 사용하거나 서명 할 때 양 당사자가 이해했는지 확인하십시오. 고용 계약서에서 잠재적으로 민감한 영역을 미리 언급하면 ​​나중에 많은 문제를 예방할 수 있습니다. 개발 계약에서 양 당사자가 누가 소스 코드를 소유하고 있는지, 누가 업그레이드를 담당하는지 또는 누가 유지 보수를 담당하는지 알고있는 경우, 개발 프로젝트에 들어가면 소송이 발생할 가능성이 훨씬 적습니다. 완료되었다. 배포 계약에서 배포자가 계약의 책임과 기간을 이해하고 있는지 확인하십시오.

11. 중요하지 않은 모든 응용 프로그램에는 버그 (또는 "디자인 고려 사항":-))가 있습니다. 모든 사용자 계약 또는 배포 계약은 버그가없는 소프트웨어에 대한 책임이 없으며 모든 버그를 수정할 것으로 기대할 수 없음을 명시해야합니다. 변경, 수정 및 업그레이드가 개발자의 선택 (또는 최선의 노력)에 따라 이루어짐을 명확히하고 수정 및 업그레이드 비용을 누가 지불하는지 명확히합니다.

12. 소프트웨어 개발 및 배포 계약에 대해 변호사와상의 한 후에도 다른 소프트웨어 회사의 계약서를 읽고 해당 변호사가 어떤 제안을했는지 확인해야합니다.

13. 나는 변호사가 아니며 이것은 법적 조언이 아닙니다.

확실하지 않은 경우 변호사에게 문의하십시오.

저는 변호사는 아니지만 시간이 지남에 따라 시간을 절약하기 위해 사용할 수있는 법적인 사람들로부터 몇 가지 경험 규칙을 수집했습니다.

• GPL 라이선스는 '카피 레프트'또는 '바이러스'입니다. 즉, GPL 구성 요소에 따라 작성하는 모든 코드는 GPL로 릴리스되어야합니다. 경험상 소프트웨어를 컴파일하기 위해 GPL 구성 요소가 필요한 경우 소프트웨어를 GPL 라이선스에 따라 배포해야합니다.
• 소프트웨어를 배포하지 않는 경우 소스를 사용할 수 있도록 할 의무가 없습니다. 예를 들어 내부 용으로 또는 웹 서버에서 소프트웨어를 실행하는 경우 소스를 릴리스 할 필요가 없습니다. 그렇기 때문에 Google은 GPL 라이브러리를 사용하는 소프트웨어를 출시 할 필요가 없습니다. GPL v3의 핵심 경쟁 지점이었습니다.
• LGPL (Library 또는 Lesser GPL)은 LGPL 기반 라이브러리를 대체 할 수없는 방식으로 통합하는 경우에만 자체 소스 코드를 GPL하도록 요구합니다. 라이브러리를 '사용'하기 만하면 자신의 소프트웨어가 GPL 일 필요는 없습니다. 헤더 파일을 포함 하고 라이브러리 의 .dll/ .so에 대한 링크 는 적절한 저작권 고지를 제외하고 어떠한 의무없이 LGPL 코드를 '사용'할 수있는 방법 중 하나입니다.
• BSD 라이선스 (Apache 라이선스는 매우 유사 함)를 사용하면 오픈 소스 구성 요소를 사용하는 상업적 확장을 만들 수 있습니다. 이것이 애플이 OSX 용 커널로 Linux 대신 FreeBSD를 선택한 이유입니다.
• MPL은 라이센스가 작성되었을 때 Netscape가 Mozilla에서 돈을 벌 수 있다고 생각했기 때문에 매우 상업적으로 친숙합니다.

오픈 소스 프로젝트의 관리자에게 연락하는 것이 종종 도움이됩니다. 그들은 라이센스의 원래 의도와 오픈 소스에 대한 자신의 견해에 대해 조언 할 수있는 가장 좋은 위치에 있습니다. 때때로 메인테이너는 당신을 돕기 위해 여러 라이선스로 소프트웨어를 출시 할 의향이 있습니다. 종종 그렇지 않습니다. 저작권 소유자에 따라 다릅니다.

KDE 프로젝트에는 편리한 매트릭스가 있습니다.

Stephen Fishman Attorney의 웹 및 소프트웨어 개발 에 대한 법률 가이드가 당신이 찾고있는 것이라고 생각 합니다.

리뷰

놀라운 책! 당신이 상상할 수있는 거의 모든 법적 질문과 당신이 생각하지 못했던 일부에 대한 답변. -John Dvorak, PC Magazine

빠르게 성장하는 무형 매체에 중요한 상상할 수있는 모든 세부 사항을 다룹니다. -기업가

이 책은 다른 법률 가이드보다 높은 점수로 법률 가이드에 대한 내 개인 테스트를 통과했습니다. -Jeff Duntemann, 편집자, PC Techniques Magazine

제품 설명

귀하의 권리와 노력을 보호하십시오!

웹 사이트 및 소프트웨어 개발에 관한 법률은 복잡하고 혼란 스럽지만,이를 풀지 않으면 변호사 수임료와 소송 비용이 수천 달러에이를 수 있습니다.

다행히 웹 및 소프트웨어 개발에 대한 법률 가이드는이 복잡한 법률 영역을 독자 친화적 인 영어로 철저히 해독합니다. 또한 CD-ROM에있는 계약, 계약 및 법적 양식을 단계별로 작성 지침과 함께 제공하므로 변호사의 몸값을 지불하지 않고도 소프트웨어와 웹 사이트를 보호 할 수 있습니다.

웹 및 소프트웨어 개발에 대한 법률 가이드를 사용하여 다음을 배우십시오.

• 필요한 법적 보호의 종류
• 각 보호 유형의 강점과 한계
• 침해를 피하는 방법
• 계약 초안을 작성할 때 필요한 조항
• 다른 사람의 자료 사용 허가를 얻는 방법

초안 작성에 대한 완전한 단계별 지침을 찾을 수 있습니다.

• 고용 계약
• 계약자 및 컨설턴트 계약
• 개발 계약
• 라이센스 계약

웹 및 소프트웨어 개발에 대한 법률 가이드의 5 판은 최신 판례법과 법정 개정판을 제공하기 위해 완전히 업데이트되었습니다.

다른 제안 :

• 스스로 일하기 : 독립 계약자, 프리랜서 및 컨설턴트를위한 법률 및 세금 (동일한 저자).
• 컨설턴트 및 독립 계약자 계약 (동일 작성자).
• Jeffrey I. Gordon의 소프트웨어 라이선스 핸드북 .
• H. Ward Classen의 라이센시 및 라이센서 를 위한 소프트웨어 라이센싱에 대한 실용 가이드 .
• 기술 계약 포켓 가이드 : David Tollen의 영업 사원, 계약 관리자, 비즈니스 개발자 및 변호사 를 위한 소프트웨어 및 서비스 계약 .

프리랜서 또는 계약자 인 경우 : 좋은 책임 보험이 있는지 확인하고 보험이 적용되는 내용을 알고 있어야합니다.

예를 들어, 신용 카드 번호를 노출 할 수있는 코드 실수에 대한 책임은 내 회사에서 다루지 않습니다. 그래서 더 이상 건드리지 않습니다!

직원의 경우 : 고객에게 첫 번째 조언을 제공 할 수 있어야합니다. 고객이 애플리케이션에서 원하는 구성 요소를 사용할 수 있습니까?

프리랜서의 경우 : 고객에게 강력한 조언을 제공 할 수 있어야합니다. 우리가 개발하는 응용 프로그램에 사용할 수있는 구성 요소를 선택합니다.

물론 당신의 말은 변호사가 당신에게 줄 수있는 조언만큼 좋지 않습니다. 그러나 당신은 이미 첫 번째 라운드를 도울 수 있습니다; 예를 들어, "우리는 이것을 사용할 수없는 이유가 ..."라고 말하면
결국 변호사는 코너 케이스에 대해 많이 알게 될 것입니다.하지만 조금만 도울 수 있다면 ...

OSS 기여자에게 : 사람들이 당신의 코드로 무엇을 할 수 있는지에 관심이 있다면 자유 라이선스 간의 차이점을 아는 것이 중요 할 수 있습니다 (재배포? 수정? 상용 애플리케이션에서 사용? 독점 애플리케이션에서 사용?).

한 답변은 법이 코드와 같지 않다고 주장했습니다. 동의하지 않습니다.

초기에 IBM은 프로그래머에게 지침에 따라 비용을 지불했습니다. (내가 아는 누군가는 그가 이런 식으로 부자가 된 프로그래머와 함께 일했다고 말했다. 분명히 그 사람은 기계의 인덱스 레지스터를 사용하는 방법을 몰랐다. 그는 각 메모리 주소에 0을 수동으로 저장하는 메모리 제로 루틴을 작성했다.)

또한 (오래 전) 변호사가 그 말로 돈을받는 경우가있었습니다. 이것은 사람들을 "가장 존경받는 그런 것들"및 기타 장황한 말로 언급하는 것과 같은 관행을 대중화하는 데 도움이되었습니다.

VB.NET 2008에서 여전히 줄 번호를 허용 한다는 답변을 읽었습니다 . 최신 PC에서도 순수 DOS를 실행할 수 있습니다. 그리고 모든 COBOL 프로그램이 점진적인 변화에 의해 공통 조상으로부터 추종되었다는 농담에는 많은 진실이 있습니다. 우리 분야에는 역 호환성과 "역사적 이유"가 만연합니다.

이것은 법의 영역과 비슷합니다. 다른 법률을 작게 (또는 크게) 변경하는 법률이 있습니다. 당신은 일종의 의존성 지옥을 가지고 있습니다. 우스꽝스러운 역사적 법칙 (태즈 매니아 주 호바트에서는 남자가 해가 진 후에 여자의 옷을 입는 것은 불법입니다. 옛날 옛적에 죄수들은 여자로 옷을 입히고 사람들을 낯을 씌우는 사람 이었기 때문입니다) 아무도 집행을 꿈꾸지 않을 것입니다. 아무도 더 이상 사용하지 않는 소프트웨어에는 몇 가지 역사적인 기능이 있습니다.

법률은 종종 의도하지 않은 결과 (버그!), 창의적인 방식으로 사용 (핵!), 허점 (보안 취약성!)을 포함하며, 일부는 의도적 (백도어!), 수정 (패치!) 또는 뒤집혀 (제거!) .

예, 법률 (코드와 달리)은 해석 대상입니다. 그러나 나는 이것이 코드 유지 보수와 비슷하다고 생각합니다. 법률을 새로운 사회적 규범에 맞게 조정하는 데 도움이됩니다.

질문에 직접 답하기 위해 : 모든 개발자는 법이 수백 년 동안 개발 된 엄청나게 거대한 소프트웨어 프로젝트와 같다는 것을 알아야합니다. (사실 각 국가마다 고유 한 프로젝트가 있으며 다른 방식으로 문제를 해결합니다.) 이론적으로 라이센스를 읽은 후에는 코드로 할 수있는 것과 할 수없는 것을 알게 될 것입니다. 그러나 유능한 프로그래머가 코드를 읽는 것만으로 코드의 모든 버그를 발견 할 수 없다면 변호사 가 아닌 사람 이 법률 문서의 코너 케이스와 회색 영역을 분석 할 수있는 가능성은 얼마나 됩니까?

소프트웨어 소스 코드와 마찬가지로 일반적으로 법률 문서의 요점을 읽을 수 있지만 구체적인 내용을 알아야 하는 경우 전문가에게 문의하십시오 .

NOLO (나는 그들과 일하지 않는다)는 평신도를위한 좋은 법적인 책을 출판한다.

http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html

저는 "모든 변호사가 프로그래밍에 대해 무엇을 알아야합니까?"라고 대답하는 것과 같은 방식으로 대답합니다. 즉, 가장 단순한 일보다 더 많은 일을 할 수있을만큼 심층적 인 분야를 잘 알 수있는 방법은 없습니다. 전문가를 구하십시오.

사용할 라이선스의 기본 권리와 의무를 알고 있어야합니다. 그다지 어렵지 않으며, 많더라도 사용하거나 만질 것만주의 깊게 읽어야합니다. 대부분의 경우 아주 명확합니다.

당신이 필요로 할 수있는 다른 것은 뭐든지 다릅니다. 특허? 상표? 이러한 것들이 필요하다면 회사에 있고 법률 부서에서이를 수행 할 가능성이 있습니다.

나는 항상 프로젝트 개발자가 자신의 작업을 사용하는 모든 소프트웨어가 똑같은 라이선스로 출시되기를 원한다고 가정합니다. 자세한 내용은 FAQ 및 법률 페이지를 읽고 여전히 확실하지 않은 경우 개발자 / 관리자에게 문의하십시오.

라이센스 계약의 세부 사항을 이해하는 데 도움이 필요하면 변호사에게 문의하십시오.

1. 개발자보다 변호사가 더 많은 국가에서 일하지 마십시오.
2. 모든 (미국) 소프트웨어 특허 중 극히 많은 비율이 가짜이지만, 지불하거나 무효화 될 때까지 기다릴 수 없습니다.
3. 오픈 소스 소프트웨어를 사용 / 개발하려면 기존 라이선스를 사용하고 수정하지 마십시오. 면허가 의미하는 바의 경계에 가까이 가지 마십시오.

좋은 IP 변호사의 이름.

6. "일시적으로"소프트웨어를 개발하는 직원이있는 경우 해당 소프트웨어를 누가 소유하고 있는지, 그리고 직원이 회사 외부에서 작성하고 배포 할 수있는 소프트웨어 종류를 명확히해야합니다.

대부분의 헌법에 명시된 바와 같이 언론의 자유 (특히 개발자가 무료 소프트웨어를 제공하는 경우)는 그러한 조건이 법원에서 비참하게 실패하게 만들 수 있습니다.

법은 코드와 다릅니다. 명확하게 이해할 수있는 단계와 규칙의 집합이 아닙니다.