Is it allowed to use CKEditor5 in a commercial (closed source) application?

According to this github page they use GPL 2: CKEditor5 License

I will publish any changes to CKEditor5 I will do and make them open source.

But I don't want to publish my whole application as open source.

AFAIK CKEditor5 is a rewrite which shares not much with the CKEditor4. The CKEditor4 License is LGPL, which means I may use it in my closed source code.

  • 1
    You will need to tell us considerably more about how you want to use CKEditor5 in your application. – MadHatter Sep 10 at 15:20
  • @MadHatter I want that the user is able to edit HTML in a WYSIWYG way. I don't want to modify the source. And my application is written in Python with almost no JS. Do you need more information? – guettli Sep 10 at 17:55
  • 1
    Yes. How will your code invoke CKEditor5? Does CKE5 provide library functions which you call? Will your code construct an arbitrary file or filename, then fork-and-exec a copy of CKEditor5 so the user can edit the file, which is then received and further processed by your code when the editor exits? Something else? – MadHatter Sep 11 at 5:10
  • @MadHatter I want to use it like documented here: ckeditor.com/docs/ckeditor5/latest/builds/guides/…. I won't use library functions. There won't be fork-and-exec happening. – guettli Sep 11 at 14:28
  • The page you point to shows the use of functions that CKEditor5 defines, eg "Call the ClassicEditor.create() method". Is that how you intend to use the code? – MadHatter Sep 11 at 14:36

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.

| improve this answer | |
  • I am unsure. You use the terms "dynamic linking", "library" "fork-and-exec". I know these terms from past (Linux, C, gcc, ...). Above example is from a different environment. You said "Python", but CKEditor does not know this. Both applications communicate via https. But thank you very much for your detailed explanation for your opinion. – guettli Sep 17 at 12:45
  • 1
    @guettli I'm sorry, you're dead right. It's been a while since I read the CKE page, and I had conflated two questions in my mind (the other being about Python, which is also interpreted). This question is about Javascript. Nevertheless, the point stands: your JS code tells the clent browser to load the library, then calls their GPL code using a function they provide. I have modified my answer accordingly. – MadHatter Sep 17 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.