The problem we’re facing in the open source community is a mixup between, on one side, open source practices and norms, and on the other, open source licenses.

A thread. https://twitter.com/mjasay/status/1351719147927859204

It’s important to understand that not all software that sports an OSI approved license actually follows what the broader community has come to consider as open source norms.

Android, for example, despite being open source from a license perspective, isn’t the fruit of an open and collaborative effort. It’s built by a single vendor, in a closed environment, and dumped over the wall when it’s ready. Good luck contributing to it independently.

Similarly, other projects don’t have licenses that are certified by OSI, and yet follow norms and practices of own source projects. For example, software built by and for coops fall in that category. So do a lot of ethical source projects.

The vendor driven GPL (or even Apache) + CLA combo that companies like Elastic champion, and which then empowers vendors to turn their back on the community that enabled them, isn’t open source from a community norms perspective either.

However, it is (well—was—in Elastic’s case) open source from the perspective of its license.

Our disappointment and feeling of treason when such projects move away from an open source license is due to the fact that we entertain the confusion in our mind that a project that has an open source license must also follow open source norms, …

… and that because a project obeys the letter of the law, it must also obey its spirit.

In practice this isn’t always the case. Some projects obey the spirit of open source, but don’t necessarily have OSI compliant licenses. Some projects obey both. And others only have an open source license.

I’ve heard @beep and @adactio call open source projects that don’t abide by open source community norms but have an open source license “nominally open source.” I like that framing quite a bit.

Until we disentangle these issues, and stop blindly equating license status to being open source and labeling as open source projects which don’t embrace community norms, we’ll continue to get disappointed when such projects bait and switch.

If I was a consultant, I’d offer a useful four quadrant diagram to help frame this.

Wait a minute… I *am* a consultant.

So here we go:

Moving away from the simplistic framing of open source licensing only, helps us better understand and map the ecosystem.

It also gives us a better view into the different perspectives of the community—or should I say the communities?

For the compliance-minded, open source is all about the top quadrants. Does it have an OSI-certified license is the key question.

For a good chunk of the developer community, it’s all about norms and community (the two right quadrants). Projects that embrace those norms and practices feel open source regardless of their license, which is why many don’t see ethical source as foreign to open source.

And finally the two left quadrants still satisfy the VCs’ definition of open source (which is essentially perceived as a marketing strategy), regardless of what either the dev community, or the OSI communities think about it.

Ultimately, this framework helps us determine what really matters about open source, including from a corporate perspective. Clearly, embracing community norms is a central aspect, as it guarantees the good health of the project, and thus its sustainability and security.

Likewise, clear licensing is critical. Non ambiguous terms and common licenses is what makes it easy for corporations to adopt and comply to licenses.

OSI-certification only isn’t a good measure of this. As we’ve seen, OSI-compliant licenses (GPL/Apache) combined with an agressive CLA end up sowing more confusion than one of the PolyForm licenses would.

This should give us pause on one hand to account more systematically for good governance and respect of community norms, …

… and on the other hand, to extend the benefit of trustable licensing to projects which don’t meet the 4 freedoms or the OSD, but have all of the other characteristics of well governed open source projects.

We’d all win.