Hey all,
So I am continuing this OSS License conversation from another thread and will continue the conversation about this in another topic.
To point out why this is not the case and give us a simple mental model of these licenses, let me define my simple taxonomy of open source software licenses:
- Permissive licenses
- Copyleft licenses
- Open-washing licenses.
My background with OSS licensing..if you wanna know
I was a developer advocate for an open source big data query engine that had a large split in the community creating a lot of confusion for the users. I needed to clarify my own understanding of the politics of licenses outside of just the legal aspects of copying, using, and modifying the code, to arm the community against some profit-focused actors who exploited the situation. There are a LOT of complex human power dynamics at play that are generally things that users, consumers, and even developers don’t want to know but truly empower themselves by learning the basics.
Disclaimer: 
I’m not a lawyer™ none of this legal advice…in fact it’s mostly just plain and simple vibes which tend to influence human behavior and how people choose what to buy .
Permissive License Vibes
An author just writing software and showing it to the world. Anyone can copy the code and reference it, or don’t…whatever, as long as you don’t sue the author for any time, damage, and money loss this causes you for using this free code provided, it’s all cool.
For higher aspiring projects, there is also a community building vibe
Everything said previously, but with intent to build a community that shares the code based on trust. Ideally the work of individuals and companies who are incentivized to contribute to shift maintenance to the community who want the features share the same code. This license keeps a tribal pressure on the leadership of this community to act well among the community and always give them the opportunity to fork the code and can legally copy the previous code if there’s ever contention. If the authors or company with the power ever make a move that removes power from the community that they didn’t consent to, the community will fork.
These licenses would always be the case in an ideal world.
Examples of Permissive Licenses
Copyleft License Vibes
The authors of this code worked really hard on the code. The work is complicated, always evolving, and/or very early and not complete yet. It’s fastest to iterate in the core group as vetting and training new community members is a heavy lift. The authors value transparency, authenticity, and community so making the source available, enabling modification and contributions, community testing and auditing, and allowing you to run your own version is fine. However, they need to limit or control the the means of commercial distribution of the product, to ensure the core engineers of this code are paid for their work, and the paid + enterprise product meets the quality bar of the original authors.
Unfortunately, this means the community has less leverage if the authors do something unplanned and outside of what the community signed on for. This has value, but requires more trust that the authors won’t just use this license to stonewall public contributions and simply use this as a sales pipeline rather than a community to share ideas as we’ll discuss in the next bucket of licensing.
Aside
If authors are explicit and upfront with community expectations or clarify that people shouldn’t waste their time contributing, this is also fine, but likely won’t build a large community as there’s not much additional value provided to the community beyond the source being available. This has worked in some instances though, especially where most of the user base is unable to contribute code.
Examples of Copyleft Licenses
Open Washing License Vibes
This is a licensing category I just made up from the term openwashing. This sets up a license structure that uses similar language of copyleft licenses that aim to equivocate their license with an open code commons with bidirectional power and information. However, these licenses are legalese that provide unilateral power over code sharing which is limited by the profit-driven whims of the company leadership and shareholders. This technically is a source-available license, just not standardized, hard to interpret, and often provides unidirectional value creation from the community. It is source-available with proprietary vibes.
Examples:
The point?
So what do these “vibes” mean for users? Sounds like only folks with the code need to be concerned.
Well, this is where the governance politics and leverage come in. True power can be seen in git commit logs with who gets the most code submitted, who approves that code, who can effectively block the code, how open is the group to new contributors or contributions, and where are all the folks who contribute working for or what other motivations might they have? This is done simply by looking at the logs and having discussions with folks in the community like you would as someone who works in a new job learning how things run.
Do you do all this work by yourself? Hell no! This is why we’re on a privacy community to build consensus through open journalistic techniques to investigate findings. Open source projects are transparent but this stuff takes time, similar to building good privacy practices that is done on this forum/site.
Licensing tends to be the first layer heuristic in understanding where a project might stand in all of these governance specifics. The next layer is tapping into the community, learning the politics, and then making an informed decision on what you adopt based on verifiable sources. As a community gets better at learning fact from fiction, the profit-driven actors are required to move with the community rather than their highest paying customers who ironically would end up wanting the innovative solution the community reaches through consensus.
If all this sounds rhetorical, here’s a real life story where this happened in a community I was involved in.
Personal anecdote where this influenced a $2+ billion buyout
I was in a format war that was won despite both technologies Delta Lake (spec) and Apache Iceberg (spec) both having the Apache v2.0 license, open libraries, and feature parity, if you compare the number of pull requests by company you quickly see that the majority was done by the company behind the project, Databricks had strong control over the project.
Big tech among other large Fortune 100 businesses caught onto this and used Iceberg, but and this led to the realization that if you use Iceberg, you won’t get locked into storing all your data with one company. Competing businesses started to adopt Iceberg, until ultimately Databricks purchased the startup created by the founders. This buyout was a huge win for users as this now pushes all vendors to use the same open format.
So, the lesson here is, don’t underestimate the power and leverage of proper licensing, and well-informed communities.
Open source is a pluralistic movement and evolves much like language. Every community is different and even my take up here won’t apply in every case. So just remember it’s all about vibes and storytelling and understanding how to be the best agent you can be as a consumer which shapes the economy around a project.
For more informed legal conversations from actual OSS lawyers
You can always read through the Software Freedom Conservancy which comprises of a bunch of lawyers upholding the theoretical laws and why adding these licenses actually curb human behavior.
In that instance, a lot of people trusted the BDFL maintainers as they had the clearest and most inclusive vision for the community despite all three of them working for the same venture capital funded company I worked for.