Handling TinyMCE license change

[ssddanbrown]

In BookStack we use TinyMCE as the main WYSIWYG page editor (in addition to the newer description/comment editor boxes). Starting with TinyMCE 7 they've changed their license from MIT to GPLv2+ (and it was LGPL before MIT). They also have a GitHub discussion for this here which I've commented on.

This puts us in an awkward place, since GPLv2+ is incompatible with the MIT license that BookStack is distributed under. We could change to a compatible license, but I'm not keen on forcing that upon the BookStack user-base as it could functionally impact existing use-cases. I chose the permissive MIT license originally because of the user freedom & simplicity it provides. Even if we did change license just because of this, this is the second recent license change from Tiny, and they have reflected a very business focused direction, with more code moving out of the open source offering, a higher focus on the commercial offerings, and questionable licensing information (https://danb.me/blog/misrepresenting-open-source/). I'm not convinced that the open offering will remain further unhindered.

I'm currently thinking the best way forward would be to fork the existing MIT code for our use, likely stripping things back as much as possible to reduce the scope of future maintenance. This could open up opportunity for easier fixing/development & future BookStack specific ideas, but the added scope & maintaining surface area will very much be significant and is quite daunting. I may need to spend some time playing the the TinyMCE source to get a realistic idea of potential impact.

Another option is to switch editor library but, from my attempts of this a couple of years back, that's likely more painful. Easy to get something going, but ensuring forward compatibility and feature parity is a wild adventure of edge-cases.

[Szwendacz99]

What other editors are considered? Maybe it could be worth to switch, if the new editor bring some new useful features? The option with a fork of TinyMCE could be good too, since it is not closing the posibility or making harder to move to another editor later.

[szabeszg]

What other editors are considered?

I suppose there isn't anything else to consider. For instance, relatively recently, ProcessWire switched to TinyMCE 6 from CKEditor 4 because CKEditor 5 was also out of the question. See: 

• https://processwire.com/blog/posts/reconsidering-the-ckeditor-5-upgrade/
• https://processwire.com/blog/posts/new-rte-for-pw/

[ssddanbrown]

There are other options, some of which can be seen in my comment here with some light evaluation: https://github.com/BookStackApp/BookStack/issues/2738#issuecomment-1022683101

That's from when I spent time trying to switch to prosemirror a couple of years back. Based on my experience of that, I know that switching editor will be a significant endeavour when aiming to reach a level of forward compatibility/stability I'd be happy with.

Think forking TinyMCE will be the best bet for now, at least in a "maintenance only mode" to get a feel for future potential effort or potential directions there. I've spent some fair time exploring TinyMCE source over the years of debugging so hopefully maintaining current functionality wouldn't be too bad.

[ivangretsky]

An option might be to leave markdown in the core and add TinyMCE with the new license as a plugin.

[guillerg86]

As @ivangretsky said, maybe a good approach is to add TinyMCE as a plugin. Just add a line in .env file like "TinyMCE=enabled" and make some php script download

[ssddanbrown]

Sure, I appreciate there are ways it could be done but I'm really not fond of a major core part being made optional, with maintenance of fallbacks. It's always been a core idea that the app is "batteries-included" by default, would be a big shame not to be able to provide a complete app. Plus, as alluded to in the original post, I'm not how much I trust Tiny anyway.

[ivangretsky]

I'm currently thinking the best way forward would be to fork the existing MIT code for our use, likely stripping things back as much as possible to reduce the scope of future maintenance.

I suppose there isn't anything else to consider. For instance, relatively recently, ProcessWire switched to TinyMCE 6 from CKEditor 4 because CKEditor 5 was also out of the question.

Just maybe there can be some sort of collaboration between projects still needing a regular content editable editor like TimyMCE or CKEditor with an MIT licence? On a common fork?

[DanielPantilimon]

I wonder if https://playground.lexical.dev can be considered.

[otherjoel]

I chose the permissive MIT license originally because of the user freedom & simplicity it provides.

Do you have a sense for how much of your user base actually does things with BookStack that would be affected by a license change? I.e., are many people distributing modified versions of BookStack without releasing the source?

[ssddanbrown]

@otherjoel No, not really. It would be a rather minimal part of the audience, but I'm not keen on abandoning even a small part of the audience, and having to change our ideal/desires of licensing due to a business change of a sub-component, especially where the intent of change, and future direction, of that sub-compontent is questionable.

[alatteri]

Quick look around, and its not bad.

I wonder if https://playground.lexical.dev can be considered.

[ssddanbrown]

I wonder if https://playground.lexical.dev/ can be considered.

Thanks @DanielPantilimon (and @alatteri). Don't think I've come across that one before. It looks quite extensive, but from my previous experience the tricky part is in the minor detail and compatibility. Think I'll put some time aside to do a compatibility run & test implementation of this one.

---

There has been a Tiny fork here but I'm not confident on direction and long term maintainership of that. Would have to inquire/watch.

Tiny have since confirmed TinyMCE 6.x support until the end of October.

I've also had Tiny reach out to me to offer a custom license, but nothing that would be any more compatible in my view over a GPL license.

[guyinpv]

Maybe looking a little further into the future, you might start planning for the eventually take over of block-based editing. The kind of thing you see in coda.io and Notion and many others. See https://editorjs.io/ Editorjs has an Apache2 license so I don't know if that would fit with your MIT, but probably could as long as the changes to core code are documented. You likely wouldn't even need to change core code since it's highly extendable.

Even if you made such a block editor a new default, you obviously have to account for legacy pages, or provide some kind of converter, or just keep a forked copy of Tiny around. But any new installs or new pages could default to block. This could work similar to how we can switch a page editor to Markdown mode, it might work, might have bugs, but we can do it if we want.

Block editors like these are getting more and more "smoother" to use, feeling almost as natural as writing in WYSIWYG. You can create any "tool" imaginable to make a block, such as draw.io charts. All the normal formatting, all the normal embedding, markdown support, shortcut keys, deep linking, exporting in various formats, etc. Lots of modules/tools have already been created for it.

I wouldn't be mad if you eventually go this direction!

[szabeszg]

I hope that a solely block-based editor will never be forced upon us. I think an editor which is between both worlds would be the best to have. I can envision a WYSIWYG editor that optionally supports visually editable "inline blocks" for use cases that aren't feasible for a text editor to support. That would be like having interactive WordPress short codes inline.

[ssddanbrown]

I don't really see us moving to a block-based editor, at least on the idea of doing so to get access to a range of modules/blocks. The lack of (relative) complexity in what we support in page content is purposeful and something I think that's important for a documentation platform, with aims for content standardisation and portability. I certainly would not look to support a third adjacent editor option.

[ivangretsky]

I would propose consider leaving only one type of markup - markdown. And have all the extra markup as markdown plugins. Full conversion between modes doesn't work in all cases anyway and you always have to make a choice which one to use beforehand.

Just another option.

[ssddanbrown]

I've been building, and playing with, a lexical based editor via the branch on PR #5058. I found early on, that many of the supported content types, and all of the UI, shown in their playground in based on their react-specific and or playground-specific codebase, so really it requires us to create/implement quite a lot where we don't want to rely on those elements, which I'm not overly confident with. This does mean we can build things to closely match what we already have though.

Making some good headway. Have implemented a range of formats and getting familiar with the editor fundamentals. Have put together some core elements of a UI framework too. Still quite a mountain to climb though, and it can be minor annoying elements that cause the most strain, and zap the most will. Just trying to chip away at it day-by-day. Somewhat hopeful this can end up with a result though, and one with more flexibility and opportunity for future ideas/additions in BookStack.

[szabeszg]

Thanks for the effort, Dan!

a lexical based editor

Can Lexical provide direct editing access to the HTML? It's always a must-have for me.

[ssddanbrown]

Can Lexical provide direct editing access to the HTML? It's always a must-have for me.

@szabeszg We could build that functionality in, and I would plan to to match the existing editor, but the exact handling of pasted HTML (and what gets filtered/removed and how the content is handled) may differ to that of the handling of what we have configured for TinyMCE, so it could depend on exactly what you're modifying in the HTML.

[DanielPantilimon]

Hi Dan, I would like to suggest another implementation of the Lexical editor: https://matheditor.me/playground The project is available MIT on GitHub: https://github.com/ibastawisi/matheditor It might help you get up to speed faster, specially for the image plugin that is better implemented in the matheditor

[ssddanbrown]

@DanielPantilimon thanks but that's really built as a project rather than a library. And really I'd rather build on the fundamentals rather than understand/alter an existing direction/project/attempt.

[szabeszg]

@ssddanbrown You might want to consider applying for a custom license. See: https://github.com/tinymce/tinymce/discussions/9609

[ssddanbrown]

@szabeszg they reached out to me directly to offer that before making it a public offering, but I rejected them since any such custom (project/user-specific) license would be even less compatible that the GPLv2+, since it generally wouldn't be considered open source.

[szabeszg]

@ssddanbrown I see.

I do not know what their exact idea was, but personally, I do not care about being able to modify TinyMCE. All that matters to me is whether I can use it freely. Of course, you naturally have more concerns than that.

[ssddanbrown]

@szabeszg Sure, but I want to ensure BookStack as whole remains open source. This means open to use, modification & distribution. I want to ensure users will have those rights, regardless of whether that's under this core project or a fork. If I get hit by a bus tomorrow, I want to ensure the code/project has a chance of surviving (or even if users want to take the project in a different direction).

[Wertisdk]

@ssddanbrown If you end up having a go at making a fork of TinyMCE 6.X, I'd be happy to lend a hand with anything from maintaining code to testing and providing feedback. I work for a company that provides an app somewhat similar to Bookstack (A Quality Management System, a bit like a CMS), where we also rely on TinyMCE as our document / page editor since TinyMCE 3 was released.

I have been testing out alternatives for the last few years, and the only editor that felt like it could provide both the same basic functionality and usability was CKEditor, both of which are now unfeasible for our purpose.

I'm also following your progress with the other editors.