关于法律事务的java程序
观察到有很多人试图加入开放源代码计划的许可评估社区和Apache软件基金会的法律事务委员会 ,我想为您提供一些提示和技巧,以帮助您在轮到您进行法律讨论时与他人进行交流。开放社区。
没有代理
首先,要确保进行对话的人既有资格又有能力 。 不要发送代理; 他们只是让社区感到沮丧,他们很快就发现您的代表一直在扮演二手车推销员的角色,然后去后室索要一笔交易。 显然,法律讨论将涉及您公司的团队,可能涉及产品管理,工程和内部法律顾问。 但是,代表必须能够自己进行对话,而不是在幕后继续传递匿名人物提供的切工报价。
多边性
开源社区就安全协作所需的确定性达成了来之不易的共识。 这种共识体现在他们的治理中,尤其是他们使用的开源许可证中。 因此,当您提出新建议时,这并不像正常的业务交易。 那是双边谈判,交易了两党的自由,以缔结最佳妥协的和平条约。 在此讨论中,您只是众多团体中的一员,您需要解释为什么您的提案对所有人都有好处。 谈判多边变化本质上是缓慢的,因此不要有最后期限。 无论您做什么,都不要建议更改开源许可证!
先学习
存在现有共识和过程是有原因的。 在建议进行更改之前,您应该了解每个元素的原因,最好与它的产生历史一起了解。 这样一来,您就可以在进一步发展的情况下提出建议,并且可以避免在社区历史中受限制(这浪费社区带宽并降低了获得成功的机会)。 重新阅读邮件列表,并询问您的开发人员同事的历史和上下文。
透明度
开源开发人员使用迭代的,增量的更改过程。 即使需要进行大的更改,也几乎总是将其作为一系列较小的,经过充分解释或不言而喻的正确更改来交付,以便每个人都可以跟进并接受改进。 您提议的更改也是如此。 不要出现新的贡献者协议或修改后的许可证,不要期望所有人都相信您是专家,所以一切都必须很好。 您需要提供一个“红线”(等同于差异的法律文件),记录每个更改,并提供一个可以接受任何社区影响并为之辩护的理由。 如果你需要一个事情是只是如此为自己的利益,承认它,而不是希望没有人会注意到。
谦逊
因此,您是一名炙手可热的律师,并且您认为只有程序员才能使用邮件列表。 很明显,他们缺乏讨论的经验,因此您可以发送自己认为平等的代理人,将其愚弄,或建议与社区选定的律师进行一对一讨论。 很遗憾地说您是如此,在所有方面都错了。 由于社区的政策是多边共识,因此他们有很大的机会知道为什么要解决目前的问题。 名单上会有一些人具有出色的特定领域知识,可能会比您的要好。 一对一的事情是最终的侮辱,例如询问是否有可以与之交谈的成年人。
不要反向传播
可能会有某种领导机构。 也许您认识VP Legal所在公司的老板。 也许您知道社区的法律总顾问。 在某些情况下,尽管寻求有关如何导航过程的提示可能是可以接受的,但尝试进行反向渠道讨论或谈判时却希望影响甚至确定结果,可能会严重倒退。 最终可能会邀请您进行一对一的讨论,但是您绝对不要要求或期望它。
成为会员
如果您做对了所有事情,社区很可能会尊重您。 停在附近。 建立一个冷静,明智的贡献者的声誉。 当他人出现并犯下您犯的错误(或避免错误!)时,请帮助他们。作为“ $ -legal”邮件列表社区中值得信赖的参与者,您对项目和雇主都是真正的财富。 继续做出贡献,某些项目最终将为您提供其治理过程中的作用。
本文的早期版本最初出现在Meshed Insights中。
翻译自: https://opensource.com/open-organization/17/3/legal-matters-community
关于法律事务的java程序