Drupal core ships CKEditor 5 as its default rich-text editor under the GPL. While this is technically license-compatible with Drupal itself, there is ongoing confusion in the community about what obligations this places on Drupal site owners.
CKEditor's own licensing materials often state that if the GPL version of the editor is used, then the "application using it” must also be GPL-licensed. This statement is relatively straightforward for distributed software, but becomes ambiguous in the context of web applications.
In Drupal's case, most of the application (PHP code) runs server-side and is not distributed to users, while CKEditor 5 is a JavaScript application whose files are downloaded and executed in the browser. Some interpret this client-side delivery as "distribution” under GPL, while others follow the common interpretation (and FSF guidance) that typical web usage does not constitute distribution of the application as a whole.
Even under a more expansive interpretation where CKEditor 5 is considered "distributed,” Drupal sites generally use it unmodified, and the site itself is not a derivative work of the editor, it merely uses an editor. Nevertheless, the way CKEditor's licensing is described publicly creates uncertainty for site owners, particularly those running proprietary or closed-source Drupal sites, who want to be confident they are compliant.
Given that:
- CKEditor 5 is the default editor in Drupal core,
- it is not trivial for site owners to replace,
- and licensing ambiguity creates real concern for users,
it would be helpful for Drupal to explicitly document the assumptions and interpretation it is operating under when shipping CKEditor 5 under GPL.
This may require coordination with the CKEditor team to ensure expectations are aligned and clearly communicated.
---
Related: There is a parallel discussion in the Drupal core issue queue about CKEditor 5's suitability as a default dependency: https://www.drupal.org/project/drupal/issues/3562959
Comments
Comment #2
adr_p commentedComment #3
kreynen commentedRelating issues. I'll post more thoughts later today.
Comment #4
kreynen commentedBecause the
heated discussionsproductive conversations around licensing of client-side JavaScript in general and WYSIWYG editors specifically in the Drupal project has been going on for 15+ years (and nearly burned many of us out), I thought this would be crystal clear by now. After looking for a simple FAQ to respond with, I can see there is STILL remove for improvement.IANAL, but from a legal perspective, I don't see any issues.
https://ckeditor.com/legal/ckeditor-licensing-options/ is pretty clear on the options, stating...
The CKEditor project includes https://github.com/ckeditor/ckeditor5/blob/master/COPYING.GPL
Drupal includes https://git.drupalcode.org/project/drupal/-/blob/11.x/core/LICENSE.txt?r...
So technically, we are meeting the requirement of https://www.gnu.org/licenses/gpl-faq.en.html#WhyMustIInclude and clearly distributing CKEditor with Drupal as GPL-2.0 (with the option to distribute as GPL-3.0 if someone chooses to do that somewhere other than Drupal.org).
Where I think there is room for improvement is leveraging newer licensing-related tools like https://getcomposer.org/doc/03-cli.md#licenses and https://classic.yarnpkg.com/lang/en/docs/cli/licenses/. If you look at the number of licenses in https://git.drupalcode.org/project/drupal/-/blob/11.x/composer.lock?ref_..., it isn't surprising there is still confusion.
Thanks for bringing this up. More to come.