POST: A case study in defending open source principles (without losing integrity)

Open source has a clear, community-defined and agreed-upon meaning based on a few set of core principles and a limited set of common licenses that follow tehse principles. Diluting it for convenience helps no one - neither the users, nor the developers of FOSS who all rely on clarity, a common understanding, and trust in established community norms.

I recently chatted in a public with a person that was announcing the release of their code as "open source" under a Commons Clause license attached to an Apache license https://scancode-licensedb.aboutcode.org/commons-clause.html

This may not be obvious at first, but it can be misleading and deceiving to mis-qualify a proprietary license as open source. And this is unfortunately not an isolated case, but instead an emerging trend that may be ruining open source licensing clarity, and bring back FOSS licensing at the forefront of software development issues.

The gist of their announce was like this:

---

**Happy Jock:**

> We’re excited to share that xxxxxx is now available as an open-source project.
> ....
> Releasing xxxxxx under an Apache 2.0 license plus Common Clause reflects our desire to foster open collaboration while preventing unauthorized monetization.

---

My observations are that:

- Jock’s common mistake is to conflate proprietary "source available" licensing (Commons Clause + Apache 2.0) with OSI-compliant open source terms. The Commons Clause adds restrictions that violate core OSI principles (notably freedom of use in any field).

- The conversation below that followed is symptomatic of a wider issue when individuals and companies attempt to redefine community definition of terms like "open source" to suit their commercial or PR needs, clashing with the well-established norms backed by institutions (OSI, FSF, FSFE, Apache, Eclipse, OWASP, etc.).

**My take: they want to have the cake and eat it too, hijacking open source goodwill without giving anything away.**

Here is a transcript of the chat triggered by that post, anonymized and lightly edited for brevity and clarity:

---

**Ally:**

> @jock The Apache 2.0 license with the Commons Clause is **not** an open source license. Most people categorize this type of license as *Source Available*. AGPL 3.0 **is** an open source license.

---

**Arrogant Jock:**

> @ally That’s fine. People can nitpick all they want. But those people have probably also never tried to build a sustainable business. 😉

---

**Me (annoyed):**

> @jock Claiming the Commons Clause is open source is blatant, naive, uneducated "open washing".
> Telling you this is not nitpicking, but correcting you when you are wrong.
> I welcome the creation of businesses, but do not try to pretend your thing is open source with dubious, incorrect claims.
> @apache This proprietary license has been out there since 2018. Do not even think about using it with or for an ASF or OWASP project. This is a poison pill for users.

---

**Jock (Looking Down On Small People):**

> @me Cool story. But nobody except for a very small vocal part of the community cares.

---

**Me:**

> @jock You seem to be very unaware of the "small community" of open source organizations like Eclipse, Linux Foundation, OWASP, and Apache to name a few - and a few small companies like Google and IBM, and pretty much every single open source-aware business that consider the Commons Clause a toxic license not to be touched with a 10-foot pole.
> Unless you are trolling.
> Oh, and I forgot: XXXXX and YYYYYYYY too - make these two also part of the "very small vocal part of the community that cares."
> Or unless you understand nothing about open source, open source licensing, and the legal side of licensing. That's OK then: if you need help, someone working in any of these "very small vocal organizations" and "very small businesses" may volunteer to enlighten you. I can provide introductions if you like.

---

**Dismissive Jock:**

> @me You do you.
> All Commons Clause does is protect against others monetizing a product as a service. You can call that toxic if you want. I call it learning from the past (Redis et al).

---

**Me:**

> @jock …which makes this a proprietary license.
> I am sorry for you that you seem to understand so little about open source licensing. This lack of understanding is scary and worrying, as SBOMs are also about conveying licensing.
> With all this said, I am thankful to you for using some of my code and standards in your commercial products. This is something you can enjoy, because I am part of that "small vocal part of the community \[that] cares" - which is also pretty much everybody in this channel and at OWASP - and who makes their code available under a bona fide open source license, for your benefit.
> I am sure everyone can appreciate the irony of this discussion 🙂.

---

**Aggressive Jock:**

> @me You do you. The only winner of these debates are proprietary, closed source, software.

---

**Me (trying to take the high road):**

> @jock So I guess XXXXXX being proprietary, you would win in that definition?
> But this is not a debate, but a statement of community-agreed upon, common understanding that all lawyers aware of open source understand and agree with (including Heather, who wrote the Commons Clause and that I know - you should contact her for education, and I can make the intro if you like).
> Again and for the record: there is nothing wrong about commercial and proprietary licenses.
> What is incorrect is to pretend that a commercial and proprietary license is open source, as this is a source of endless confusion.
> And I assume you mean well by default and are not trying to hijack the goodwill of the open source community, and are just lacking experience in the field.
> I will stop it there. There is not much more for me to say than: you should read, consult experts like the lawyer who wrote the Commons Clause.
> In the end, you are likely doing yourself and the community a great disservice by incorrectly claiming XXXXXXXX is open source.
> And again, thank you for using my open source code in your products.

---

**Open Source Ally:**

> @jock FWIW I'm entirely with @me here.
> I can only speak from my own experience, and there the discussion with paying customers is an entirely different one between an open source license and a non-open source one like the one you chose.
> A simple clarification would have ended the whole debate. Instead we get dismissive comments about vocal minorities and doubling down…

---

**Another Ally:**

> @jock Since both the Apache 2.0 and Commons Clause licenses must be accepted, the effective permissions do not meet the definition of open source as defined by OSI.
> Specifically, clause 6 (No Discrimination Against Fields of Endeavor), which reads:
>
> > The license must not restrict anyone from making use of the program in a specific field of endeavor.
> > For example, it may not restrict the program from being used in a business, or from being used for genetic research.
> > The acceptance of both licenses makes the project “source available,” not open source.
> > There are ways to leverage Commons Clause - which I personally like - in a way that allows the community code to remain open source and the proprietary code to be source available. But the project needs to be architected in a way that makes this delineation clear.

---

**Annoyed Jock, retreating:**

> @another-ally Thanks, yep, this is 100% accurate. Technically speaking as per OSI’s definition, this is “source available.”

---

**Confused Bystander:**

> OK, I REALLY hate doing this as I imagine this will just be throwing gasoline on a fire, but I am seriously asking:
> If @another-ally is correct (and @another-ally is *always* correct! 😁)
> Then why is Apache 2.0 listed on the OSI approved site?
> I was trying to figure out what were “open source” licenses when I ran across this.

---

**License Savvy Observer:**

> @confused The problem isn't Apache 2.0 - it's Apache 2.0 **AND** Commons Clause together, right?

---

**Jock, Trying To Muddy the Water:**

> Hi everyone,
> I’d like to take a moment to clear the air following our recent discussion. I had a conversation with @me, and I want to clarify my earlier point.
> My message was never meant to suggest that licensing isn’t important - it absolutely is.
> What I was trying to highlight is that the OSI’s definition of “open source” might differ from how many people commonly use the term.
> Technically, it may not be accurate to label something as open source if it doesn’t meet OSI’s criteria. However, much like how people often use “Band-Aid” to refer to any adhesive bandage or “Jacuzzi” to describe any hot tub, the term “open source” is sometimes used more loosely in everyday conversation.
> I appreciate everyone’s input on this topic and hope this clarification helps.

---

**Me:**

> @jock It has been a major win that when we talk about open source, we know what this means and there are no technicalities about this.
> How people commonly use the term is 99.99% of the time referring to the community-agreed upon meaning of open source.
> Diluting that is not helping anyone, unless one wants to ride the coattails of open source without actually being open source.
> I am not sure your understanding of open source has progressed much over the last few days. 🤔

---

This exchange highlights why defending the integrity of "open source" matters. I believe that clarity here is not pedantry, but it is about protecting devs from legal traps. Proprietary licenses like the Commons Clause violate the principles that make open source licensing so simple: well-known terms, community norms, and established practices that we can trust. Calling source-available software “open source” hijacks the term and misleads the communities.

We must continue to stand up for the OSI definition and the Free Software Foundation freedoms, not just for legal precision, not even to preserve the values that sustain an ecosystem of code sharing that made the internet what it is today and is still powering it, but simply to keep legalese from creeping back in software engineering with the proliferation of confusing and often deceiving proprietary "fauxpen" source licensing terms.

In that sense, commercial licenses are much better than proprietary, source-available licenses as they do not try to masquerade as open source.