Improving Transparency: Clarifying Licenses & Commercial Features

[bannert1337]

Hi everyone,

First off, I want to say thank you to the maintainers and contributors of the Proxmox VE Helper-Scripts project. I, like many others, find these scripts incredibly valuable for quickly and easily setting up various services on Proxmox VE. They significantly simplify the management of our servers and are a real asset to the Proxmox community.

That being said, I wanted to raise a point for discussion regarding the transparency of the project, specifically in relation to the licensing and commercial aspects of some of the applications these scripts help deploy. While the Helper-Scripts repository itself is open-source, and that's fantastic, some of the integrated applications have more complex licensing models and/or include features locked behind paywalls.

This isn't necessarily a criticism of using these applications – they can be excellent choices – but rather a call for greater clarity and transparency within the Helper-Scripts project about their licensing and commercial aspects. Users relying on these scripts, especially in production environments, need to be fully informed to make responsible and compliant choices.

To illustrate my point, I wanted to bring up a few examples I've noticed:

• Checkmk: The script for Checkmk is very helpful, but while Checkmk is licensed under GPL-2.0, it's important to acknowledge that significant features are part of their enterprise offering and require a paid license. Users might inadvertently assume the script deploys a fully "free" solution without realizing the feature limitations in the open-source version.

• Komodo & MongoDB: The Komodo script recommends MongoDB as a database option. While Komodo itself is under GPL-3.0, MongoDB has a more complex license (SSPL or MongoDB Community Server license) and is often perceived as proprietary. This potential licensing difference and the shift away from fully open-source databases like PostgreSQL might not be immediately clear to users following the script's recommendations.

• Graylog: The project website describes Graylog as open-source and links to the Graylog company website. While Graylog does have an open-source core (graylog2-server), the company also offers commercial extensions and services. It would be great to clarify which version of Graylog is being deployed by the script and explicitly mention any potential commercial aspects or feature limitations depending on the chosen setup. (I haven't verified the exact version deployed, but raising the point for clarity.)

My suggestion isn't to remove these scripts, but rather to enhance the project's transparency by:

• Adding a "License and Usage" section to the documentation (and potentially within the script output itself) for each relevant script.
  This section could briefly outline:
  • The license of the deployed application.
  • If there are commercial versions or feature paywalls.
  • Links to the official licensing information for the application.
  • If applicable, which specific version (open-source or community) is being deployed.
• Considering explicitly noting in the script descriptions on the website if an application has commercial aspects or isn't purely open-source in all its features.
• Potentially exploring if there are fully open-source alternatives for some services where commercial aspects are a significant concern, and offering those as options where feasible.

Increased transparency in these areas would make the Proxmox VE Helper-Scripts even more valuable and trustworthy for the community. It would empower users to make fully informed decisions about the services they deploy and ensure they are aware of any potential licensing implications or commercial constraints.

I'd love to hear your thoughts and ideas on how we can improve transparency in this project. Let's discuss constructively how to make this excellent resource even better!

Thanks for your time and contributions!

[ssddanbrown]

Users relying on these scripts, especially in production environments, need to be fully informed to make responsible and compliant choices.

The tricky part is that it will have to be very well maintained otherwise you can easily risk users being further misinformed.
That would require a lot of effort, especially as many of these things can be in gray areas and need specific inspection and interpretation to be able to understand and inform users well.
Overall you'd be putting that effort in, and moving responsibility to this project, instead of users being self-responsible for their own compliant choices.

I respect the desire for something like this though, as transparency & licensing can be real muddy.
For context, I have a project where I inform and document in cases of misrepresented licensing (or misadvertising of being open source) and in many cases it can demand a significant amount of time to properly understand & interpret scenarios.

[bannert1337]

Great project! I really advocate for FOSS and the values it stands for. But I see the term "open-source" being used more and more as a (pure) marketing term, because of the trust and reputation it is generally associated with.

In general, I would follow the statements and decisions of the Open Source Initiative, as they are an independent entity and have been trustworthy for a long time.

[tremor021]

@bannert1337 "Users relying on these scripts, especially in production environments, need to be fully informed to make responsible and compliant choices."

Hi, thanks for your feedback. Just a small clarification here. Nowhere do we state any of our scripts are for production use. If you look at our homepage, it clearly states that its for homelab users:

We do not recommend any of our scripts to be used in production environment, we cannot provide 24/7 support as this is a community driven project. Our intent is to help homelab users to get their apps up and running as fast as possible.

Edit: typos