Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.

I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license. 

In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.

Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:

1. Am I granted rights permissions? An OSI-approved license guarantees this; does it apply to all the code? If there are portions of the code that remain proprietary or wrapped in additional terms that amount to a “constructive restriction“, 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 even for the portions where they do.

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 combination with a contributor agreement that means the “project owner” is not subject to the terms of the license for their own 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 demands? It can never be prevented, but patent grants like the ones in modern open source licenses — plus corporate pledges and nonaggression alliances like OIN or LOTN — 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. While patent demands can always come from afar, most patents related to a given codebase actually arise close to where it was written. Projects built around de jure standards that permit “FRAND” patent royalty demands are also likely to find this will happen.

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 “not for cloud deployment” or “can’t be used for military purposes.” Watch especially for contractual controls outside the scope of the actual code, such as to participate in an app store or to use components or apps that are essential for participation in the platform ecosystem.

5. Am I free to contribute my improvements?  That’s a matter of the rate of acceptance of pull requests, of course. But it also applies when contributor assignments are a precondition to contribution. As well as creating inequality, they get in the way of participation, as does any mandatory agreement that will require legal review. I contribute back to reduce my maintenance and refactoring burden — it’s not (only) philanthropy. It’s reasonable for a community to expect me to demonstrate competence and ownership before giving me commit rights. It’s much less reasonable to insist I have to assign ownership of my work to a “project owner.” That chills participation, by forcing me to effectively pay to participate, both for legal advice and with code.

6. Am I treated as a development peer?  When a company’s employees have privileged access to the code (or unearned commit rights) they rob potential collaborators of the confidence they have space to innovate. A sure sign is changes that are conducted in private, then “thrown over the wall” to the community. 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, license change or business move that turns the rights ratchet? All these moves are scornful of contributor equality. 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. Is the project 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, and for an OSPO to understand concerns with projects their developers would like to adopt beyond mere licensing issues. 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.