New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling TinyMCE license change #4908
Comments
What other editors are considered? Maybe it could be worth to switch, if the new editor bring some new useful features? |
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. |
There are other options, some of which can be seen in my comment here with some light evaluation: That's from when I spent time trying to switch to prosemirror a couple of years back. 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. |
An option might be to leave markdown in the core and add TinyMCE with the new license as a plugin. |
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 |
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. |
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? |
I wonder if https://playground.lexical.dev can be considered. |
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? |
@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. |
Quick look around, and its not bad.
|
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.
The text was updated successfully, but these errors were encountered: