I speak the same native language as Lennart and apparently I have the same misunderstandings of the language. I agree with his reading, that NTP welcomes usage (as a default in your open source project) iff you apply as a vendor. Can you point me to a better clarification on why this reading is wrong?
Lennart said in the linked thread that systemd was not allowed to use pool.
> Its up to the distros to register an ntp pool product. systemd is not a product. Its just some toolset people can build products from. We cannot use the ntp pool hence. If the googl time servers
In this post he says that systemd is not a product. In the context of whether they're allowed to use pool.ntp.org systemd is a product.
> Coreos should register its own product with the pool and use that. Systemd upstream is not a product, we shouldnt register it as one. distributions such as fedora have their own pool, debian has, ubuntu ha, arch hass. if downstream dont set the correct pool for their product then thats something to fix downstream.
Here he repeats the line that pools is forbidden:
> the ntp pool made very clear we cannot use them. As i read what is written above google just says the servers are crap but doesnt explicitly deny us to use them. Which is why id like to leave them in place because they are at least googd enough for testing purposes.
And here:
> We are an open source project, with no legal entity behind it and as such we are not the ones who can take responsibilty and not the ones who register as a vendor at the pool. [...] but right now the ntp pool is nothing we can use since the non-vendored pool is explicitly forbiddrn for us and the vendored pools dont apply to us since we arent a vendor.
He makes the claim several times in that thread.
But even if we accept that pools should not be used: that doesn't mean you can use Google's time servers. Google have asked systemd to stop using them and provided strong reasons.
That doesn't look at all like a language barrier problem. That looks like Lennart understood perfectly well, that usage of the pool is conditional on registering a vendor pool and that he has perfectly sound reasons not wanting a systemd vendor pool. And note, that the main Maintener of the NTP pool agreed with his reasoning.
I also somewhat agree with Lennart, that the reasons Google give don't really apply.
However, I also agree, that they shouldn't be used nevertheless :) Luckily, as I understand it, there seems to be somewhat of a concensus to not put a default and instead have fail the build if nothing was ./configure'd.
They're Google's servers. If they aren't meant for your use they can ask you to stop using them without any reason at all. The fact that they provided reasons at all is simply to inform people how they're systems are not going to operate normally.
To me it reads like a soft rule, especially amenable to something as big as systemd. Any decent project leader honestly looking for a solution in such a situation, would reach out to ntp.org and explain the problem. If he cared, of course.
> ...to provide a correction to someone saying pools can't be used.
Yes. Someone claimed (correctly), that *.pool.ntp.org can't be used. abh ammended that by saying, that however, a vendor zone can be used. I don't think anyone ever doubted that point. Notably, Lennart seemed to be aware of that point in his earlier mail.
> That's something that LP appears to have considered. I'm not sure why that isn't done.
The reason given before was, that tests and similar need some values. However, a PR implementing exactly this solution is currently in discussion (and afaik Lennart has not respondet to that yet). I would wait until the dust is settled on that, before I continue this discussion. The bug report (which is afaik the first time anyone has indicated that the Google servers shouldn't be used for this) is half a day old, that's basically nothing in FOSS-development (especially for a non-critical issue like this). Give it some time, if this isn't solved in a week, that may be a more appropriate time for pointing fingers and being unpatient.
I think the problem is not a language problem but rather both a set-theoretic and a technical issue specific to how NTP works.
Set-theoretic: what exactly is meant by "the pool"?
Is it: a) the set of all NTP servers on the Internet which cooperate with those on .pool.ntp.org, b) the subset of NTP servers with hostnames [0-9]+.pool.ntp.org, c) the subset of NTP servers with (one or more particular) "vendor" subdomains under .pool.ntp.org, d) a particular intersection or union of any of these sets?
Technical: Does the perceived restriction on who may or may not use "the pool" apply to NTP servers which wish to participate in "the pool", or to NTP clients which simply wish to synchronize their clocks?
I've found several documents, from ntp.org as well as from other sources, with varying levels of vagueness and contradictory language.
