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:
#2738 (comment)

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.