每个开发人员应该了解法律事务?

mar*_*cgg 80 licensing open-source

今天,对GPL许可证的一些含义感到惊讶,主要是因为我不能像我想象的那样自由地使用它.

现在我知道了.

我应该知道什么,更广泛地说,每个开发人员应该知道这样的法律事务?

您可以将员工,自由职业者,开源项目贡献者(等)分开,或者给出更广泛的答案.

xpd*_*pda 135

软件开发的十二个法律考虑因素

  1. 如果软件可供公众使用,则软件受版权保护.不再需要在应用程序或源代码中提供版权声明.版权所有者是向作者付费的作者或公司.

  2. 软件的版权可以由版权所有者分配,或者可以由所有者保留,并且软件可以由所有者许可给用户或用户.

  3. 开发中使用的库可能在使用和分发方面受到限制.GPL不会使库成为公共领域,也不会使库附带开发平台.在分发应用程序之前,您应该阅读并理解许可证.一些图书馆需要支付版税,尽管近年来这种情况已经不那么常见了.

  4. 软件专利诉讼是废话.当然,您不应该故意违反软件专利.但是,有些公司会因违反专利而起诉你.即使您独立开发软件,您从未听说过该专利,也可能会发生这种情况,该专利涵盖了一种直观明显且与您的软件几乎完全无关的技术.鉴于目前的USPTO政策,除买入保险外,没有太多可以避免的事情.好消息是,专利巨魔通常会以大量资金起诉大公司.

  5. 如果您使用员工或自由职业者开发软件,您应该以书面形式明确谁拥有该应用程序的版权,包括源代码.一些自由职业者和合同开发公司认为源代码是他们自己的财产,使公司依赖于原始开发人员.如果它在开发协议中,这是合法的.

  6. 如果您有一名员工"全天候"开发软件,您应该明确谁拥有该软件,以及该员工应该能够在公司外部编写和分发哪种软件.

  7. 如果您是开发软件的员工或自由职业者,您应该在开始开发之前明确谁将拥有您的应用程序的版权.此外,您应该知道或澄清谁拥有您自己编写的软件.一些公司在雇佣协议中有条款声称对开发商在雇佣期间撰写的任何软件拥有所有权,无论是在家还是在工作.许多公司在雇佣协议中都有不竞争条款,这些条款限制了员工可以生产以在公司外部分发的软件.有时这些限制非常广泛.

  8. 商标是名称或符号,而不是软件本身.如果您分发软件,您应该(a)确保您的应用程序名称和"标记"或名称的设计与其他应用程序不"混淆地相似",并且(b)注册您的商标.首次使用日期对于解决冲突很重要,因此您应该记录应用程序首次在商业中使用的时间.

  9. 当您为应用程序命名时,请检查注册商标,还要检查Google.首次使用该名称的申请可能会在您的申请成功后获取您的姓名和商标,即使他们尚未注册您的商标.

  10. 当您使用或签署合同或协议时,请确保双方都理解它.在就业协议中,预先提及任何潜在的敏感区域可以防止以后出现很多问题.在开发协议中,如果双方都知道谁拥有源代码,谁负责升级,谁负责维护等,进入开发项目,则申请后诉讼的可能性要小得多.已经完成.在分销协议中,确保分销商了解协议的责任和期限.

  11. 每个非平凡的应用程序都有错误(或"设计考虑因素":-)).任何用户协议或分发协议都应明确表明您不对无错误的软件负责,并且不能指望您修复所有错误.明确指出,开发人员可以选择(或尽最大努力)进行更改,修复和升级,并明确谁为修复和升级付费.

  12. 即使在您咨询律师有关软件开发和分销协议之后,您也应该阅读其他软件公司的协议,看看他们的律师提出了什么.

  13. 我不是律师,这不是法律建议.

  • 我接受了这个答案,因为它真的很有趣,并且自最近添加以来不会得到太多的看法.同样有趣的答案是:http://stackoverflow.com/questions/1396191/what-should-every-developer-know-about-legal-matters/1448419#1448419.当然,每个人都提到咨询律师很重要的事实. (4认同)

mmr*_*mmr 28

如有疑问,请联系律师.

  • ......并且在怀疑方面犯了错误. (18认同)
  • 如果有疑问,是的.但"有疑问"应该足够小,以至于我们并不都需要让律师留在保留者身上.任何开发人员都应该对知识产权法有合理的理解,并清楚地了解共同的开源许可所施加的限制和义务.律师们提出了难题. (3认同)
  • 我的想法是,如果你知道一些东西,你将能够更容易地告诉需要联系律师.就像吉姆所说的这个问题的评论一样,有些人认为"它是开源的.你可以随心所欲地做任何事情." (2认同)

leo*_*onm 26

我不是律师,但随着时间的推移,我从合法的人那里收集了一些你可以用来节省时间的经验法则:

  • GPL许可证是"复制左"或"病毒式".这意味着您编写的依赖于GPL组件的任何代码也必须在GPL下发布.一个好的经验法则是,如果您需要GPL组件来编译您的软件,您的软件必须在GPL许可下发布.
  • 如果您不分发软件,则无需提供源代码.例如,如果您为内部目的或在Web服务器上运行该软件,则无需释放源.这就是Google不需要发布使用GPL库的软件的原因.这是GPL v3中的一个关键争论点.
  • 如果您将LGPL-ed库合并为不可替代的LGPL,则LGPL(库或较小的GPL)仅要求您使用GPL自己的源代码.如果您只是"使用"库,则您自己的软件不需要是GPL.包括头文件和链接到的.dll/ .so库的是,你可以"使用" LGPL-ED代码没有任何义务,除了适当的版权声明的方式之一.
  • BSD许可证(Apache许可证非常相似)允许您创建使用开源组件的商业扩展.这就是为什么Apple选择FreeBSD而不是Linux作为OSX的内核.
  • MPL非常友好,因为Netscape认为在编写许可证时他们可能会从Mozilla赚到一些钱.

通常有助于联系开源项目的维护者.他们最有可能向您提供有关许可的初衷以及他们对开源的看法.有时,维护者愿意在多个许可证下发布软件来帮助您.通常他们不是.取决于拥有版权的人.

KDE项目有一个方便的矩阵

  • 对第一点的一个修正:仅当"依赖于"涉及(动态或静态地)将GPL代码链接到程序的可执行文件中或以其他方式错综复杂地将程序捆绑在一起(例如,内存转储).如果您为Linux编写了一个使用grep的专有程序,并且仅适用于GNU版本,那么只要grep代码不在您的可执行文件中,您仍应该没问题.但是,IANAL. (2认同)
  • 方便矩阵的链接不再返回方便的矩阵. (2认同)

Moa*_*ini 8

我认为Stephen Fishman Attorney的网络和软件开发法律指南正是您所需要的.

替代文字

评论

一本很棒的书!回答几乎所有你能想象到的法律问题和一些你从未想过的问题. - PC杂志John Dvorak

涵盖了对这种快速增长和无形媒介重要的每一个可以想象的细节. - 企业家

本书通过了我自己的法律指南测试 - 比任何其他法律指南都高. - Jeff Duntemann,PC技术杂志编辑

产品描述

保护您的权利和您的辛勤工作!

涉及网站和软件开发的法律既复杂又令人困惑,但如果你不解开它们,可能会花费你数千美元的律师费和诉讼费.

幸运的是,网络和软件开发法律指南彻底解读了这个复杂的法律领域,并且对读者友好的英语进行了解读.它还提供CD-ROM上的合同,协议和法律形式,并提供逐步说明,以便您可以保护您的软件和网站,而无需支付律师的赎金.

使用Web和软件开发的法律指南来学习:

  • 你需要什么样的法律保护
  • 每种保护的优点和局限
  • 如何避免侵权
  • 在起草协议时您需要哪些条款
  • 如何获得使用他人材料的许可

你会找到完整的,逐步的草稿说明:

  • 就业协议
  • 承包商和顾问协议
  • 发展协议
  • 许可协议

第5版"网络与软件开发法律指南"已完全更新,以提供最新的判例法和法定修订版.

其他一些建议: