He states that

There are now two definitions of Scrum. One is maintained and sustained by Jeff Sutherland and myself at www.scrum.org. Another is an old copy that is posted at www.scrumalliance.org, by the ScrumAlliance.

His article continues mentioning what sounds like the start of a copyright dispute over the Chinese version of the Scrum Guide which in its original form is written and maintained by Ken Schwaber and Jeff Sutherland. Apparently now the ScrumAlliance claims ownership to the Chinese translation of the Scrum Guide. As Ken points out

Any of you familiar with copyright law know that a derivative of the original is still owned by the original copyright holder.

Ken Schwaber recommends

that you refer to the Scrum Guide created and sustained by
the authors of Scrum, Jeff and myself.

This is serious news.

Do we see the beginning of a split up of Scrum?

Well I don't know about that but the way I read the article we are seeing a split up between Ken Schwaber and Jeff Sutherland with the ScrumAlliance.

Already scrum.org, maintained by Ken Schwaber and Jeff Sutherland offers a Scrum Assessment program that looks similar to the one offered by the ScrumAlliance.

What good will come out of it?

Well again, I don't know. My personal opinion is "not so much".

I see Ken's point and his desire to keep his intellectual property his (and Jeff's).

I also agree with Ken that it is required to have one (!) formal description of what Scrum is. As he points out in application Scrum is mixed up with other agile approaches such as Kanban, XP and others. This makes it important to have one (!) "master copy" of what is Scrum and what is not Scrum. A benchmark is required.

Paul Oldfield of Capgemini may be right that in reality, in the scope of your project it does not matter whether your Scrum is 100% pure or whether you mix it with other methodologies in order to make it work for you.

The importance of a formal definition is on the global scale, not on project scale.

If Scrum minus Burndown Chart, plus 30% Kanban and estimations done through COCOMO works in your project, keep doing that! But don't call it Scrum.

There is only one definition for each of software design pattern. Differences in implementation in your project don't matter. But if I ask in a job interview what the "goal" of the Factory design pattern is and the answer is not something along the lines of "it deals with the problem of creating objects without specifying the exact class of object that will be created" ( (c) Wikipedia) the candidate fails. He doesn't know the Factory design pattern.

If you tell me your estimation method is PERT and the formular is "(opt + 3*real + pess) / 6" you are not using PERT. The estimation technique you're using might work perfectly well for you but it is not PERT.

Same for Scrum. The importance of one formal definition lies in what you know and what everybody (!) agrees to, not in what you do.

We need one formal definition

We are able to benchmark people against a principle only if there is one commonly agreed upon definition.

If there are several definitions of one principle the whole idea gets diluted and harder to assess. The principle in itself might - but doesn't have to - become less important.

I have no background information on what lead to the confusion as Ken calls it. But surely I hope that all involved parties get back on one table and keep Scrum unique. Keep it simple. Don't dilute it.