document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

translated

Browse Source
This commit is contained in:
geekpi 2017-06-26 09:02:12 +08:00
parent f047146211
commit 9ea2b39b28
2 changed files with 65 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
sources/talk/20170321 7 ways to discuss legal matters with an open community.md
View File

@ -1,67 +0,0 @@
translating------geekpi
7 ways to discuss legal matters with an open community
============================================================
> Are your organization's lawyers ready to engage an open community? Don't let them make these mistakes.
![7 ways to discuss legal matters with an open community](https://opensource.com/sites/default/files/styles/image-full-size/public/images/law/LAW-Internet_construction_9401467_520x292_0512_dc.png?itok=xmtgmowQ "7 ways to discuss legal matters with an open community")
>Image by : opensource.com
Having watched a fair number of people attempt to engage both the [Open Source Initiative's licensing evaluation community][3] and the [Apache Software Foundation's legal affairs committee][4], I'd like to offer some hints and tips for succeeding when it's  _your_  turn to conduct a legal discussion with an open community.
### No proxies
First and foremost, make sure the person conducting the conversation is both  _qualified_  and  _empowered_ . Don't send proxies; they simply frustrate the community, who quickly work out that your representative is always playing the second-hand car salesman and going to the back room to ask for a deal. Obviously, legal discussions will involve a team at your company, probably involving product management, engineering and in-house counsel. But the representative needs to be able to hold the conversation themselves and not keep delivering cut paste quotes from anonymous personae behind the curtain.
### Multilaterality
An open source community reaches a hard-won consensus on the certainties they need in order to collaborate safely. That consensus gets embodied in their governance and especially in the open source license they use. So when you come with a new proposal, it's not like a normal business deal. Those are bilateral negotiations, trading the freedoms of the two parties to create a peace treaty that's an optimal compromise. In this discussion you are just one of many, many parties, and you need to explain why your proposal is good for everyone. Negotiating multilateral change is inherently slow, so don't come with a deadline. And whatever you do, don't suggest changes to the open source license!
### Study first
The existing consensus and process exists for a reason. You should understand the reason for each element, preferably along with the history of how it arose, before suggesting changes to it. That way you can couch your proposals in the context of further evolution, and you can avoid being schooled in community history (something that wastes community bandwidth and reduces your chances of effectiveness). Read back through the mailing list and ask your developer colleagues for history and context.
### Transparency
Open source developers use a process of iterative, incremental change. Even if a big change is needed, it will almost always be delivered as a sequence of smaller, well-explained or self-evidently correct changes so that everyone can follow along and buy in to the improvement. The same is true of your proposed change. Don't show up with a new contributor agreement or a modified license and expect everyone to trust that you're experts so it must all be good. You need to provide a "red-line" (the legal document equivalent of a diff), document each change, and provide a justification that admits any community impact and justifies it. If you need a thing to be  _just so_  for your own benefit, admit it rather than hoping no one will notice.
### Humility
So you are a hot-shot lawyer and you think only programmers use the mailing list. It's clear to you that they'll lack the experience to have a discussion, so you either send a proxy you think is their equal, dumb it all down, or propose having a one-on-one discussion with the community's chosen lawyer. I'm sorry to say that you are so, so wrong on all counts. Since the community's policy is a multilateral consensus, there is a really good chance they know why they settled on what they have now. There will be some people on the list with excellent domain-specific knowledge, likely to be better than yours. And that one-on-one thing is the ultimate insult, like asking if there is an adult you can speak with.
### Don't back-channel
There may well be a leadership body of some kind. Maybe you know the boss at the company where the VP Legal works. Perhaps you know the community's General Counsel. While asking for hints on how to navigate the process may be acceptable in some circumstances, trying to conduct a back-channel discussion or negotiation with the expectation of influencing or even determining the outcome can blow back badly. You may eventually be invited for a one-on-one discussion, but you should never demand or expect it.
### Become a member
If you do everything right, chances are that the community will respect you for it. Stick around. Build your reputation as a calm, wise contributor. Help others when they show up and make the mistakes you made (or avoided!) As a trusted participant in the "$-legal" mailing list community, you are a real asset to both the project and your employer. Keep contributing and some projects will eventually offer you a role in their governance process.
_An earlier version of this article [originally appeared][1] at Meshed Insights._
--------------------------------------------------------------------------------
作者简介：
Simon Phipps - Computer industry and open source veteran Simon Phipps started Public Software, a European host for open source projects, and volunteers as a director at The Document Foundation. His posts are sponsored by Patreon patrons - become one if you'd like to see more!
------------
via: https://opensource.com/open-organization/17/3/legal-matters-community
作者：[ Simon Phipps][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/simonphipps
[1]:https://meshedinsights.com/2017/02/28/engaging-communities-on-legal-matters-7-tips/
[2]:https://opensource.com/open-organization/17/3/legal-matters-community?rate=gSFbyOzBTIipXOdeeL-GVIT1BYoC4f61FKZJ7KRg3d0
[3]:https://opensource.org/approval
[4]:https://www.apache.org/legal/
[5]:https://opensource.com/user/12532/feed
[6]:https://opensource.com/open-organization/17/3/legal-matters-community#comments
[7]:https://opensource.com/users/simonphipps

65
translated/talk/20170321 7 ways to discuss legal matters with an open community.md Normal file
View File

@ -0,0 +1,65 @@
与开放社区讨论法律事宜的 7 种方式
============================================================
> 你的组织的律师准备好参加开放社区了么？不要让他们犯这些错。
![7 ways to discuss legal matters with an open community](https://opensource.com/sites/default/files/styles/image-full-size/public/images/law/LAW-Internet_construction_9401467_520x292_0512_dc.png?itok=xmtgmowQ "7 ways to discuss legal matters with an open community")
>图片提供： opensource.com
我注意到有相当多的人尝试同时参与[开源倡议的许可评估社区] [3]以及[ Apache 软件基金会的法律事务委员会][4]，我想提供一些成功的提示和技巧在当轮到_你_与开放社区进行法律讨论时。
### 不要代理人
首先要确保进行谈话的人员既有_资格_，又有_授权_。不要用代理人，这只会让社区沮丧，他们很快会发现你的代表总是扮演二手车推销员的角色并且到后面的房间要求交易。显然，法律讨论将涉及公司的一个团队，可能涉及产品管理、工程和内部咨询。 但代表们需要能够自己进行谈话，不要总是引用幕后匿名人物的话。
### 多边主义
一个开源社区就安全合作所需的确定性达成了难得一致的共识。这种共识体现在其治理中，尤其是在他们使用的开源许可证中。所以当你提出一个新的提案时，这不是一个正常的商业交易。这些是双边谈判，交换双方的自由创造一个最佳妥协的和平条约。在这个讨论中，你只是许多方面之一，你需要解释为什么你的提案对所有人都有好处。谈判多边变化本质上是缓慢的，所以不要设置最后期限。无论你做什么，不要建议对开源许可证进行更改！
### 首先学习
现有的共识和过程存在一个原因。你应该了解每个元素的原因，最好连同其发生的历史一起了解，然后再提出修改。这样，你可以在进一步发展的背景下表达你的提案，这样你可以避免在社区历史中受教育（浪费社区资源，降低你机会的有效性）。回看邮件列表，并向开发人员询问历史和来龙去脉。
### 透明
开源开发人员使用一个迭代、增量修改的过程。即使需要大的变化，它几乎总是用一系列更小，更好的解释或不言而喻的正确变化来实现的，这样每个人都可以跟进并支持。你提出的更改也是如此。不要出现新的贡献者协议或者修改过的许可证，并期望每个人都相信你是专家，所以一切都是好的。你需要提供一根“红线”（相当于法律文件的差异），记录每个变化，并提供一个承认任何社区影响的里有并为其辩护。如果你_只是_为了你自己的利益需要一个东西，承认它，而不是希望没有人会注意到。
### 谦逊
你是一个炙手可热的律师，你认为只有程序员使用邮件列表。很明显，对你而言他们缺乏讨论的经验，所以你排了一个你认为是同等的代理人，简化这一切，或者提出与社区选择的律师进行一对一的讨论。 我很抱歉地说你做的都是错的。由于社区的政策是多边协商一致的，所以他们很有可能知道他们现在的决定。名单上的一些人将具有优秀的领域知识，可能会比你的更好。而且一对一这件事是终极的羞辱，就像询问是否有一个成年人可以与你说话。
### 不要后台渠道
有可能是某种领导机构。也许你认识在公司法务工作的 VP。也许你认识社区的总法律顾问。虽然在某些情况下，询问如何操控流程的提示可能是可以接受的，但试图影响甚至决定结果的方式进行后台渠道讨论或协商, 那么结果会很糟糕。你最终可能会被邀请进行一对一的讨论, 但你不应该要求或期待。
### 成为一个成员
如果你一切都做得正确，那么社区就有可能尊重你。坚持这些。作为一名冷静、机智的贡献者建立你的声誉。当人们犯你犯过的错误（或者已避免的）时，帮助他们。作为邮件列表社区的值得信赖的参与者，你是项目和雇主的真正资产。继续贡献，一些项目最终会在它们的治理中为你提供一个角色。
_这个文章的早期版本[最初发表][1]在 Meshed Insights 中。_
--------------------------------------------------------------------------------
作者简介：
Simon Phipps - 计算机行业和开源老手 Simon Phipps 上线了 Public Software，一个欧洲的开源项目托管，Document Foundation 的志愿者总监。他的帖子由 Patreon 赞助者赞助 - 如果你想要看更多，成为其中一个！
------------
via: https://opensource.com/open-organization/17/3/legal-matters-community
作者：[ Simon Phipps][a]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/simonphipps
[1]:https://meshedinsights.com/2017/02/28/engaging-communities-on-legal-matters-7-tips/
[2]:https://opensource.com/open-organization/17/3/legal-matters-community?rate=gSFbyOzBTIipXOdeeL-GVIT1BYoC4f61FKZJ7KRg3d0
[3]:https://opensource.org/approval
[4]:https://www.apache.org/legal/
[5]:https://opensource.com/user/12532/feed
[6]:https://opensource.com/open-organization/17/3/legal-matters-community#comments
[7]:https://opensource.com/users/simonphipps