7 Rules For Engaging Communities On Legal Matters


Having watched a fair number of people attempting to engage both the Open Source Initiative’s licensing evaluation community and the Apache Software Foundation’s legal affairs committee, here are some hints and tips for succeeding when your turn comes to conduct a discussion over legal terms with an open source community.

When you need to discuss a license, a legal document like a CLA or a governance rule with an open source community, what’s the best approach to take?

  1. 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. Legal discussions obviously will involve a team at your company, probably including product management, engineering and in-house counsel. But your representative needs to be able to hold the conversation themselves and not keep delivering cut & paste quotes from anonymous personae behind the curtain.
  2. 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. The culture is different here too – don’t assume anyone shares your objectives. 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!
  3. 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, as well as avoid being schooled in community history, something that wastes community bandwidth and reduces your chances of effectiveness. Read back in the mailing list and ask your developer colleagues for history and context.
  4. 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 so for your own benefit, admit it rather than hoping no-one will notice.
  5. Humility
    So you are a hot-shot lawyer and you think the mailing list comprises all programmers. 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 1:1 discussion with the community’s chosen lawyer. Sorry to say 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 1:1 thing is the ultimate insult, like asking if there is an adult you can speak with.
  6. 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 OK 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 1:1 discussion, but you should never demand or expect it.
  7. 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.

This article was originally published in Meshed Insights, and was made possible by Patreon patrons.

Image credit: "7Rules.jpeg" is a derivative of "Silhouettes, Against, Nonconformist, Anti, Anders" via Max Pixel, used under CC0 Public Domain. "7Rules.jpeg" is licensed under CC BY 4.0 by The Open Source Initiative