你的组织的律师准备好与开源社区打交道了么？不要让他们犯这些错。
我注意到有相当多的人尝试与开源推进联盟的许可证评估社区以及 Apache 软件基金会的法律事务委员会建立沟通，当轮到你与开放社区进行法律讨论时，我想提供一些成功的提示和技巧。
不要代理人
首先，也是最重要的是，要确保进行谈话的人员既是有资格的，也是有授权的。不要用代理人，这只会让社区沮丧，他们很快会发现你的代表总是扮演二手车推销员的角色并且要求到后面的房间交易。显然，法律讨论将涉及公司的一个团队，可能涉及产品管理、工程和内部咨询。 但代表们需要能够自己控制谈话内容，不要总是引用幕后某个匿名人物的话。
多边主义
开源社区就安全合作所需的确定性达成了难得一致的共识。这种共识体现在其治理中，尤其是在他们使用的开源许可证中。所以当你提出一个新的提案时，就不像是一个普通的商业交易。这些是双边谈判，以双方的自由为代价来创造一个最佳妥协的和平条约。在这个讨论中，你只是许多方面之一，你需要解释为什么你的提案对所有人都有益。写上多边之间的调整本质上是缓慢的，所以不要设置最后期限。无论你做什么，不要建议对开源许可证进行更改！
首先学习
现有的共识和过程其存在是有原因的。你应该了解每个元素的原因，最好连同其发生的历史一起了解，然后再提出修改。这样，你可以在进一步发展的背景下表达你的提案，这样你可以避免在社区历史中受教育（浪费社区资源，降低你机会的有效性）。回看邮件列表，并向开发人员询问历史和来龙去脉。
透明
开源开发人员使用一个迭代、增量修改的过程。即使需要大的变化，它几乎总是用一系列更小、更好的解释或不言而喻的正确变化来实现的，这样每个人都可以跟进并支持。你提出的更改也是如此。不要弄出新的贡献者协议或者修改过的许可证，并期望每个人都相信你是专家、一切都是对的。你需要提供一根“红线”（相当于法律文件的差异），记录每个变化，并提供一个承认任何社区影响并为其辩护的理由。如果你只是为了你自己的利益需要一个东西，那就承认它，而不是希望没有人会注意到。
谦逊
你是一个炙手可热的律师，而你认为只有程序员才使用邮件列表。很明显，对你而言他们缺乏讨论的经验，所以你安排了一个你认为是同等的代理人，简化这一切，或者提出与社区选择的律师进行一对一的讨论。 我很抱歉地说你做的全都是错的。由于社区的政策是多边协商一致的，所以他们很有可能知道他们为什么定下现在的这些决定。名单上的一些人将具有优秀的领域知识，可能会比你的更好。而且一对一这件事是终极的羞辱，就像询问是否有一个成年人可以与你说话。
不要秘密渠道
有可能在某种领导机构，也许你认识在公司法务工作的 VP，也许你认识社区的总法律顾问。虽然在某些情况下，询问如何操控流程的提示可能是可以接受的，但尝试通过秘密渠道讨论或协商来试图影响甚至决定结果，那么结果会很糟糕。你最终可能会被邀请进行一对一的讨论, 但你不应该要求或期待它。
成为一个成员
如果你一切都做得正确，那么社区就有可能尊重你。坚持这些。作为一名冷静、机智的贡献者建立你的声誉。当人们犯你犯过的错误（或者已避免的）时，帮助他们。作为邮件列表社区的值得信赖的参与者，你是项目和雇主的真正资产。继续贡献，一些项目最终会在它们的治理中为你提供一个角色。
这个文章的早期版本最初发表在 Meshed Insights 中。
（题图： opensource.com）
via: https://opensource.com/open-organization/17/3/legal-matters-community
作者：Simon Phipps 译者：geekpi 校对：wxy
发表回复