Beware of Poison in the Source

Bitwarden found itself caught in a spot of drama last week introducing non-free and non-open code into their desktop client. I don’t use Bitwarden myself, but in a similar vein I remember they launched their “Passwordless” project as open source while under non-open terms.

This event got me thinking more about an increasing trend I’m seeing where projects are advertised as open source, but actually rely on non-(free or open source) code to build/run/function for their advertised value. I mention advertised value since some open source projects are built to depend on or use proprietary code (think OpenRCT2 for instance which requires a copy of the original Roller Coaster Tycoon 2) but generally, if I see a web application advertised as open source, I expect to be able to build/run that using code licensed in a way which meets the OSD and therefore provides open use, open modification & open distribution as a whole. I’ve written before about the why I think the “open source” term is important here.

To demonstrate this trend, I’m going to present some examples of web projects I’ve come across that each advertise as “open source”, while depending on their own non-open proprietary licensed code, while also showing responses from authors when this has been raised to them.

Note: I am not a legal expert by any means, and it’s possible that I have misunderstood how these projects are set-up (and I’d be happy to amend the below if so) but generally each of the below have had a response from the author which has indicated that assumptions, or tests regarding the license/build structure are valid. Additionally, I have nothing specifically against authors being able to choose licensing options to protect their own efforts, my main concern is when this is done in a potentially misleading or opaque way.

Formbricks

Website - ⭐ 8.3K - ⚖️ Mixed AGPLv3 - 💸 OSSC

• Project includes certain directories/files under a proprietary enterprise license.
• Many files in the AGPL licensed source make use of the non-open ee package.

I queried this on Reddit here, with my impression of the response being that this is done for convenience and not felt to be an issue. Responses included:

[…] So the EE licensed code is packaged into the Docker image but only gets activated with a valid license. […] (ref)

[…] if someone would like to deploy Formbricks without the EE licensed code, that’s definitely possible, it just requires a bit more work on their side […] (ref)

😂 (ref))

Cal.com

Website - ⭐ 32K - ⚖️ Mixed AGPLv3 - 💸 OSSC, Seven Seven Six

• Project includes certain directories/files under a proprietary enterprise license.
• Many files in the AGPL licensed source make use of the non-open ee package.

This was queried by a GitHub user squatica. Responses included:

[…] we never thought about being able to completely remove the /ee folder. (ref)

The EE folder is not meant to be removed. The license specifies on not using code from it. This decision was also made to avoid spending resources on having to develop and maintain two separate codebases. So as far a you don’t actively use enterprise features you would still be honoring the license. (ref)

On a Reddit thread where I had mentioned the used of mixed open/proprietary code a co-founder stated:

[…] - we are partners and work very closely with opensource.org (OSI – the organisation that knows the most about licensing and has the best reputation). Not only do they approve our project as open source, they are also using Cal.com for their own scheduling. […] (ref)

So I guess it’s okay, they’ve got OSI approval. I hadn’t heard about the OSI bestowing validation to specific projects like that so I did reach out to the OSI regarding this but failed to get a direct response to this (although I haven’t chased it up since initial messages in April).

Papermark

Website - ⭐ 5.2K - ⚖️ Mixed AGPLv3 - 💸 None found

• Project includes certain directories/files under a proprietary enterprise license although this is completely unmentioned at the top level of the repository and top-level license file.
• Files in the AGPL licensed source make use of the non-open ee folder, although doesn’t go too deep, mainly to get feature limits.

I queried this on Reddit here where the author indicated that the non-open code was not needed, but did not follow up when I queried this again after attempting to build the project with the non-open code removed. Responses include:

[…] You are correct that we are providing a dual license product. However, instead of other projects that have a Pro Edition and Community Edition, we make all the source code available under different licenses. […] (ref)

[…] Correct, you can run the open-source application without the /ee/ folder. You can comply to our open-source license by deleting the /ee/ folder. […] (ref

Budibase

Website - ⭐ 22.5K - ⚖️ Mixed GPLv3 - 💸 SignalFire

• Project requires checking each “package” to get a full view of licenses used.
• The project includes a separate license for the “Structured Query Server” which it reports to be shipped with, which is very much not an open source license.
• Files in the GPLv3 licensed source make use of a “pro” package does appear to have its sources in the same repository (with the folder being an inaccessible submodule link) while appearing to be a package under a non-open license.

I queried this in a GitHub discussion here but received no official response, but other users did report issues attempting to build the project from source.

Tolgee

Website - ⭐ 1.8K - ⚖️ Mixed Apache 2.0 - 💸 Flying Founders

• Project includes certain directories/files under a proprietary enterprise license.
• Many files in the Apache licensed source make use of the non-open ee code.

I queried this use of setting arbitrary limits in the code on Reddit here. The author responded with the following in regards to a user’s suggestion of a fork:

Go for it. Just heads up: Remove all the ee code, before you do that. (ref)

When I queried the relied upon “ee” code in response to that, they stated:

Yeah, you would have to fix these issues. (ref)

Documenso

Website - ⭐ 8.3K - ⚖️ Mixed AGPLv3 - 💸 OSSC

• Project includes certain directories/files under a proprietary enterprise license although this is completely unmentioned at the top level of the repository and top-level license file.
• Files in the AGPL licensed source make use of the non-open ee package.

I queried this in a GitHub discussion here and am yet to receive a response but this was only opened a few days ago so they may have just not found the time to respond yet.

Why does this matter?

In most of these cases the companies encourage/allow free use of their software regardless of these mixed sources, so you may wonder why this matters. In my view, this matters for the following reasons:

• Users may be thinking they’re using/depending on open source software, since it’s advertised as such, without knowing they’re using/relying on code under more complex/limited terms that do not afford open rights of use, modification & distribution.
• The deeper this runs, the harder it could be for users to exercise their rights of open source to fork a project away to new leadership & authors.
• Users may not be aware that in many cases they’re technically agreeing to comply with additional terms and requirements.

Thoughts

I included the GitHub star count for these projects since many portray or use these as a sign of reputation and/or maturity, but I wanted to indicate that even highly-starred popular projects can have this kind of unclear licensing mix in play.

You’ll also note that many of these projects use and are distributed under the label of the AGPLv3, an often misrepresented & misunderstood license. This can bring into question the validity of mixing licensing terms in a lot of cases here, since section 7 of the AGPLv3 license allows removal of many additional terms:

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

This may mean that in many scenarios users could just ignore the extra “enterprise” license terms, making them redundant, but doing so may introduce legal questions & risk since it’s likely against the author’s wishes (and potential lack of understanding in regards to their own license).

Within this list I also included the main investors I could find from a quick search. From my experience, most licensing confusion I come across have some VC/financial backing, although I haven’t yet assessed if that’s just bias towards the communities I watch & see projects advertised within.

We do see OSS Capital as a common thread here. Again, this could be some selection/market bias but it’s potentially an indicator of shared strategy between projects, OSSC strategy for achieving “commercial open source”, or lax attitude to open source in general. Another thread is that all of these, apart from Budibase, are part of the “OSS friends”, an initiative by Formbricks to gain backlinks for SEO, which may indicate these patterns & ideas for licensing spread within communities as projects take notes from eachother.

Overall, it’s up to users to consider how important these licensing scenarios are to their usage, but unless you’re a licensing pedant like me it might be hard to know that such license mixes are at play in “open source” advertised software. I think in most of these cases it’s done due to not thinking it matters relative to the effort of properly organising/building/distributing an “open core”/mixed-license codebase but the negative impacts are not on the authors, but on the users, although it can go unnoticed to users until the time it matters.