Hi! CKEditor team here
The CKEditor 4 LTS pricing model is flexible and the final number depends on multiple factors. We don't currently have a self-service system to sell those licenses too.
I know this isn't the answer that you were looking for and anticipating next questions I'll repost here a fuller answer that I gave recently on Drupal's Slack channel:
The LTS pricing as well as CKEditor 5's pricing model is flexible and the final number depends on multiple factors. While I totally get why this may not be one’s favorite model, it’s a result of us trying to stay flexible and enable the largest number of customers to buy a license. Our customers range from small businesses, single person companies with 3 potential editor users, to biggest enterprises in the World with tens of thousands of users. There’s no single pricing to fit them all. And the prices will differ significantly, so whatever I or anyone else could include here, might be confusing to someone.
I understand it’s not the answer that you were looking for, but in my opinion it’s best to contact our team and talk to them.
There has been actually work happening in a duplicate of the issue that you mentioned (both were opened by me 🙈) :)
Just last week we resolved https://github.com/ckeditor/ckeditor5/issues/14925. You can test how it works on the nightly docs: https://ckeditor5.github.io/docs/nightly/ckeditor5/latest/features/pasti...
A bit more context on the versioning from our side:
CKE5 ecosystem is around ~100 pkgs now. In the past, we versioned them independently, just like semver dictates. Some were in e.g. 5.0.0, other, that changed slower were 1.1.10 let's say. All good.
But, that created an awful DX – you could never know which packages are actually meant to work together. It'd be fine if you were using the very latest versions of all of them, but sometimes you can't. So, when trying to hardlock to some older CKE5 version, you'd need to somehow figure out versions of all CKE5 packages that were shipped at the same time.
Theoretically, you may ask, why is it necessary to get those shipped at the same time if you use semver and track all BCs? Couldn't I get some of the latest, but keep some of the older ones if... well, if what?
Let's welcome npm on stage. And transient dependencies.
Let's say you use two CKE5 features – FeatA and FeatB. cke5-featA@1.0.0 requires cke5-engine in version ^1.0.0, cke5-featB@1.0.1 relies on a newer version of the engine (^2.0.0) as it was released a year later. As a developer integrating CKE5 you'll only see the versions of featA and featB pkgs. So you think all's good.
What will npm do if you try to install this setup?
It will install the cke5-engine package twice to satisfy both feature packages needs. That makes some sense in Node.js, for which npm was built, although, causes issues there too from time to time. But it makes zero sense for the web, where you don't want and very often cannot include one library twice in different versions. Hence our "ckeditor-duplicated-modules" check.
This isn't a problem isolated to CKEditor 5 itself. We've seen people running into similar issues with other projects too. And we researched how did some of them resolved this madness.
The most sane resolution was to ditch semver. This kinda works (but again, not often) for libraries, but makes no sense for ecosystems of packages. I don't remember anymore what projects we followed (I think babel and Angular) but we realised that by having all our pkgs in the same version we're resolving many integrators issues.
But then, the side effect is that a braking change in one package needs to somehow be reflected on the version of all packages. Something that happened in this case. A very narrowly used CKBox package had to have a BC due to a new major version of CKBox itself that had to rebuild its configuration. This isn't a widely used package yet so investing our limited capacity into building compat layer and/or shipping this without a BC on CKE5 side could not be justified. It's literally cheaper to go on a call with everyone using this package and resolving this for them :D
So, my recommendation is to analyze the changelog of CKE5 itself where we're trying (not always successfully, but we're hopefully improving on this) to list all BCs (that we divide into two categories based on their impact) and figure out whether this is a major or minor release for your use case. The version number of CKEditor 5 is a secondary thing and I started thinking we should use only the X of X.Y.Z :D
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .
Wim Leers → credited Reinmar → .