모든 개발자는 법적 문제에 대해 무엇을 알아야합니까? [닫은]
오늘 저는 GPL 라이선스의 일부 의미에 대해 알게 된 깜짝 놀랐습니다 . 주로 제가 생각한 것만 큼 자유롭게 사용할 수 없었습니다.
이제 알아.
그 밖에 내가 알아야 할 사항은 무엇이며, 모든 개발자는 이와 같은 법적 사항에 대해 무엇을 알아야합니까?
직원, 프리랜서, 오픈 소스 프로젝트 기여자 (등)를 분리하거나보다 광범위한 답변을 제공 할 수 있습니다.
소프트웨어 개발을위한 12 가지 법적 고려 사항
일반 대중에게 공개 된 소프트웨어는 저작권이 있습니다. 더 이상 애플리케이션이나 소스 코드에 저작권 표시를 할 필요가 없습니다. 저작권의 소유자는 저자 또는 저자에게 비용을 지불하는 회사입니다.
소프트웨어의 저작권은 저작권 소유자가 할당하거나 소유자가 보유 할 수 있으며 소프트웨어는 소유자가 사용자 또는 사용자에게 라이센스를 부여 할 수 있습니다.
개발에 사용되는 라이브러리는 사용 및 배포에 제한이있을 수 있습니다. GPL은 라이브러리를 공개 도메인으로 만들지 않으며 라이브러리가 개발 플랫폼과 함께 제공된다는 사실도 아닙니다. 응용 프로그램을 배포하기 전에 라이센스를 읽고 이해해야합니다. 일부 도서관은 로열티 지불이 필요하지만 최근 몇 년 동안 덜 일반적입니다.
소프트웨어 특허 소송은 헛소리입니다. 물론 소프트웨어 특허를 고의로 위반해서는 안됩니다. 그러나 일부 회사가 특허 위반으로 귀하를 고소 할 가능성은 작지만 실제적입니다. 이는 소프트웨어를 독립적으로 개발하고 특허에 대해 들어 본 적이없는 경우에도 발생할 수 있으며 특허는 직관적으로 분명하고 소프트웨어와 거의 완전히 관련이없는 기술을 포함합니다. 현재 USPTO 정책을 고려할 때 보험 구매 외에이를 방지하기 위해 할 수있는 일은 많지 않습니다. 좋은 소식은 특허 트롤이 일반적으로 많은 돈으로 대기업을 고소한다는 것입니다.
직원 또는 프리랜서를 사용하여 소프트웨어를 개발하는 경우 소스 코드를 포함하여 애플리케이션에 대한 저작권 소유자를 서면으로 명시해야합니다. 일부 프리랜서 및 계약 개발 회사는 소스 코드를 자신의 자산으로 간주하여 회사가 원래 개발자에게 의존하도록합니다. 개발 계약에있는 경우 합법적입니다.
"일시적으로"소프트웨어를 개발하는 직원이있는 경우 해당 소프트웨어를 소유 한 사람과 직원이 회사 외부에서 작성하고 배포 할 수있는 소프트웨어의 종류를 명확히해야합니다.
소프트웨어를 개발하는 직원 또는 프리랜서 인 경우 개발을 시작하기 전에 누가 애플리케이션의 저작권을 소유 할 것인지 명확히해야합니다. 또한 자신의 시간에 작성하는 소프트웨어를 누가 소유하고 있는지 알고 있어야합니다. 일부 회사는 집에서든 직장에서든 고용 기간 동안 개발자가 작성한 소프트웨어에 대한 소유권을 주장하는 고용 계약 조항을 가지고 있습니다. 많은 회사는 고용 계약에 직원이 회사 외부에 배포하기 위해 생산할 수있는 소프트웨어를 제한하는 비경쟁 조항을 가지고 있습니다. 때때로 이러한 제한은 매우 광범위합니다.
상표는 소프트웨어 자체가 아니라 이름 또는 상징입니다. 소프트웨어를 배포하는 경우 (a) 응용 프로그램 이름과 "마크"또는 이름의 디자인이 다른 응용 프로그램과 "혼동 될 정도로 유사"하지 않은지 확인하고 (b) 상표를 등록해야합니다. 최초 사용 날짜는 충돌 해결에 중요하므로 애플리케이션이 상거래에서 처음 사용 된시기를 문서화해야합니다.
응용 프로그램의 이름을 지정할 때 등록 상표를 확인하고 Google도 확인하십시오. 이름을 처음 사용하는 응용 프로그램은 상표를 등록하지 않았고 귀하가 가지고 있더라도 귀하의 신청이 성공한 후에 귀하의 이름과 상표를 취할 수 있습니다.
계약 또는 계약을 사용하거나 서명 할 때 양 당사자가 이해했는지 확인하십시오. 고용 계약서에서 잠재적으로 민감한 영역을 미리 언급하면 나중에 많은 문제를 예방할 수 있습니다. 개발 계약에서 양 당사자가 누가 소스 코드를 소유하고 있는지, 누가 업그레이드를 담당하는지 또는 누가 유지 보수를 담당하는지 알고있는 경우, 개발 프로젝트에 들어가면 소송이 발생할 가능성이 훨씬 적습니다. 완료되었다. 배포 계약에서 배포자가 계약의 책임과 기간을 이해하고 있는지 확인하십시오.
사소하지 않은 모든 응용 프로그램에는 버그 (또는 "디자인 고려 사항":-))가 있습니다. 모든 사용자 계약 또는 배포 계약은 버그없는 소프트웨어에 대한 책임이 없으며 모든 버그를 수정할 수는 없음을 명시해야합니다. 변경, 수정 및 업그레이드가 개발자의 선택 (또는 최선의 노력)에 따라 이루어짐을 명확히하고 수정 및 업그레이드 비용을 누가 지불하는지 명확히합니다.
소프트웨어 개발 및 배포 계약에 대해 변호사와상의 한 후에도 다른 소프트웨어 회사의 계약서를 읽고 해당 변호사가 어떤 제안을했는지 확인해야합니다.
나는 변호사가 아니며 이것은 법적 조언이 아닙니다.
확실하지 않은 경우 변호사에게 문의하십시오.
저는 변호사는 아니지만 시간이 지남에 따라 시간을 절약하기 위해 사용할 수있는 법적인 사람들로부터 몇 가지 경험 규칙을 수집했습니다.
- 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
빠르게 성장하는 무형 매체에 중요한 상상할 수있는 모든 세부 사항을 다룹니다. -기업가
This book passes my own personal test for legal guides --with higher marks than any other legal guide. -- Jeff Duntemann, Editor, PC Techniques Magazine
Product Description
Protect your rights, and your hard work!
The laws covering website and software development are complex and confusing, but if you don't untangle them, it could cost you thousands of dollars in attorneys' fees and lawsuits.
Fortunately, Legal Guide to Web & Software Development decodes this complex area of the law, thoroughly and in reader-friendly English. It also provides contracts, agreements and legal forms on CD-ROM, with step-by-step instructions for filling them out, so you can protect your software and website without paying a lawyer's ransom.
Use Legal Guide to Web & Software Development to learn:
- what kind of legal protection you need
- the strengths and limitations of each type of protection
- how to avoid infringement
- which provisions you need when drafting an agreement
- how to obtain permission to use other people's materials
You'll find complete, step-by-step instructions to draft:
- employment agreements
- contractor and consultant agreements
- development agreements
- license agreements
The 5th edition of Legal Guide to Web & Software Development is completely updated to provide the latest case law and statutory revisions.
Some other suggestions :
- Working for Yourself: Law & Taxes for Independent Contractors, Freelancers & Consultants (Same author).
- Consultant & Independent Contractor Agreements (Same author).
- Software Licensing Handbook by Jeffrey I. Gordon.
- Practical Guide to Software Licensing for Licensees & Licensors by H. Ward Classen.
- The Tech Contracts Pocket Guide: Software and Services Agreements for Salespeople, Contract Managers, Business Developers, and Lawyers by David Tollen.
If a freelancer or contractor: make sure you have good liability insurance and know what's covered under it.
For instance, mine doesn't cover liability for mistakes made in code that might expose credit card numbers. So I don't touch that stuff any more!
For employees : we should be able to give a first round of advice to your clients -- like can they/we use the component we want, in their application ?
For freelancers : we must be able to give strong advice to your clients ; and choose which components we can use for the applications we develop for them.
You course, your word is not as good as the advices a lawyer can get you ; but you can already help for a first round ; for instance, to say "we definitly can't use this because it would mean..."
In the end, the lawyer will know much about corner cases -- but if you can help a bit...
For OSS contributors : knowing some differences between free licences can matter if you care what people can do with your code (redistribute ? modify ? use it in commercial application ? use it in proprietary application ? )
One answer has asserted that the law is not like code. I disagree.
In the early days, IBM paid programmers by the instruction. (Someone I knew said he worked with a programmer who got rich this way. Apparently the guy didn't know how to use the machine's index register; he wrote a memory-zero routine that manually stored zero in each memory address.)
There was also a time (long ago) when lawyers were paid by the word. This helped to popularise practices such as addressing people as "the most highly esteemed such-and-such" and other verbosities.
I just read an answer on SO that said VB.NET 2008 still allows line numbers. You can still run pure DOS on a modern PC. And there is much truth to the joke that all COBOL programs are decended from a common ancestor by incremental changes. Backwards-compatibility, and "historical reasons", are rife in our field.
This is comparable to the realm of law. There are laws which make small (or big) changes to other laws. You've got a kind of dependency-hell. There are some ridiculous historical laws (in Hobart, Tasmania, it's illegal for a man to wear a woman's dress after sunset - because once upon a time, convicts would dress up as women and mug people) that nobody would dream of enforcing, just as there are some historical features in software that nobody uses anymore.
Laws often have unintended consequeuences (bugs!), get used in creative ways (hacks!), contain loopholes (security vulnerabilities!), some of which are intentional (backdoors!), get modified (patches!) or overturned (uninstallation!).
Yes, laws (unlike code) are subject to interpretation. But I think this is rather like code maintenance. It helps to adjust laws to new social norms.
To answer the question directly: every developer should know that law is rather like a ridiculously enormous software project that has been in development for hundreds of years. (Actually, each country has its own project, and they solve problems in different ways.) In theory, after reading a licence you will know what you can and can't do with your code. But if a competent programmer can't spot all the bugs in his code just by reading it, then what chance does a non-lawyer have of analysing the corner cases and grey areas of a legal document?
Like with software source code, you can usually get the gist of a legal document by reading it, but if you need to know something specific, ask a professional.
NOLO (I don't work for them) publishes a good set of legal how to books for the layman.
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
I would answer this in the same way that I would answer "what should every lawyer know about programming?" That is to say, know that there's no way you can possibly know the in-depth field well enough to do more than the simplest of things. Get an expert.
You should know the basic rights and obligations of the license you are going to use. It's not that hard, and even if there are plenty of them, you need to read carefully only those you are going to use or touch. Just read them, in most cases they are quite clear.
Anything else you could need, well, that depends. Patenting ? Trademarks ? If you need these things, chances are that you are in a company and have a legal department to do this for you.
I would always assume that the developers of a project want any software using their work to be released under the exact same licence. Read their FAQs and legal pages for more information and don't hesitate to contact the developers/maintainers if you are still unsure.
If you want help understanding the details of a licence agreement, talk to a lawyer.
- Don't work in a country that has more lawyers than developers.
- An extremely large percentage of all (U.S.) software patents are bogus, but you can't pay or wait for them to be invalidated.
- If you want to use/develop open source software, use an existing license and don't modify it. Don't go near the borders of what the license is supposed to mean.
The name of a good IP lawyer.
6.If you have an employee who develops software "off the clock," you should make it clear who owns > that software, and what kind of software the employee should be able to write and distribute outside of the company.
freedom of speech right as stated in most constitutions (esp. if devs make free s/w off-the-clock) can make such terms fail miserably in courts
The law is not like code. It is not a well cast set of steps and rules that can be unambiguously understood.
참고URL : https://stackoverflow.com/questions/1396191/what-should-every-developer-know-about-legal-matters
'Development Tip' 카테고리의 다른 글
| Android Studio를 사용하여 공유 환경 설정 파일을 보려면 어떻게해야합니까? (0) | 2020.10.06 |
|---|---|
| Vuejs : 경로 변경 이벤트 (0) | 2020.10.06 |
| 데이터베이스에서 너무 많은 행이 몇 개 있습니까? (0) | 2020.10.06 |
| Django의 ./manage.py syncdb를 실행할 때 자동으로 관리자 사용자 생성 (0) | 2020.10.06 |
| Event.target이 Typescript의 요소가 아닌 이유는 무엇입니까? (0) | 2020.10.05 |