Remove netdata from projects list (became partially closed source) #2153
Comments
|
The "projects" list for project 2231 is here: https://www.bestpractices.dev/en/projects/2231 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 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) |
|
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:
However, we do require build-ability:
Believe it or not, I don't think we've ever discussed "binary blobs" in the badge project. So I propose these steps:
Thank you for your information! |
Thank you very much! I'd request to look through 2 cases specifically for 2 (but more are always welcome!):
Edit: Otherwise you could simply make a project with a completely closed source ui, yet still earn this badge. |
|
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 CommitmentNetdata 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 ConcernsThe 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 SolutionIt 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 PracticesWe 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. |
You could have shortened this to "Yes, we have switched to a partially closed source model."
Which makes your default solution not open source. 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.
Your response shows an almost malicious intent to keep profiting off the open source community while closing down the actual business end.
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.
And the main ui to use it with as per default build, is not
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.
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:
Opensuse Bug report: PATCHED after being notified Alpine Linux: PATCHED after being notified Nix: Split by themselves, packaged Netdata Cloud separately Debian: still has not updated and you're being a headache to the maintainer More to come, likely. So no - the "Community" doesnt expect, or want, v2 and you've not done us a favour with it. 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. |
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. |
"The open-source observability platform everyone needs!" which is also the title bar 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
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. |
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. |
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. 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: 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+ ComplianceFirst 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 PracticesThe 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 NatureRegarding 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 SustainabilityWe 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 Now, to the marketing points:
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.
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? No, No and No. You are not open source.
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).
You are, as of today, shipping only v2 as supported option to view the data by your project, which is closed source.
Then the badge would be a sham, from my view, and i will communicate this further. But that is not for me to decide, only for the badge project.
You are, once again, not open source usable anymore with your own tools (in a way that is supported). 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.
Their Packaging Guideline is "is this open source". Which your repo with the v2 dashboard, is not.
Which you have been freeloading off of, and silently changed this in a way that was maximum plausible deniability.
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.
Then let Actions follow your words. BE open source, or split the v2 Dashboard. 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.
Split, or open source, v2. 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. 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 StatusThe 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 ComponentsThe 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 EligibilityRegarding 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 ForwardI 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. |
Same again: "The software produced by the project MUST be released as FLOSS" 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.
Nowhere on your repo or builds is it crystal clear from a glance that its "only the agent". Make that happen then.
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. PackagingIt 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 PoliciesLinux 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 OpenSSFI 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.:
There's a lot to read in the issue discussion, but one sentence really jumped out at me:
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.
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. |
*partially open-source, with the important user interaction bits behind login & paywalls
You've missed:
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:
|
|
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 ChangesTo address these concerns, we are actively working on the following:
Moving ForwardWe 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 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. |
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 text was updated successfully, but these errors were encountered: