On TinyMCE 7 moving to GPLv2+

[lostkeys]

Dear TinyMCE Community,

We're reaching out to share some important updates regarding the licensing of TinyMCE 7.0. As TinyMCE has evolved, so have our approaches to licensing, each reflecting our ongoing commitment to the open-source community but also the sustainability of the project as its maintainers.

After long and hard internal discussions, we have decided to release TinyMCE 7 under the GNU General Public License Version 2 or later, abbreviated as GPLv2+. Our intention with this move is bringing a fair balance among the project stakeholders: those who benefit from it and those who maintain it.

• TinyMCE celebrates its 20th anniversary this year. By software standards it is an incredible feat, and it would likely not have been possible without the open source community and adoption into projects like Wordpress and Mambo/Joomla.
• The project’s longevity also comes from it being commercially funded from the get-go. TinyMCE is a very feature-rich and complex software used by some of the biggest brands and organizations in the world. As the editor has grown in popularity, so have expectations on features, support, security, stability and longevity.
• TinyMCE is built and maintained by Tiny. It has a passionate and dedicated team spread over 20 countries on almost all continents. This team maintains TinyMCE, its integrations and several other supporting initiatives like the Tiny Cloud, Tiny Drive and Moxiemanager.

Our commitment to open source

We wholeheartedly embrace open source. Maintaining TinyMCE's high quality for over 20 years has always been a key priority for us. Our conviction is that open source software should offer benefits across the board:

• For a maintainer, open source enables fellow developers to help out with development, fixing bugs, writing documentation, performing testing and QA and building an ecosystem around third-party integrations and solutions.
• For a developer, open source allows access to the source code to inspect, modify and enhance the software according to their needs, to use it for free forever without royalties and to share it with others.

We are not a company who has open sourced an internal technology we’re using ourselves. Tiny as a company lives solely on selling commercial licenses of TinyMCE and its supporting products to others.

Developing a rich text editor beyond the very basics is also quite complex – that is why so many developers much prefer to use a product like TinyMCE instead of building it themselves. But it also makes it difficult for the open source community to help out with development and maintenance of the project.

This means that paying customers are carrying the vast majority load to the benefit of its open source users. It also means we from time to time have to evaluate and decide what and under which terms we open source our product to the benefit of the whole customer base – open source and commercial alike.

Moving to GPL

We believe moving to GPLv2+ will provide a clearer differentiation between commercial and open source use:

• It ensures open source use of TinyMCE and the value it provides remains free to use, modify and be distributed under equal terms.
• It provides a fair relationship between commercial parties ensuring ongoing usage directly supports the sustained development of top-quality features, maintenance, support, security improvements, accessibility improvements and other essential aspects expected by a professional development team.

What if you can't move to GPL?

We always have the commercial license available if the GPLv2+ license is not meeting your requirements. Read more about your options over at our website

What about older versions?

Older versions of TinyMCE remain under their original license. We will continue to issue security fixes for the open source version of TinyMCE 6 for some time to give you time to consider the upgrade to TinyMCE 7.

[ssddanbrown]

I completely respect your right to license your work how you wish, and I thank the whole TinyMCE team & contributors for all the value provided up to this point.

This move will naturally put a lot of projects in a challenging position though.
Personally, I'll face this with my project BookStack.
While I could also change my license to be compatible, that is a significant change that I'm not comfortable forcing upon my user base.
Right now I'm thinking my main foreseeable option would be to maintain a custom fork, likely trimming all unused functionality to reduce maintenance cost, although this is still a significant daunting prospect.

[mikkorantalainen]

It's also worth understanding that if you have any dependencies in your existing open source project licensed as MIT or similar permissive license, you may not be able to switch to GPL because your other dependencies may not be compatible with GPL even though those are compatible with MIT.

[ThiefMaster]

One thing I really dislike is that you seem to treat self-hosted as a second-class or "only for enterprises" citizen.

On your website you only directly sell licenses for the cloud version, with all the privacy implications that come with such usages. The only way to even get a license for self-hosted is to contact you/sales - that usually implies a very high price, and it's in any case a hurdle because now you have to interact with people can cannot just "click and pay".

I get it, you probably want to avoid certain large companies (website/webshop builders and similar) using your software for free and making (lots of) money from it. And if you are a commercial company and use TinyMCE e.g. to write HTML emails to customers, then it makes sense to pay for it.

But even if we as open source maintainers would be willing to pay for a license (certainly not at the currently published pricing though, at least purely private FOSS developers will not spend 50-100 bucks a month for this), anything based on number of users (or in your case "editor loads") is basically unlimited risk since anyone can install and use the application. Not to mention that the domain restriction also would not work for something people can freely download and install.

Maybe you could consider providing some decent way for non-GPL FOSS to get a free license for the core functionality, if the project clearly has no commercial intent? Sure, it's a bit more work for you, but it'd solve most of the issues. At least if it's done properly, ie in a very informal way - not requiring signatures on documents, being restricted in how you can publicly voice your opinion about the software, etc.). - then I think it would solve the problem for everyone.
Yyu could even go for something like "you're allowed to use it in a permissively-licensed project, unless you provide commercial SaaS using it". Going a bit in the direction of BuSL, FSL, etc. And someone who wants to provide such commercial offerings using the open source software including TinyMCE could then of course buy their own license and use that instead of the "non-gpl-foss" license key that'd be used by default.

[earlh]

Hi folks --

Do you have any plans to support version pinning or integrity hashes on the hosted version?

[TheSpyder]

Our cloud supports pinning, the deployment guide describes how to do it:
https://www.tiny.cloud/docs/tinymce/latest/editor-plugin-version

[earlh]

I don't see the word pin even appear on that page. All I see is the ability to subscribe to a channel, and a description of how you update the release on that channel.

Am I misunderstanding?

[TheSpyder]

"specify editor version" is the same thing as pinning?

[mikkorantalainen]

I think pinning was more along the lines of SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

[TheSpyder]

Our cloud is a SAAS product and that design doesn't allow for SRI, each channel is automatically updated with every new editor version in that major release.