Whether you're starting an open source project or deciding whether to participate in one, you don't want to waste time in an endeavor that imposes arbitrary restrictions that will stop you in your tracks down the line.
The Open Source Initiative, of which I am president, has successfully focused on copyright licensing as a concrete expression of software freedom. OSI does not only provide guidance in the form of the Open Source Definition; it also manages a process by which the copyright licenses used for outbound licensing by open source authors can gain OSI approval.
Here’s a model I use in my consulting engagements to help clients work through their proposals for new open source community activities. Evaluating a project's licensing, patent, and community management strategy should begin with the question: How confident are community members that they have permission in advance to do what they need to succeed? See below for examples.
1. Am I granted copyright permission? An OSI-approved license guarantees this; does it apply to all your code? If there are portions of your code that remain proprietary, a community is not truly free to form around the code. Developers wanting to enhance or even deploy that portion of the code do not have permission in advance, so probably won’t want to join you.
2. Am I free to use my chosen business model? Copyleft licenses may limit certain business models, but issues arising from them aren’t usually directly to do with their copyleft terms. Communities use the GPL very effectively where the playing field is level -- the Linux kernel and the GNOME community both come to mind. More problematic is the use of strong copyleft license like the AGPL in conditions where the “project owner” is not subject to the terms of the license for trading. In these circumstances, one community member is free to engage in proprietary strategies while everyone else can only offer support or add-on businesses because any platform value-add would have to be donated to the business of that one community member.
3. Am I unlikely to suffer patent attack? It can never be prevented, but patent grants like the ones in modern open source licenses -- plus corporate pledges and nonaggression alliances like OIN -- can all help. Communities with no patent grants to protect people can feel like the Wild West, with the concern anyone could show up with weapons any time you’re successful.
4. Am I free to compete with other community members? Community rules that prohibit -- explicitly or tacitly -- competition with the sponsor reduce freedom. That includes any attempt at field-of-use restrictions -- which are banned in OSI-approved licenses but still show up in governance rules -- such as “not for mobile use” or “can’t be used for military purposes.”
5. Am I free to contribute my improvements? Copyright assignments get in the way, as does any mandatory agreement that will require legal review. I contribute back to reduce my maintenance and refactoring burden so that it’s not only philanthropy. It’s reasonable for a community to expect me to demonstrate competence before giving me commit rights, asking me to channel my work through others initially. It’s much less reasonable to insist I have to assign ownership of my work to a “project owner.” That chills participation, both by forcing me to effectively pay to participate and by forcing me to get legal advice first.
6. Am I treated as a development peer? Changes that are conducted in private, then “thrown over the wall” to the community rob potential collaborators of the confidence they have space to innovate. Why would you invest in significant new work, only to find the “project owner” rendering all your work moot with a bolt-from-the-blue code update? When the only way to be sure you’ve permission to innovate is to enter into a bilateral agreement with one company, you’re being treated as a client or partner and not as a community peer.
7. Am I inclusive of all people and skills? How do you license your documentation? Can I contribute to it? What about your user support community? Can I join in both to get and to give help? Do you have policies to discourage harassment of people who don’t seem to fit into your community norms? If people need to ask for any of those, that’s a lack of permission in advance as well.
Using the lens of “permission in advance” turns out to be an easy and useful tool for diagnosing your community governance. The seven points here aren’t the only concerns; which do you use for your own purposes? I would be interested to hear what tests others apply to community and project governance to determine whether there is truly freedom to collaborate.