feat: offer dashboard v2 enablement features

[RaitoBezarius]

Summary

Fixes #15640 #16035.

Dashboard V2 is under NCUL1 (https://raw.githubusercontent.com/netdata/netdata/master/src/web/gui/v2/LICENSE.md).

For packagers, to convey the accurate set of licenses, it is helpful to distinguish free licenses from free + unfree redistributable components.

In NixOS, we have two expressions of netdata: netdataCloud containing all the cloud features, including the cloud UI (unfree) and netdata (free) stripped of all cloud features.

We carried another version of this patch for the Makefile, this would make the packager's work easier to put it at the build system level.

Test Plan

Deploying this with -DENABLE_DASHBOARD_V2=off just fallback to the v1 dashboard.

Additional Information

FWIW, I completely understand the need of NCUL1, but I need to abide the rules of licensing as a NixOS developer. Some folks would like to use software while abiding a 100% free software rule, we offer that possibility, and, we would like to keep it. I personally use the cloud UI because of the value it brings me, but carrying a weird patch downstream is worse for our users in terms of security. I would like this to come to an end with this PR, if that's possible.

[ktsaou]

The problem with v0 and v1 is that they are unmaintained.

So far we have tried hard to keep backwards compatibility in Netdata, for them to work, but it becomes increasingly more complex and the code ends up being more like spaghetti. I think that at some point, we will have to give up and drop v0 and v1 support.

There may be a solution though...

index.html is responsible for dashboard routing. So, if we provide this piece as GPL, you should be able to package Netdata as GPL only.

Keep in mind that once index.html is loaded to a web browser, it will fetch the latest v2 dashboard from the internet, giving users the full functionality of Netdata. So, although v2 will not distributed and installed with the Netdata package, it will still be used.

Would this be acceptable for you?

[RaitoBezarius]

The problem with v0 and v1 is that they are unmaintained.

Yeah, I do understand this, but people may feel strongly about free dashboards and want to keep the old UI for some reason, this is ultimately your choice to drop it completely, but people may re-introduce it until it break and v2 is the only thing left.

So far we have tried hard to keep backwards compatibility in Netdata, for them to work, but it becomes increasingly more complex and the code ends up being more like spaghetti. I think that at some point, we will have to give up and drop v0 and v1 support.

There may be a solution though...

index.html is responsible for dashboard routing. So, if we provide this piece as GPL, you should be able to package Netdata as GPL only.

Keep in mind that once index.html is loaded to a web browser, it will fetch the latest v2 dashboard from the internet, giving users the full functionality of Netdata. So, although v2 will not distributed and installed with the Netdata package, it will still be used.

Would this be acceptable for you?

I mean, it's a gimmick somehow, for self-hosters who want to control the origin of their static assets, they still will need to download those static assets and those are NCUL1.

What can be done I guess is that I can split the dashboard into a separate package under NCUL1, as there's no build process for it, there should be no penalty in the build time by assembling it as an unfree component in the end.

If you feel strongly about v0/v1 being dropped soon-ish, I feel like this is the best solution, at least, this keeps the control of the static assets origin at the cost of some assembling code which is cheap in general anyway.

[Ferroin]

From a code review and testing perspective, LGTM.

From a personal perspective, I agree that this is needed and should be included.

From a corporate perspective, this will unfortunately need internal discussion before anything can be done WRT it.

[Ferroin]

And of course I missed the existing discussion before reviewing...

Splitting the dashboard to it’s own package is indeed probably the best option here, and there has been some internal discussion within the agent SRE team in the past about the possibility of doing this ourselves (though it’s never gotten as far as actual implementation).