Remove netdata from projects list (became partially closed source)
Opened this issue · 27 comments
For your consideration, the netdata tool and all of its builds (there is no separate FOSS-only build) now include a new dashboard (served by default, and worse, by a cdn by default instead of locally) that is only built in private and exists merely as built blobs:
https://github.com/netdata/netdata/tree/master/src/web/gui/v2
which also locks newer, desirable features (like systemd log shipping) behind an account.
Given that this makes netdata at minimum partially closed source it should not meet the FLOSS inclusion criteria for this badge.
The "projects" list for project 2231 is here: https://www.bestpractices.dev/en/projects/2231
That refers to this repo URL:
https://github.com/netdata/netdata
That is unambiguously GPL-3.0 https://github.com/netdata/netdata/blob/master/LICENSE which is OSS.
They may separately release closed-source builds, but the source code for that specific repo seems to be unambiguously open source software. A lot of projects don't release builds at all.
Please reopen. You missed their closed blobs and license at
License https://github.com/netdata/netdata/blob/master/src/web/gui/v2/LICENSE.md
Blobs https://github.com/netdata/netdata/tree/master/src/web/gui/v2
Which are closed blobs, from a separate repo, not source accessible, licensed non-floss and dumped into their github repo and used in all builds and referenced from the rest of their code.
There is, as far as i am aware since debian has not updated it either, no way to build without them.
For Reference:
(Debian is on a pre-blob version and has not updated it for this reason)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145
Thanks for the additional information!
For the badge, things appear to have changed in the project, in a subtle way that isn't obvious from a simple "look at the LICENSE file" review. We now need to see if the project continues to meet the criteria.
The badge does allow some actions that Debian would not allow. For example, we allow projects to write OSS for MacOS or Windows (e.g., "gcc on Windows"). We also discourage (but allow) the use of non-OSS build tools, as shown here:
The project SHOULD be buildable using only FLOSS tools. {N/A allowed} [build_floss_tools]
However, we do require build-ability:
If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code. {N/A allowed} [build]
Believe it or not, I don't think we've ever discussed "binary blobs" in the badge project. So I propose these steps:
- Ask the project to explain the current state (I'll send an email requesting that).
- Bring this issue to the badge project mailing list to get wider perspectives. The badge TAC will then need to make a decision.
Thank you for your information!
Believe it or not, I don't think we've ever discussed "binary blobs" in the badge project. So I propose these steps:
1. Ask the project to explain the current state (I'll send an email requesting that). 2. Bring this issue to the badge project mailing list to get wider perspectives. The badge TAC will then need to make a decision.
Thank you very much!
I'd request to look through 2 cases specifically for 2 (but more are always welcome!):
- blobs that provided by other projects and that are present and used for function (like device firmware from vendors with no source access)
and, as in this case - build output of closed source and inaccessible projects from the same creator, like web uis that ran through a build tool (like webpack/vite and possibly an obfuscator) that come from private repos.
Edit:
And maybe a project can earn the badge if they offer a FLOSS build-time option for example, so that those get excluded in a -foss (or maybe mandatorily the default) release? (And with checks in place that that process actually works?)
Otherwise you could simply make a project with a completely closed source ui, yet still earn this badge.
(Which would very much not be what i'd understand the spirit of this badge to be)
Dear OpenSSF and Community,
I am Costa Tsaousis, the founder of Netdata, and I would like to address the concerns regarding the inclusion of Netdata in the OpenSSF Best Practices project list.
Netdata and Its Open-Source Commitment
Netdata is committed to providing high-quality open-source software. The core of our platform, the Netdata agent, is a comprehensive observability tool that includes data collection, a high-performance time-series database (dbengine), machine learning for anomaly detection, alerting, logs management, and many more.
All of this is available under the GPLv3+ license in our Netdata GitHub repository.
Addressing the Concerns
The issue raised seems to stem from a misunderstanding about the relationship between the open-source components of Netdata and our additional services. Specifically the Netdata UI.
The Netdata UI, a component included in our open-source repository, is distributed as a binary blob. This blob is built privately, and while the source code for this particular UI is not available, we created a specific license that allows its distribution alongside the open-source Netdata agent. This ensures that the UI can be used with the open-source agent without compromising the GPLv3+ license of the agent itself.
Keep in mind that currently two older, open-source versions of the UI are included in the repo, allowing the agent to be used without the closed source component.
On the Expectation of a Fully Open-Source Observability Solution
It appears that there may be an expectation that for software to be considered open-source, all components, including any supplementary components or services, must also be fully open-source. However, this is not a requirement for compliance with OpenSSF Best Practices, nor is it a standard expectation in the open-source community.
Our approach is to provide a powerful, open-source observability platform through the Netdata agent. We have chosen to offer additional non-open-source components (such as the Netdata UI binary blob) under a license that allows them to be used with our open-source software. This does not diminish the open-source nature of the Netdata agent itself.
Commitment to OpenSSF Best Practices
We believe that Netdata fully complies with the OpenSSF Best Practices. The core agent is entirely open-source, and we are transparent about the inclusion of the binary UI component, which does not affect the open-source license of the agent. We understand that this may raise questions, and we are open to discussing any concerns further to ensure full transparency and alignment with best practices.
The Netdata UI, a component included in our open-source repository, is distributed as a binary blob. This blob is built privately, and while the source code for this particular UI is not available, we created a specific license that allows its distribution alongside the open-source Netdata agent. This ensures that the UI can be used with the open-source agent without compromising the GPLv3+ license of the agent itself.
You could have shortened this to "Yes, we have switched to a partially closed source model."
Keep in mind that currently two older, open-source versions of the UI are included in the repo, allowing the agent to be used without the closed source component.
Which makes your default solution not open source.
Mind you there is no indication that you are about to load a closed source dashboard when visiting a default netdata instance or default build, and distros had to patch out your blobs - as you might've noticed happening. Opensuse and alpine already did, Debian has an open bug about this and is aware since this was shipped. Rhel/Fedora/Epel are also on track to patch.
Noone was aware of this outside debian. Even in this very ticket it is evident that you plaster "open source" so widely all over your github page that it takes a second look to see the lockdown happening.
Trying to pretend this was a helpful move for the open source community (its not, BEING open source is!), and not a hidden way to still be published despite being closed source and just having gotten away with it so long is just plain wrong, and any intent you point to dissolves when you look at every single major distro out there patching out what is clearly not wanted.
nor is it a standard expectation in the open-source community.
Your response shows an almost malicious intent to keep profiting off the open source community while closing down the actual business end.
Having notified openSUSE their "no binary blob" rule was applied, and the v2 Dashboard - mind you, a version you would prefer all users to use and that gets all current features, with v0/v1 basically being locked as legacy track - has been patched out. Other distros are currently applying the actual Expectation as well.
Our approach is to provide a powerful, open-source observability platform through the Netdata agent. We have chosen to offer additional non-open-source components (such as the Netdata UI binary blob) under a license that allows them to be used with our open-source software. This does not diminish the open-source nature of the Netdata agent itself.
Until my recent request this was hidden at the end of your Readme. Users definitely did not expect the UI to be closed down on your project. If your project was split into "agent" and "ui" - maybe, but as it stands you're trying to write "open source" all over - Your github project slogan is "The open-source observability platform everyone needs! " - and this is, in all default builds and your default deployments and even the default build, not true (anymore).
I would applaud you for openly becoming "The partially open source solution" instead.
The core agent is entirely open-source,
And the main ui to use it with as per default build, is not
and we are transparent about the inclusion of the binary UI component
As of my pull request a few days ago, and you still openly try to give off the (wrong) look that you are fully open source.
Hiding it down in your Readme is misleading, at best.
which does not affect the open-source license of the agent.
Then split it and the cloud ui into separate projects. Make it clear that the open (and locked away from new features) end user ui is v1 and let users separately sideload cloud ui from a custom repo, or upon explicit enablement.
As it stands your project is partially closed source in the worst, hidden way. And all the points made - marketing talk.
For Reference how much the open source community:
- actually saw this happening
- wants this
Opensuse Bug report: PATCHED after being notified
https://bugzilla.opensuse.org/show_bug.cgi?id=1229119
Alpine Linux: PATCHED after being notified
https://gitlab.alpinelinux.org/alpine/aports/-/issues/16367
Nix: Split by themselves, packaged Netdata Cloud separately
https://github.com/NixOS/nixpkgs/blob/c3aa7b8938b17aebd2deecf7be0636000d62a2b9/pkgs/tools/system/netdata/default.nix#L113
Debian: still has not updated and you're being a headache to the maintainer
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145
More to come, likely.
So no - the "Community" doesnt expect, or want, v2 and you've not done us a favour with it.
Nix is probably closest in a solution to this conundrum: Split the project. Keep netdata-agent open source, with a single node open v1 ui that we all benefit from and can contribute to, and clearly separate, and ship, v2 on your own Effort, or lock it into Netdata Cloud, as you've done with most recent developments.
Then you'd at least partially meet the spirit of being an open source citizen that collaborates on best practices, instead of the slow lockdown you're currently on.
And no, as long as v2 files are in the repo and the default build (or it being sideloaded from the web) i personally would not consider you open source anymore, and thus not eligible for open source awards.
Note: Pretending that "Netdata" as project is "the agent" and the "UI" is seen as separate by the Community - neither you, nor your repo, nor your other communication is like this anywhere else. This is, at best, dishonest.
And to add more proof: Not even your users knew, and stumbled upon it trying to make privacy-respecting local-only deployments happen. netdata/netdata#15466 (comment)
And this is not without precedent, feel free to check how many distros still package mongodb, and whats happening with redis.
Until my recent request this was hidden at the end of your Readme.
It seems the claim that the license information is hidden is based solely on a cursory glance at the badges, without a thorough examination of the readily available information provided in the README. Both the Is Netdata open-srouce? and License sections clearly state that dashboard v2 is licensed under the NCUL 1.0 license. Additionally, these sections provide a link for further information.
It seems the claim that the license information is hidden is based solely on a cursory glance at the badges
The title of your project is:
"The open-source observability platform everyone needs!" which is also the title bar
Note: for most users aka the reasonable understanding this has meant "netdata, and the ui you interact with". As you can see in the linked other bug report.
The badges, which only list GPL3 (until now) and you'll need to scroll the entire Readme for a not very visible paragraph.
Not only is this sidelining the problem that you are shipping closed source code as of right now - the proof that this was and is insufficient is that
-
netdata-agent with v1 is not standalone with v2 as a separate repo that users must separately install (which would make this immediately okay!)
-
multiple major distros trusted those exact labels, and started shipping v2 assuming your badge and repo comment claims were true.
-
once again, even in this thread its evident your visible labelling does not match what you provide in the repo. Where is the spdx license identifier for your blobs? The top level sublicense? You should be aware that if you'd have labelled this correctly no distro should have ever picked it up. At which point we're back to the start - v2 should be in its own repo, and clearly labelled as what it is.
All you need to do to make the entire open source community okay with this is to remove v2 blobs from the repo and default builds, because as of right now both of them do not meet the standards of open source software.
Or if you werent going down the lockdown route, collaborate on a open source v2. 😃
Label what is not open as explicitely so, and dont try to sneak in the blobs into the main repo. Again, look at all Distros taken by this by surprise - arguing anything else is in bad faith.
The badges, which only list GPL3 (until now) and you'll need to scroll the entire Readme for a not very visible paragraph.
Absolutely, giving the README a good read (or even a quick scroll) is a wise move before forming conclusions. I was simply responding to the comment about "hidden information."
You're right about the missing dashboard v2 license badge. There was no hidden agenda. The good news is it was fixed as soon as it was reported.
You're right about the missing dashboard v2 license badge. There was no hidden agenda. The good news is it was fixed as soon as it was reported.
Then i have some more requests for fixes:
Will netdata, as project, consider to make netdata v1-only again on the repo, since most distros will be only shipping that anyway, and commit to continued support (not even feature support (even if appreciated), just updates for bugs and fixes) for it then? Or make v0/1 only the default build?
Will netdata, as project, state on docker hub that https://hub.docker.com/r/netdata/netdata is actually "open source observability + closed source dashboard"? Because there too nothing indicates the shipping, and autoloading, of closed source v2. (Or default ship only v1 there too). This miscommunication is pretty much everywhere where netdata is, as of now, and does not make users aware of the orientation netdata is headed towards.
And as much as i would love to trust you on this, this "open source" claim is so pervasive on every public instance of netdata, yet not true in all default builds of yours (and until a few days ago, even most distros. A good open source collaborator might have approached them ahead of time - at which point v2 would have never needed to be in the repos since it would not get shipped anyways). And in no way should it be marketed as fully open when it is not.
And no, no one on docker hub assumes that "open source observability platform netdata" means the agent only.
Nor do you provide an "-oss" build, or (even better) a "-cloud" build with the expectation met.
That is what the entire thing boils down to - the cloud dashboard should be your own responsiblity to ship and maintain, while you and v1 get to enjoy continued collaboration with the open source community.
Oh and: you were already on a plan to "oops, not compatible" v1:
netdata/netdata#17240 (comment)
And just ship cloud-nag v2 instead to open users.
The more i look at this the worse it looks.
And you are as a project aware, and idle, to this entire problem netdata/netdata#16035 since then.
Which makes netdata agent a neat data collection without a open source ui to view said data once that plan comes through, and you'll not even ship the fallback v1. Which CANNOT possibly fall under open source, with the current project structure. (And even now it is questionable)
Yet you want open source best practices badges?
Thank you for your continued engagement on this matter. I’d like to address your concerns directly.
Clarifying Open-Source and GPL v3+ Compliance
First and foremost, Netdata fully complies with the GPL v3+ license. This license is widely recognized as a standard for open-source software, and compliance with it is the foundational requirement for any software to be considered open-source. The GPL v3+ ensures that the source code for the Netdata agent is freely available, and users are granted the rights to use, modify, and distribute it.
The concept of open-source is centered around the provision of intellectual property to the public, allowing for free access and modification. It does not, however, mandate that every aspect of a project (such as supplementary components or features) be fully open-source, especially when those components are offered under a separate, compatible license.
Compliance with OpenSSF Best Practices
The OpenSSF Best Practices badge is awarded to projects that adhere to a set of guidelines for maintaining and developing high-quality open-source software. Netdata is committed to following these best practices, and we believe our project fully aligns with the standards set by OpenSSF.
It’s important to note that OpenSSF Best Practices focus on code quality, security, and sustainability, rather than prescribing that all components must be open-source. The binary distribution model we employ, which includes both open-source and closed-source components, does not contradict these best practices.
Distribution Policies and Open-Source Nature
Regarding the distribution policies of various Linux distributions: these policies are distinct from the principles of open-source software. Distributions may choose to package or exclude certain components based on their specific guidelines, but this is separate from the licensing and openness of the software itself.
The fact that different distributions can, and do, modify or exclude certain components based on their own policies further demonstrates the open-source nature of the Netdata agent. It’s this very flexibility - allowing distributions to adapt the software as they see fit - that is a hallmark of open-source software.
Balancing Open and Closed Source for Sustainability
We understand that there is often concern in the open-source community about projects introducing closed-source elements. However, sustaining the growth and development of open-source projects requires funding, especially when the project is as ambitious as Netdata. Our approach involves balancing open and closed-source components to ensure that we can continue to develop and offer high-quality software, while generating revenue from users who derive significant value from it.
In closing, I want to reiterate that Netdata is committed to transparency and adherence to open-source principles. We value the input from the community and remain open to dialogue about how we can continue to improve and align with the expectations of our users.
Thank you for your feedback.
Before going through each of the marketing talk points:
One of the requirements for the badge is
The software produced by the project MUST be released as FLOSS
The NCUL release of the v2 dashboard and the "no reversing" is not FLOSS.
This is the License i must accept to use your software in a supported way.
Your release is not eligible for the badge, by the very requirements of it - anything else is wishful thinking.
Now, to the marketing points:
First and foremost, Netdata fully complies with the GPL v3+ license.
I recognize that the agent is. Point is you're talking around the bush: your project is not open source as built or in that repo today. Split v2 out then, and force everyone to Netdata Cloud then and let the agent remain open.
The concept of open-source is centered around the provision of intellectual property to the public, allowing for free access and modification. It does not, however
Now you are trying to redefine what FLOSS Software is to an open source Enthusiast. Thanks.
Can i view the v2 Dashboard Code, which i am supposed to use for viewing your produced data?
Can i reverse engineer it (ideally not needed, with code access)?
Can i make it work better for me, and submit the ideas back?
No, No and No. You are not open source.
Why do you keep lying about this? It is clear as day that Netdata in its form now is not open source in its release.
The OpenSSF Best Practices badge is awarded to projects that adhere to a set of guidelines for maintaining and developing high-quality open-source software.
Which netdata v2 ui is not anymore, yet is basically required to use netdata however (Using it through Netdata Cloud is still the same closed code).
Netdata is committed to following these best practices, and we believe our project fully aligns with the standards set by OpenSSF.
You are, as of today, shipping only v2 as supported option to view the data by your project, which is closed source.
You are violating the main point of the openssf requirements.
And you also thought about deprecating v0/1 as well.
It’s important to note that OpenSSF Best Practices focus on code quality, security, and sustainability, rather than prescribing that all components must be open-source.
Then the badge would be a sham, from my view, and i will communicate this further.
If you can be a best practices badged open source project that just sideloads the entire ui and cloud nag from a cdn or ships it outright - then this badge would not deserve its name, or weight.
But that is not for me to decide, only for the badge project.
The binary distribution model we employ, which includes both open-source and closed-source components, does not contradict these best practices.
You are, once again, not open source usable anymore with your own tools (in a way that is supported).
That can hardly be best open source practices.
It sickens me seeing a once great project fall into this cycle, and wanting to maintain the looks of being an open source citizen. All while insisting that you are totally open source (you are not, by the definition of it and the gplv3 you point to in your release!). And you cycling the same (wrong) point makes it no better.
Regarding the distribution policies of various Linux distributions: these policies are distinct from the principles of open-source software. Distributions may choose to package or exclude certain components based on their specific guidelines, but this is separate from the licensing and openness of the software itself.
Their Packaging Guideline is "is this open source". Which your repo with the v2 dashboard, is not.
Neither is your docker hub image, which ALWAYS ships & defaults to v2, yet you still prominently market yourself as open source platform there.
that is a hallmark of open-source software.
Which you have been freeloading off of, and silently changed this in a way that was maximum plausible deniability.
And the hallmark of open source software is collaboration and being open source. You point to the GPL3 a lot, i'd suggest to take its spirit to heart.
We understand that there is often concern in the open-source community about projects introducing closed-source elements. However, sustaining the growth and development of open-source projects requires funding
Exactly, you want to continue stating that you are open source and follow open source practices, while you are starting a process often called "enshittification" - first v2 is the only supported dashboard, then you needed an account for new features so you know who to contact for a business license.
If you want to be "well, yes but its closed source to view and interact with" then just make netdata that, and dont lie to the Community. Badge yourself clearly as only doing open source data collection, and closed source examination of it.
If you want to make money as closed software, feel free to. But then market yourself like it.
In closing, I want to reiterate that Netdata is committed to transparency and adherence to open-source principles.
Then let Actions follow your words. BE open source, or split the v2 Dashboard.
BE OPEN about you locking down into a paid & closed model.
Correctly label your software on docker hub.
Approach distros about them shipping closed source code proactively, or remove it entirely. As you can see: no one in the open source world wanted this. The collective actions of the distros once notified hold a little more weight, to me.
We value the input from the community and remain open to dialogue about how we can continue to improve and align with the expectations of our users.
Split, or open source, v2.
I'd begrudgingly accept a netdata-agent only being open source, but i estimate why you didn't split this or actually make it transparent - it would lead to lower sales and homelab (and then company) adoption.
Anything else is more marketing attempts to proliferate the lie that netdata is in some way, shape or form intended to be open entirely, whereas there is no project-created-and-supported open source way to interact with your collected data.
In closing:
Split out v2, leave agent + v1 and badge the leftover data collector.
OR
Make v2 open source
OR
Go the route you seem to want to go anyway and only have agent open with paid/login view for v2 on cloud.
And for everyones sake please stop trying to insist that you are open source in some way, shape or form outside of the agent - your current default repo output and container images ship blobs.
Anything else does not befit a collaborative open source project, or one supposedly following open source badges.
And all of this you've known for years. You've ignored all the maintainers, all the users, all the bug reports and questions. (as linked in here). Hardly a "best practice".
Why do you only act when others find out the words you want to dress your project with do not actually apply?
Thank you for your detailed response. I believe we may be facing a fundamental misunderstanding regarding the relationship between open-source licensing and the presence of closed-source components within a project.
Clarifying the Open-Source Status
The core of the Netdata agent, which is licensed and released under GPL v3+, remains fully open-source. The inclusion of a closed-source binary (the v2 Dashboard) in the same repository does not alter the open-source nature of the GPL v3+ licensed code. The GPL v3+ license ensures that all code under this license remains open-source, providing users with the rights to use, modify, and distribute it. This is a well-established principle in open-source software.
The Role of Closed-Source Components
The v2 Dashboard, while closed-source, is distributed under a specific license that permits its use alongside the GPL v3+ licensed Netdata agent. The presence of this component in the repository is transparent and explicitly licensed, ensuring that there is no ambiguity about its status.
Addressing the Badge Eligibility
Regarding the OpenSSF Best Practices badge, the criteria focus on the management, security, and quality of the open-source components of a project. The badge does not require that every component of a project must be open-source, but rather that the open-source elements adhere to best practices. The Netdata agent, which is the core of our project, fully complies with these criteria.
Moving Forward
I understand that the presence of closed-source components may be a point of contention for some in the open-source community. We are open to discussing ways to improve transparency and user expectations, such as better differentiating between open-source and closed-source elements within our communications and repository structure.
However, the open-source nature of the Netdata agent remains intact, and its GPL v3+ licensing ensures that it continues to offer the freedoms associated with open-source software.
I look forward to seeing the OpenSSF's perspective on this matter.
However, the open-source nature of the Netdata agent remains intact, and its GPL v3+ licensing ensures that it continues to offer the freedoms associated with open-source software.
Same again:
"The software produced by the project MUST be released as FLOSS"
You do not release your Software in FLOSS - the v2 dashboard is closed source.
At least we went from "netdata" to "netdata agent", glad we're finally going onto the same page.
No source, no badge. Or, as said, split v2 from the agent.
The Netdata agent, which is the core of our project, fully complies with these criteria.
Nowhere on your repo or builds is it crystal clear from a glance that its "only the agent". Make that happen then.
And your website "Netdata vs the World" is a joke in the face of your statements. So much for "vibrant community".
I look forward to seeing the OpenSSF's perspective on this matter.
Me too.
And probably the same again once v3 happens, where you already pull the screws on users into a locked down ecosystem, the antithesis of open source.
Thank you for continuing the discussion.
On the Release of Source Code vs. Packaging
It seems there may be some confusion between "release" (the act of making source code available) and "packaging" (the distribution of software as binary packages).
The Netdata agent—the core of our project—is fully open-source and released under the GPL v3+ license. This means that all the source code in the Netdata agent repository adheres to the open-source principles defined by this license. The OpenSSF badge refers specifically to this open-source codebase.
While the Netdata agent itself is open-source, we do include the v2 Dashboard (a closed-source component, in binary form) in the repository as a convenience for building our binary distribution packages.
Respecting Distribution Policies
Linux distributions have their own policies regarding the distribution of open and closed-source software, and we respect their decisions to package Netdata in a way that aligns with their guidelines. This flexibility is a key aspect of the open-source ecosystem, allowing different communities to tailor software to their needs.
Moving Forward with OpenSSF
I believe it’s essential to let OpenSSF weigh in on this discussion. If OpenSSF determines that the inclusion of binary blobs of closed-source components within an open-source repository compromises the open-source status of the project, we are prepared to take the necessary steps, including potentially removing the closed-source dashboard from the repository.
Our primary goal is to continue to support and contribute to the open-source community while also ensuring that we can sustain and grow the project.
Let’s await OpenSSF’s perspective, and we’ll proceed accordingly.
i swear to god it's chatgpt or similar ai making these replies
Sorry for the drive-by, but I was eyeing Netdata for my home lab, so here's my two cents.
I understand Costa's argument but I'd argue per the Agent provisioning me the UI so that I can access the collected data, they're tightly logically coupled as the same thing (that is, Netdata).
When Netdata is shown in promotional material, I don't see the guts of the agent, I see the UI because that's the bit that makes Netdata useful compared to say, refreshing Prometheus metrics repeatedly. I find it difficult to separate the two because I think part of Netdata's power comes from compiling that data in a legible way for me.
On that note, even if Netdata [Agent] is under an open source license and fulfills metrics set by the OpenSSF, I feel like the UI being proprietary violates the spirit of open source (for me): The UI is a significant part of Netdata but I don't get to study and understand it, I don't get to modify what runs on my machine. And if I have any useful changes that I might want to give to the greater community, I can't do that without asking Netdata [the entity] for permission.
That doesn't feel like open source to me as a (potential) user.
In general, badge earners must simply meet the criteria. The OpenSSF Best Practices Badge Technical Steering Committee (TSC) may need to adjudicate this particular case! That said, let's make sure the TSC has correct information :-). Please don't consider this "weighing in" formally; consider these as "initial thoughts in a discussion". Sorry if it seems to be rambling; I'm trying to identify the "key issues" and then the answers to those key issues.
First: Everyone, please don't presume bad faith. For now, let's just focus on the facts of the situation. If a mistake has been made, then let's work to correct it.
So, let me start with some generalities. We've generally been flexible in the OpenSSF Best Practices Badge, as long as the project meets the criteria. We've allowed OSS projects that only run on closed source operating systems (e.g., OSS that run on Windows). We also permit "open core" projects where the project getting the badge is unambiguously OSS but there are optional extensions that are clearly managed as separate (related) projects and aren't OSS. We discourage but allow software that can only be built by closed source components (e.g., a build process that uses a commercially-available closed source compiler). Given those precedents, I suspect it'd be ok if the OSS depended on some external closed source software, as long as the closed source component is separate & externally obtained. E.g., I think we'd accept an OSS application that depends on Unity (a closed source game engine) or NVIDIA's CUDA, as they can be separately acquired. In short, we want to make sure that a specific project is OSS, and that everyone knows what is OSS & what isn't.
This obviously has some differences with the policies of Debian or Fedora. This does not mean that Debian or Fedora's policies are wrong, not at all!! It's just that the badge process intentionally allows a broader range of software. If a company decides to release project A as OSS and project B as closed source, I'll be delighted if they later decide to release project B as OSS, but my delight is outside the scope of this badge :-).
That said, the badge process is not intended for any software; these criteria were designed presuming that the project is producing OSS. So any software must meet the required criteria, e.g.:
- "description_good" - "The project website MUST succinctly describe what the software does (what problem does it solve?)."
- "floss_license" - "The software produced by the project MUST be released as FLOSS."
- "build" - "If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code." E.g., you can use a closed source compiler (as long as it's obtainable elsewhere), but you need to provide the makefile / build script / whatever specialized thing you use to build the project.
There's a lot to read in the issue discussion, but one sentence really jumped out at me:
While the Netdata agent itself is open-source, we do include the v2 Dashboard (a closed-source component, in binary form) in the repository as a convenience for building our binary distribution packages.
As best as I can determine, all agree that the "Netdata agent" is OSS (GPL-3.0), while the "v2 dashboard" that can display this data is not OSS. The older obsolete "v1 dashboard" was OSS.
A key issue, as far as I can tell, is that there are closed source components included in this project's repo that are necessary for expected function but are not widely understood as external components. At the very least I'd agree that's extremely confusing. Many people would expect that if a repository has a specific license identified for code, following that license would be enough to know what your rights & responsibilities are. Some code might also have a less-restrictive license (e.g,. there may be some MIT licensed code in a GPL-3.0 codebase), giving you more rights in some cases, but such less-restrictive licenses don't create "surprise" limitations. I can point to myself; when this issue was first raised, I went to LICENSE, saw "GPL-3.0", and said "sure, that's OSS". I don't think it's an unreasonable expectation.
I do applaud trying to make things convenient - wonderful! I wish more people would try making things easier. However, these "convenience" binary components appear to some others to be released by this project. If that's the typical interpretation, that would conflict with "floss_license" which says that "The software produced by the project MUST be released as FLOSS."
Since the blobs are a "convenience", would it be possible to remove those closed-source blobs from the repo & instead provide something (e.g., a script) to separately acquire them? I also think it's important that the project make clear that this repo contains just the netdata-agent. Otherwise, this repository seems to claim it's OSS, yet it's really a mixture of OSS code & non-OSS code. I'm not sure the TSC would agree that this meets "floss_license" when there's such confusion.
On that note, even if Netdata [Agent] is under an open source license and fulfills metrics set by the OpenSSF, I feel like the UI being proprietary violates the spirit of open source (for me): The UI is a significant part of Netdata but I don't get to study and understand it, I don't get to modify what runs on my machine. And if I have any useful changes that I might want to give to the greater community, I can't do that without asking Netdata [the entity] for permission.
The OpenSSF Best Practices Badge must take a complicated real world & turn it into simple statements, which is hard.
We do require criterion "description_good", "The project website MUST succinctly describe what the software does (what problem does it solve?)." So if only the agent is OSS, the description should make it clear that this project is only the agent, and if there's a convenience blob for display, make it clear how to acquire it.
It's okay if the same company provides an OSS project & a closed source component. I mean, I'd personally prefer that is was all OSS, but that's not a requirement. What is a requirement is making it clear which is which :-).
So I'd love it if the dashboard was also OSS, that's not the badge's call to make. I think we do need to make it clear what's OSS and what isn't, though.
I'm going to post to the mailing list that there's a discussion here. I realize this is long, but it's an important discussion, and I want to make sure everyone is treated fairly. Please respond carefully & don't assume bad faith - instead, please help us work towards a good solution. Thanks!
@david-a-wheeler and the OpenSSF community,
Thank you, David, for your balanced views. I admire your effort to carefully weigh all aspects of this situation. As an open-source project, we also find ourselves navigating a very thin line while trying to provide innovative open-source software.
For the moment we tried to clarify the components of Netdata at the README of the repo and also moved the badges to make it clear to which component they refer to.
As an open-source project, we are committed to navigating this challenging landscape responsibly. We will continue to provide clarity and follow the best practices for open-source software.
I look forward to continuing this dialogue and to the feedback from the OpenSSF TSC as we work together to find the best path forward.
provide innovative open-source software.
*partially open-source, with the important user interaction bits behind login & paywalls
For the moment we tried to clarify the components of Netdata at the README of the repo and also moved the badges to make it clear to which component they refer to.
You've missed:
-
the github project description (Please clarify it only targets the netdata agent, not the entire platform)
-
docker hub (same)
-
your website "netdata vs. the world" which is now blatantly falsely stating that you have a vibrant open source community (for the entire platform, not just the agent) :P
-
notifying the CNCF that netdata as a whole is not open source, but instead only the agent
-
that you still provide the closed source build from this repo, which was the initial issue, and still auto-load it from the agent on visit. Instead of, for example, providing only a netdata-agent build standalone and structuring the repo like it. V3/V2 are the only options going forward anyway, which will mean netdata cannot be used fully open source anymore if you want to act on the data as intended.
As an open-source project, we are committed to navigating this challenging landscape responsibly. We will continue to provide clarity and follow the best practices for open-source software.
The best path forward is to still be fully open source instead of locking down like this, but it is what it is and you set the path you're going down on yourself 🤷🏻
And please dont try to shove me off as "confused" again, thanks.
Two thoughts:
- Shipping free and non-free code in the same repository is going to lead to misunderstandings. GitHub and others tend to list a single main license for the repository and showing off a FOSS license under these conditions is then not correct. I can imagine this as a criteria for the best practices badge. For clarity.
- (big) binary blobs that cannot be reproduced in a git repository should be a red flag after the xz attack. It should be a big no no for a best practices badge. For transparency.
Dear OpenSSF and Community,
Thank you for the continued feedback and for helping us navigate this discussion.
@bagder, I believe you're right—having binary blobs in the open-source repository unnecessarily complicates things and can lead to misunderstandings.
Planned Changes
To address these concerns, we are actively working on the following:
-
Removal of Closed-Source Components: We are in the process of removing the closed-source components from the open-source repository to ensure that only open-source code is present. This will help eliminate confusion about the licensing of the code in the repository.
-
Separate Packages and Licensing: We will adjust our build process to generate two separate packages, each with a single license: one for the Netdata agent (GPLv3+) and one for the Netdata UI (NCUL1). This separation will provide clearer delineation between the open-source and closed-source components and also potentially fix the issue for the Linux Distributions.
-
Docker Image Clarifications: While we cannot fully separate the components in our Docker images, we have already updated the descriptions on Docker Hub to clarify that the images include two distinct products with different licenses.
-
README Updates: We have thoroughly reviewed the README in our open-source repository to add clarity regarding the components each feature refers to, and we have noted the inclusion of closed-source components where applicable.
Moving Forward
We are committed to making these changes as quickly as possible (I expect 2-3 weeks) and will continue to ensure that our project aligns with the best practices for open-source software. Our goal is to maintain transparency and build trust within the community while sustaining the development of Netdata.
Thank you for your ongoing engagement and support as we work through these improvements.
Commenting as an uninvolved outsider who was curious about netdata and the OpenSSF licenses, and is unsettled by what's happening.
The description for the Netada project is The open-source observability platfrom everyone needs! (as of commenting, August 27 2024). This implies, as a user, that the platform is open-source! Great, wonderful!
The README then outlines three core components: the agent, the cloud, and the UI. Reasonable, this is what comprises a "platform" (not just a "tool"). However, only one of these, the agent, is FLOSS. The other two are commercial or closed-source! Yet the whole platform, and the repository are labelled as FLOSS. This is intentionally deceptive, and borderline malicious.
The fix, as outlined in detail earlier, is simple: separate the projects, and stop calling the platform "open-source". Because something is "freeware" or "free-trial" does not make it "open-source". The source for the platform (not just the agent, agent != platform) is not open, therefore the platform is not open-source.
Thank you @GhostofGoes for your comment. You are right. The platform is not entirely open-source.
I changed the repository description too.