每个开发商都应该了解哪些法律事务？
今天我有一个糟糕的惊喜了解了GPL许可证的一些含义，主要是我不能像我想象的那样自由地使用它。
现在我知道了。
我还应该知道什么，更广泛地说，每个开发人员都应该了解此类法律问题的哪些内容？
您可以将员工、自由职业者、开源项目贡献者（等）分开，或者给出更广泛的答案。
Today I had a bad surprise learning about some implications of the GPL license, mainly that I couldn't use it as freely as I thought.
Now I know.
What else should I know, and more widely, what should every developer know about legal things like that?
You can separate employees, freelancers, open source projects contributors (etc.) or give a more broad answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
软件开发的十二个法律注意事项
如果软件向公众提供，则该软件受版权保护。不再需要在应用程序或源代码中添加版权声明。版权所有者是作者或向作者付费的公司。
软件的著作权可以由著作权人转让，也可以由著作权人保留，由著作权人将软件许可给用户。
开发中使用的库可能在使用和分发方面有限制。 GPL 并没有使库成为公共领域，库附带开发平台的事实也没有使库成为公共领域。在分发应用程序之前，您应该阅读并理解许可证。一些库需要支付版税，尽管近年来这种情况已不太常见。
软件专利诉讼毫无意义。当然，您不应该故意侵犯软件专利。然而，有些公司确实有可能因侵犯其专利而起诉您。即使您独立开发软件，您从未听说过该专利，并且该专利涵盖了直观上显而易见且几乎与您的软件完全无关的技术，也可能会发生这种情况。鉴于美国专利商标局当前的政策，除了购买保险之外，您没有什么办法可以避免这种情况。好消息是，专利流氓通常会花很多钱起诉大公司。
如果您使用员工或自由职业者来开发软件，您应该以书面形式明确谁拥有该应用程序的版权，包括源代码。一些自由职业者和合同开发公司将源代码视为自己的财产，从而使公司依赖于原始开发人员。如果开发协议中有规定，则这是合法的。
如果您有一名员工“不加班”地开发软件，您应该明确谁拥有该软件，以及该员工应该能够在公司外部编写和分发哪种软件。
如果您是开发软件的员工或自由职业者，您应该在开始开发之前明确谁将拥有您的应用程序的版权。此外，您应该知道或澄清谁拥有您自己编写的软件。一些公司在雇佣协议中包含条款，声称对开发人员在雇佣期间（无论是在家还是在工作）编写的任何软件拥有所有权。许多公司在雇佣协议中都有非竞争条款，限制员工可以生产并在公司外部分发的软件。有时这些限制相当广泛。
商标是名称或符号，而不是软件本身。如果您分发软件，您应该 (a) 确保您的应用程序名称和名称的“标记”或设计不与其他应用程序“令人困惑地相似”，并且 (b) 注册您的商标。首次使用日期对于解决冲突非常重要，因此您应该记录应用程序首次在商业中使用的时间。
当您为应用程序命名时，请检查注册商标，同时还要检查 Google。首次使用该名称的应用程序可能会在您的申请成功后获得您的名称和商标，即使他们尚未注册该商标而您已经注册。
当您使用或签署合同或协议时，请确保双方均理解。在雇佣协议中，提前提及任何潜在的敏感领域可以防止以后出现很多问题。在开发协议中，如果双方都知道谁拥有源代码，或者谁负责升级，或者谁负责维护等，进入开发项目，那么申请后发生诉讼的可能性就会小很多已完成。在分销协议中，确保分销商了解协议的责任和条款。
每个重要的应用程序都有错误（或“设计考虑因素”:-)）。任何用户协议或分发协议都应明确您不对无错误的软件负责，并且不能指望您修复所有错误。明确指出更改、修复和升级是由开发人员选择（或尽最大努力）进行的，并明确谁为修复和升级付费。
即使您就软件开发和分发协议咨询了律师，您也应该阅读其他软件公司的协议，看看他们的律师提出了什么建议。
即使
我不是律师，这不是法律建议。
Twelve Legal Considerations for Software Development
Software is copyrighted if it is made available to the general public. It is no longer necessary to put a copyright notice on the application or in the source code. The owner of the copyright is the author(s) or company paying the author(s).
The copyright of software can be assigned by the owner of the copyright, or it can be retained by the owner and the software can be licensed to the user or users by the owner.
Libraries used in development probably have restrictions in their use and distribution. GPL does not make a library public domain, nor does the fact that the library comes with a development platform. You should read and understand the license before you distribute your application. Some libraries require royalty payments, although this has become less common in recent years.
Software patent lawsuits are crap shoots. You should not, of course, knowingly violate a software patent. However, there is a small but real chance some company will sue you for violating their patent. This may happen even if you develop your software independently, you never heard of the patent, and the patent covers a technique that is intuitively obvious and almost completely unrelated to your software. There is not a lot you can do to avoid this, given the current USPTO policies, other than buy insurance. The good news is that patent trolls generally sue large companies with lots of money.
If you use an employee or freelancer to develop software, you should make it clear, in writing, who owns the copyright to the application, including the source code. Some freelancers and contract development companies consider the source code their own property, leaving the company dependent on the original developer(s). This is legal if it's in the development agreement.
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.
If you are an employee or freelancer developing software, you should make it clear who will own the copyright to your application, before you begin development. Also, you should know or clarify who owns software you write on your own time. Some companies have clauses in employment agreements claiming ownership to any software written by a developer during the period of employment, whether at home or at work. Many companies have non-compete clauses in employment agreements that restrict the software an employee can produce for distribution outside the company. Sometimes these restrictions are pretty broad.
A trademark is a name or symbol, not the software itself. If you distribute software, you should (a) make sure your application name and "mark" or design of the name is not "confusingly similar" with other applications, and (b) register your trademark. Date of first use is important in resolving conflicts, so you should document when the application is first used in commerce.
When you name an application, check for registered trademarks, but also check Google. An application with first use of the name may be able to take your name and trademark after your application is successful, even if they have not registered the trademark and you have.
When you use or sign a contract or agreement, make sure both parties understand it. In an employment agreement, mentioning any potentially sensitive areas up front can prevent a lot of problems later. In a development agreement, if both parties know who owns the source code, or who is responsible for upgrades, or who is responsible for maintenance, etc., going into the development project, then there is much less likelihood of a lawsuit after the application has been completed. In a distribution agreement, make sure the distributor understands the responsibilities and term of the agreement.
Every non-trivial application has bugs (or "design considerations" :-)). Any user agreement or distribution agreement should make it clear that you are not responsible for bug-free software, and you cannot be expected to fix all bugs. Make it clear that changes, fixes, and upgrades are made at the option (or best efforts) of the developer, and make it clear who pays for fixes and upgrades.
Even after you consult a lawyer about software development and distribution agreements, you should read agreements from other software companies and see what their lawyers came up with.
I am not a lawyer, and this is not legal advice.
如有疑问，请联系律师。
When in doubt, contact a lawyer.
我不是律师，但随着时间的推移，我从法律人士那里收集了一些经验法则，您可以使用它们来节省时间：
.dll/.so是您无需承担任何义务即可“使用”LGPL 代码的方法之一，除了适当的版权声明。联系开源项目的维护者通常会有所帮助。他们最有能力向您提供关于许可证的初衷以及他们自己对开源的看法的建议。有时维护人员愿意发布多个许可证下的软件来帮助您。通常情况并非如此。取决于拥有版权的人。
KDE 项目有一个方便的矩阵
I'm no lawyer but over time I have gathered a few rules of thumb from legal people that you can use to save time:
.dll/.soof the library is one of the ways you can 'use' LGPL-ed code without any obligations, except for the proper copyright notice.It often helps to contact the maintainer of the Open Source project. They are in the best position to advice you about the original intention of the license as well as their own views on open source. Sometimes maintainers are willing to release software under multiple licenses to help you out. Often they are not. Depends on the person who owns the copyright.
The KDE project has a handy matrix
我认为网络和法律指南Stephen Fishman 律师的软件开发正是您所寻找的。
其他一些建议：
I think Legal Guide to Web & Software Development by Stephen Fishman Attorney is what you're looking for.
Some other suggestions :
如果是自由职业者或承包商：请确保您拥有良好的责任保险并了解其承保范围。
例如，我的保险不承担可能暴露信用卡号码的代码错误的责任。所以我不再碰那些东西了！
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!
对于员工：我们应该能够向您的客户提供第一轮建议 - 比如他们/我们可以在他们的应用程序中使用我们想要的组件吗？
对于自由职业者：我们必须能够为您的客户提供强有力的建议；并选择我们可以为他们开发的应用程序使用哪些组件。
当然，你的话不如律师给你的建议那么好；但你已经可以帮助第一轮了；例如，说“我们绝对不能使用这个，因为这意味着……”
最后，律师会对极端案例了解很多——但如果你能帮忙一点……
对于 OSS 贡献者：如果您关心人们可以用您的代码做什么（重新分发？修改？在商业应用程序中使用它？在专有应用程序中使用它？），了解免费许可证之间的一些差异可能很重要。
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 ? )
一个答案断言法律不像代码。我不同意。
早期，IBM 按指令向程序员支付报酬。 一个人说他和一个通过这种方式致富的程序员一起工作。显然这个人不知道如何使用机器的索引寄存器；他编写了一个内存清零例程，在每个内存地址中手动存储零。）
（我认识的 还有一个时期（很久以前），律师是按字面报酬的。这有助于普及一些做法，例如称呼人们为“最受尊敬的某某”以及其他冗长的措辞。
我刚刚读到一个关于 VB.NET 2008 仍然允许行号的答案。您仍然可以在现代 PC 上运行纯 DOS。所有 COBOL 程序都是通过增量变化从一个共同的祖先传下来的，这个笑话是有道理的。向后兼容性和“历史原因”在我们的领域很普遍。
这堪比法则境界。有些法律会对其他法律进行小（或大）修改。你已经陷入了一种依赖地狱。有一些荒唐的历史法律（在塔斯马尼亚州的霍巴特，日落之后男人穿女装是违法的——因为从前，罪犯会打扮成女人，扮鬼脸），没有人会梦想去执行，就像软件中有一些历史功能现在没有人再使用了。
法律通常会产生意想不到的后果（错误！），以创造性的方式使用（黑客！），包含漏洞（安全漏洞！），其中一些是故意的（后门！），被修改（补丁！）或被推翻（卸载！） 。
是的，法律（与法规不同）需要解释。但我认为这很像代码维护。它有助于调整法律以适应新的社会规范。
直接回答这个问题：每个开发人员都应该知道，法律就像一个已经开发了数百年的极其庞大的软件项目。 （实际上，每个国家都有自己的项目，他们以不同的方式解决问题。）理论上，读完许可证后你就会知道你可以用你的代码做什么和不能做什么。但是，如果一个有能力的程序员仅仅通过阅读代码无法发现代码中的所有错误，那么非律师又有什么机会分析法律文档的极端情况和灰色区域呢？
与软件源代码一样，您通常可以通过阅读法律文档来了解其要点，但如果您需要了解特定内容，请询问专业人士。
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（我不为他们工作）为外行出版了一套很好的法律书籍。
http://www .nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
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.
一位优秀知识产权律师的名字。
The name of a good IP lawyer.
大多数宪法中规定的言论自由权（特别是如果开发者不时提供免费软件）可能会使这些条款在法庭上惨遭失败
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.