Implications of using GPL-licensed client-side JavaScript?

This gets explained very well on this page:

https://greendrake.info/#nfy0

Does using JavaScript code on a website constitute distribution of the code to the website visitors?

Yes

Does GPL'ed client-side JavaScript "infect" the server-side code?

No

Do I have to GPL my client-side JavaScript code if I am using a GPL'ed library in it?

Yes.Yes.No.

...

So having thought about this, I should be clear how I'm coming at the answer. We already have a pair of questions that address the issue of whether dynamic linking creates derivative works; one for those who think it does, and one for those who think it doesn't. Both note that the question remains unsettled, but I firmly believe that dynamic linking does create derivative works, and the rest of this answer reflects that.

In this question, you're using a GPLv2 Javascript application as a library: your JS code calls functions it provides. The core question is: to what extent are interpreted languages that make such calls at run-time similar to the behaviours of dynamically-linked executables that cause them to be derivative works of their linked libraries.

To my mind, one of the key arguments for dynamic linking creating derivatives is that, unless there is a published third-party guide to the API, the only way to discover how to call the library code (either via dynamic linking or at run-time) is to inspect the library code, or to read the (GPLed) project documentation.

If you were to inspect the library code in order to reimplement it from scratch, you would have contaminated yourself such that the reimplementation is likely to be held to be a derivative work; hence the clean-room reimplementation. As I see it, the same applies to anyone inspecting the library code in order to work out how to call it; you are taking its methods and APIs with you following an inspection of the source. As pointed out elsewhere in the SE universe, APIs can be and often are copyrightable; Oracle v. Google turned on a fair-use defence, and (by clean room principles) it's not at all clear one could succeed in one of those after having read all the source code.

So as I see it, you're doing something just as copyright-entangling as dynamic linking, and thus your work has to be GPLv2 also. If you invoke the editor at arms-length, through (eg) fork-and-exec with a simple filename passed between caller and editor, I would hold differently; but you're not, and the fact you're doing it in an interpreted language rather than a compiled one doesn't make me see it differently.

Edit: I also suspect that the CKEditor people see things the same way. They write:

CKEditor 5 is licensed under the terms of GNU General Public License Version 2 or later.

If you are running an Open Source project with an OSS license incompatible with GPL please contact us and we will be happy to support your project with a CKEditor 5 license.

Earlier versions were licensed under multiple terms, one of which was LGPLv2.1+. This option has gone, for version 5; clearly they feel that there are uses that LGPL permitted that they no longer wish to permit, and your proposed usage seems to me to be exactly one such.