Having watched a fair number of people attempt to engage both the Open Source Initiative's licensing evaluation community and the Apache Software Foundation's legal affairs committee, 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 at Meshed Insights.
1 Comment