我观察到很多人试图与 开源倡议组织的许可评估社区 和 Apache 软件基金会的法律事务委员会 进行沟通，我想为那些轮到您与开放社区进行法律讨论时提供一些提示和技巧，以帮助您取得成功。
不设代理
首先，也是最重要的是，确保进行对话的人员既合格又被授权。 不要派代理人；他们只会让社区感到沮丧，社区很快就会发现您的代表总是扮演二手车推销员的角色，并且总是跑到后台去讨价还价。 显然，法律讨论将涉及您公司的团队，可能包括产品管理、工程和内部法律顾问。 但代表需要能够自己进行对话，而不是一直传递来自幕后匿名人士的复制粘贴的引言。
多边性
开源社区就他们安全协作所需的确定性达成了来之不易的共识。 这种共识体现在他们的治理中，尤其体现在他们使用的开源许可中。 因此，当您提出新的提案时，它不像正常的商业交易。 这些是双边谈判，交易双方的自由，以缔结一项最佳妥协的和平条约。 在这次讨论中，您只是众多参与者之一，您需要解释为什么您的提案对每个人都有利。 谈判多边变革本质上是缓慢的，因此不要设定最后期限。 无论您做什么，都不要建议更改开源许可证！
先研究
现有的共识和流程存在是有原因的。 您应该理解每个要素的原因，最好还要了解其产生历史，然后再建议对其进行更改。 这样，您可以将您的提案置于进一步发展的背景下，并且可以避免接受社区历史的教育（这会浪费社区带宽并降低您的效率）。 回顾邮件列表，并向您的开发人员同事询问历史和背景。
透明度
开源开发人员使用迭代的、增量式的变更过程。 即使需要进行重大更改，它几乎总是会作为一系列较小的、解释清楚的或不言而喻的正确更改来交付，以便每个人都可以跟进并接受改进。 您提出的更改也是如此。 不要带着新的贡献者协议或修改后的许可证出现，并期望每个人都相信您是专家，因此一切都必须是好的。 您需要提供“红线”（相当于法律文件中的差异比较），记录每次更改，并提供一份理由，承认任何社区影响并证明其合理性。 如果您需要为了自己的利益而使某件事恰如其分，请承认这一点，而不是希望没有人会注意到。
谦逊
所以您是一位炙手可热的律师，您认为只有程序员才会使用邮件列表。 您很清楚他们会缺乏经验进行讨论，因此您要么派您认为与他们平等的代理人，要么将其全部简化，要么建议与社区选择的律师进行一对一的讨论。 很抱歉地说，您在所有方面都大错特错了。 由于社区的政策是多边共识，因此他们很有可能知道他们为什么会选择现在拥有的东西。 列表上会有些人拥有出色的特定领域知识，很可能比您更好。 而一对一的事情是最终的侮辱，就像问是否有成年人可以与您交谈一样。
不要暗箱操作
很可能存在某种领导机构。 也许您认识担任法律副总裁的公司老板。 也许您认识社区的总法律顾问。 虽然在某些情况下，询问如何驾驭流程的提示可能是可以接受的，但试图进行幕后讨论或谈判，期望影响甚至决定结果可能会适得其反。 您最终可能会被邀请进行一对一的讨论，但您永远不应该要求或期望它。
成为会员
如果您做的一切都正确，那么社区很可能会因此尊重您。 留下来。 建立您作为冷静、明智的贡献者的声誉。 当其他人出现并犯下您犯过的（或避免的！）错误时，帮助他们。 作为“$-legal”邮件列表社区中值得信赖的参与者，您对项目和您的雇主来说都是真正的财富。 继续贡献，一些项目最终会为您提供在其治理流程中担任角色的机会。
本文的早期版本最初发表于 Meshed Insights。
1 条评论