A draft scorecard for determining if a software project is open as bait for a business pivot or genuinely keeping your freedoms protected.

The seven signs a project is following the rights-ratchet route to riches and the framework for going beyond licensing can be augmented by some straightforward indicators of an issue. None of these alone is necessarily a cause for concern, but the more clicks, the more risks. Here’s a rough-and-ready first draft of a scorecard to check whether your software supplier considers you a community peer and will respect and protect your essential freedoms, or visualises you more like one of those pods in The Matrix. Just count the clicks; the more clicks, the higher the risk this is a rights-ratchet that will end up closed.

• Is the project hosted by a Foundation or a company?
  • A project hosted by a public benefit charity (such as Software Freedom Conservancy or the Apache Software Foundation) can be trusted with aggregated rights, even if gathering them sets a poor precedent. No click.
  • A project hosted by a tax-exempt trade association (such as the Linux Foundation or Eclipse) is likely to be safe in the same way (although see the CLA comments below). No click.
  • Watch for organisations that appear to be Foundations like these, but actually are for the benefit of a single entity. For example, the MariaDB Foundation is considered by many to be in this category. Click.
  • Projects which are not sheltered in a seperate organisation are unlikely to be safe stewards of aggregated rights. Click.
• Who owns the trademarks?
  • You have the right to do as you wish with the software, but you don’t have the liberty to pretend it is yours alone. To protect against this, most community-based open source projects control the trademarks that identify the essential identity of the project. The Apache Software Foundation, for example, has a well-developed and strongly patrolled trademark policy. Generally, a project in this condition gives no-one the right to trade on the name of the project, leaving all to leverage nominative fair uses of the trademark. No click.
  • When the trademark is controlled by just one company, that means they and they alone have the right to be identified with the software and its strengths. Any other community member attempting to trade on the name should expect to receive a cease and desist notice. Click.
  • When the trademark is woven into the software, there needs to be a build switch that lets it be easily changed. If this is absent, click.
• What is the scarcity the company is monetising?
  • Is it a use-case-specific addition (e.g. a specific connector to a proprietary database) or does it embody the whole commercial value of the project? If the latter, click.
  • Are direct competitors excluded, tolerated or accommodated? Two clicks, one click, no click.
• What is the project license?
  • Is it OSI Approved? If not, click.
  • Is it copyleft? If there’s a contributor agreement too, click.
  • Is it a plus-license? If there’s a contributor agreement too, click.
• Do community contributors need to sign any form of contributor agreement to get their patches/pull requests accepted? What does it say?
  • A CA that limits itself to having authors attest to the originality of their work and entitlement to contribute is no click.
  • CAs that assign rights equivalent to ownership (let’s call those CLAs) exempt a company from the project license. When a company is thus not bound by the same license terms as the community, that’s a big click, maybe two.
  • If the CA/CLA assigns rights to a Foundation, who has a vote in decisions such as relicensing or changing the project trademark? If all contributors have a vote, no click. If only corporate sponsors of the Foundation, perhaps acting through their delegated board member, have a vote, maybe click. (thanks to Aeva Black)
• How is the company funded? Are there investors with a track record of respecting open source?
  • VCs don’t invest in companies, they invest in exits. Are they the primary source of funding? Click.
  • Look at other investments these VCs have made before. Do they tend to pivot to closed? Click.
• Is the project realistically forkable?
  • Yes, all OSI-approved licenses give you a theoretical ability to fork. But a project with aggregated ownership, a copyleft license, the trademark smothered everywhere (see above) and held by a privileged party and forums that block “disruptive parties” may not actually be viable to fork to avoid toxicity. If that’s the case, click.
  • Do corporate agreements include “no forking” rules so that large participants are hamstrung? Click.
  • Is the documentation under an open license? It’s hard to fork if all the documentation is withdrawn. No open documentation license is a click.
  • Could we get the tool chain realistically working for us on our own systems? Does it require paid licenses? Does it require specific cloud infrastructure? Is there a project supplied virtual machine or container required? Yes to any is a click-per-yes. (Thanks to Jeff Luszcz).

Got more? Got changes? Please use the comments below or contact us via the About page. Ideally this will turn into a useful OSPO tool.