Move to GPL 2+ #991
This issue is a follow up to an internal discussion where we agreed to set the Open Source license of CKEditor 5 to GPL 2+ only.
Our main intention with this move is bringing a fair balance among the project stakeholders: those who benefit from it and those who maintain it.
Who maintains CKEditor?
To bring clarity to it, let’s introduce CKSource - the company that maintains CKEditor.
CKSource is located in Warsaw, Poland. It’s a beautiful company that I started in 2006 with the objective of continuously developing and maintaining CKEditor. It has a modern and future-oriented team made of 40+ top-quality professionals.
As the maintainer of CKEditor, CKSource accumulates the following accountabilities:
Yes, it’s a lot of work to keep a high quality and successful Open Source Software going. All this done by the hands of the best developers and professionals you can find in the market. We’ve been doing this for more than 15 years already.
Who benefits from CKEditor?
Unlike many other Open Source maintainers, and because of CKEditor’s nature, CKSource does not benefit from CKEditor directly as an end-user or integrator. The ones that enjoy CKEditor are the companies that adopt it, who we call “the community”. We’re talking about hundreds of thousands of companies and millions of end-users.
By today, CKEditor must have hit more than 20 million downloads, historically. The great-great majority of those using the editor do it for free, enjoying the benefits of our wide GPL+LGPL+MPL triple license.
From these thousands of businesses and millions of downloads, a very small group (less than 0,5%) decides to enter into business relations with CKSource. They search mainly for support and better commercial licensing conditions. In some sense, these are the ones that finance CKEditor so the great majority can enjoy it for free. We should be all thankful to them.
We believe in Open Source. So much that we’re one of the few pure OSS projects that lasted that long. Of course, keeping the high quality of CKEditor has been always a decisive factor. Open Source Software should bring benefits to everyone:
Those who benefit from CKEditor are enjoying it in full. We’re very happy and proud about it.
On the maintenance side though, CKSource has been alone for these many years. The one part where the community has been active is on reporting issues. We’re grateful for that as it played an important role in keeping the quality of CKEditor high. Another part, where the community has shown a great potential was the CKEditor 4 addons repository, where we saw plugins being created by users, however here we observed a tendency that the more complex the plugin was, the more often it was commercial.
When it comes to contributions though, apart from a few heroes that show up sporadically with small fixes, we don’t see much. At the same time, there are always those who press us for free support, and rant about issues they found, and are very persuasive when it comes to their opinions. Thankfully, that’s a small group.
We completely understand the specific nature of CKEditor. It’s a component which is used inside much bigger applications. Those who come for CKEditor don’t have much time to think about it (let alone contribute to it). They have much bigger projects to think about. They just want CKEditor to work, period.
But sincerely, we’ve always been fine with all that. We’ve found financial ways to make it happen and we were happy to create top quality software and make it available to everyone without asking for anything in return.
Moving to GPL only
Although we say that we’re fine with the current situation, we need to make changes:
Taking all the above into consideration, the GPL (version 2 or later) seems to be our best option:
I can’t go with GPL!
There will always be the commercial license for CKEditor 5 available for you, if the GPL is not an option, which we understand may not be in most of the cases.
So there’s no disaster with this change. It’s the same software, with the same quality. One would just have to pay for it and we believe that there’s no shame for being paid for the hard work we put into producing and maintaining the software.
More information about the commercial license options can be found on the CKEditor website.
What about CKEditor 4?
We decided that keeping CKEditor 4 on the current GPL+LGPL+MPL triple license is the best option we have. There are already way too many solutions out there that depend on it so a change on the license could be too drastic. That’s why we’re going GPL with CKEditor 5 only.
The text was updated successfully, but these errors were encountered:
Free for Open Source Software
I have to recognize our mistake, of not having clarified in this proposal how we want to handle Open Source Software in general. My apologies. We had way too many things on our shoulders and we still didn't put every piece in place.
We had a final conclusion: we want to support Open Source Software, just like we always did. Therefore, our plan is providing a free license for Open Source Software, as long as they meet a few conditions:
This is a well-established model with many companies already providing the same terms. No surprises them and no limits for our Open Source folks.
We're before a whole week of holidays and we gonna still implement all the above on our website but feel free to contact us at any moment if you want to talk about this or participate into the OSS program.
Sorry again and I hope this will work for all you guys. Thanks!
I completely understand your reasoning here, but to me this is effectively a capitulation to a very negative trend. You're good people, and I've seen that through numerous interactions before, so please don't take this as a personal attack - I am just sharing my philosophical perspective, and practical suggestions.
Theoretically (and literally) you're still Open Source. But in practical terms, the product won't be an Open Source solution anymore - because a regular Open Source component (read: library) would be at worst on LGPL. For anyone not on GPL2-compatible licenses, which many projects aren't on, you aren't usable anymore.
Anyway, the trend...
The trend is for Open Source (a grassroots movement against corporate software) to be co-opted by the corporate ecosystem. The level of complexity is significantly raised by VC-investment (which I assume you have had), such that casual contributors can not realistically add to the project. This is something I saw myself, when I tried to contribute something to what I saw as the standards of the project at the time, but came across a higher set of standards than I could realistically meet for an initial commit. So that's one big reason you're not seeing contributions. Then the original organisation behind the project turns into just another enterprise provider, with a high-participation cost (license fee / complexity / OSS-licensing-prescription), very distant from the origins.
We of course want to push the quality of Open Source solutions higher. I always used to bring up how un-user-friendly just about every Open Source applications GUI is, while Open Source puritans were blind to it and constantly claimed Linux was about to have its "year of the desktop". But look at what the effect this has been since back then, since VC/corporate-money changed the nature of Open Source, taking Google as our example:
I think this recent move with CKEditor is another example. You have practical concerns, but those concerns, with the money associated with them, have pulled you away from the roots. Now it is more important to provide a ultra-quality product to corporate customers and a common-denominator of consumer than it is to provide a good-quality product that can serve as a part of the grassroots Open Source community (meeting their practical needs). Some of the original values, and value, has been lost. Different to the values in my Google example, but still some of the fundamental ethos we all came from.
Foundational values and ethos need to be maintained, otherwise continued slippage will happen. At some point CKEditor will be bought out by someone bigger like Atlassian, and then the next phase of slippage would be the Open Source version being discontinued completely.
The way we license my company's product to defend against some existential risk of working in the Open Source space, is CPAL. It's a different situation to you, but I think underlying motivation still applies. In our case we use CPAL to force any fork to credit my company as the originator of the product - so that the value nexus isn't pulled away from the investor, and thus we still have ways to drive revenue. In your case you could just do something like a "powered by CKEditor - free license" bar at the bottom of the editor that a CPAL-like (attribution-based) license would allow you to enforce to be there. Then downstream projects could simply tell users "well, if you don't like it, you have to pay CKEditor to have that removed". Having some forced credit doesn't hurt grassroots communities, but I believe does work as an effective way for an investor to maintain its interests when deriving revenue in the corporate space - because corporate players are going to be embarrassed by their editor saying something like that, because they're working on a distinct common-denominator consumer-supplier paradigm, totally unlike a grassroots paradigm. If I were you I'd have gone with CPAL instead of GPL2 (as then you can encourage a much bigger set of freeloaders to pay via the same attribution clause) - but you could go with CPAL+GPL2.
I think there's no good solution for encouraging more contributions really, I think that is inevitably lost as things progress. Sad, but the reality of any maturing industry.
In summary - I hope you consider what I say on the importance of not letting Open Source be (in practice) co-opted as a corporate affair, and keep a strong foot in the grassroots community. I don't think GPL2 does that in practice, I do think CPAL does.
And in closing - there's practical reason to keeping a strong foot in the Open Source community. With time, new competitors, or forks, will emerge. It's the same reason that capitalist countries need to keep the poor happy - otherwise a reset will happen that will wipe the board clean.
@fredck glad to hear you guys are thinking of a solution for other OS projects and look forward to the clarification on your site. I'm not a lawyer myself so not completely sure of the legal ramifications, but I am skeptical about the idea that you can license it differently to other open source projects.
Lets say my project meets the requirements stated. Your license would allow me to distribute ckeditor5 with my OS software without imposing gpl copyleft on my software, but doesn't the main gpl license still apply to consumers of my software packages, who may build things on top of my project that includes non OS code of their own? Would they not be in violation?
This is possible, just like we can issue a commercial license for commercial customers, as copyright holders.
Nope, the GPL license restrictions will not apply to consumers of your software, that's the goal after all with allowing CKEditor to be included in OS applications licensed under different terms. As @fredck wrote we need to work on it further, but I believe we have a good solution for the problem raised here.
CKEditor developers are looking for some reasonable recompense given the vast usage of CKEditor by penurious corporations and developers: Given that the issue here is money, is there room or interest in a bountysource/indiegogo campaign for CKEditor 5 to be released back into a non-viral license?
The viral license is quite restrictive for UI Web components -- we all know that -- and this a long standing core component, one which we'd all hope does not have to see a fork from its earlier multi-licensed branch. As an individual developer who has burned a hundred grand of his own capital (don't worry, I've burned other people's money too), I very much sympathize with the CKEditor developers in their desire to see some return on their investment. Best of luck to all parties!
@fredck Glad to hear that! I cannot force users of my open source software to pay for part of the system or force them to use GPL license.
Even if it may be mostly psychological, I expect the monthly licensing model may prove a barrier to adoption for a lot of solo developers and small teams. Aside from this direct issue, there's a more pernicious knock-on effect as it leads to a loss of mind-share for CKE in general, when such developers move on to join larger teams and take the experience of using whatever else they've become familiar with to their new roles instead of CKE.
As an example, say someone is looking to use an RTE in a bootstrapped commercial project. It might take 6 months to a year to develop, and another year to get to 50 users. With the current CKE5 pricing model, they'd need a license from day one of development. This can be a non-starter for someone who is unsure of the success they'll see in the market.
Offering a free license for maybe five or ten users/month would allow aspirational developers to develop their apps and get to a small base of users (when they start to breathe easier about having external costs) without the overhead of a monthly license from the outset. Essentially, this would defer the decision to pay a license fee to a later date, when the worry of whether or not their project will succeed has been mitigated.
I run commercial software - website building platform, and we use Froala. We use commercial license. It is 900$ perpetual license with 1 year of updates. If I want - I can pay for another year of updates. And it is not problem.
@demkinmaxim, the online offer takes into consideration a group of use cases. The reason we have an option to "Contact us" is exactly to allow us to better understand your specific situation and come with a solution that fits your expectations. So please don't take misleading conclusions and feel invited to contact us.
That's a very important point, btw. Please don't underestimate the importance of the text editor. As a creator of a website building platform, I'm sure that you understand that the text editor has an important role in your application. We've seen countless solutions where the attention to this important part is not appropriate and the results are disappointing.
But of course, feel free to go with the option that fits your requirements better and I'm not here in any way trying to undermine other editors. From our side, we can just promise you that we're doing our best so CKEditor is not "just a text editor" ;)
I do not really understand.
As long as there is no distribution of binaries, there is no problem with using GPL libraries (or other code) in an otherwise closed-source project.
As far as the regular GPL and LGPL are concerned, providing access to use a software over a network (like in SaaS or websites) is not considered distribution. This means that there is no problem with using (L)GPL libraries in a closed-source SaaS project.
I think most of uses of CKEditor happens on SaaS software or websites and these use cases are not considered distribution. So I do not really understand the change of licensing but maybe my interpretation of the GPL v2 is wrong ...
The fact is that it seems to be no final word and consensus about the legality of mixing GPL into software that is made available as websites/SaaS. There are those bringing interpretations to allow for it (usually GPL software consumers) and those bringing arguments against it (usually GPL software producers).
As situations like this bring doubt, when analyzing the legality of a specific case, there will be a strong emphasis on understanding what are the intentions of the copyright owner (licensor). In our case, as explained in this issue, there is a clear intention, and I confirm it, of allowing CKEditor under the GPL license only within software that is also GPL, no matter which way such software is made available for end users.
Another important aspect to consider is that CKEditor is a "component". It is not a complete software that can be delivered as a website, like a CMS for example.
Let's take Drupal and WordPress as examples. These are GPL software and you create websites with them. You're not integrating Drupal/WP into anything else when delivering such websites so there is no doubt whether you can integrate it with... well... with what?
Take CKEditor now. One will be always assembling it inside another software and then delivery the resulting product into a server making it available as a website. For that to happen, that another software must be GPL as well.
The above are examples of different kinds of GPL software and the legal interpretation must almost certainly be different for each of them.
Anyway, summarizing, we could start a long thread of discussions about this topic, manipulating words from license terms to justify opposite argumentations (I'm not saying that you're doing so). But at the end of the day, our intentions as licensors are decisive to solve any doubt and I hope to have them clarified with this comment.
@fredck Thanks for taking the time to clarify. I really do not want to undermine the work of all of you at CKSource. You really are doing an unbelievable work
I was truly excited by CKEditor 5 but with theses change of licensing, it is really a no go on my side. Even though I chose to publish my source code on an OSS license, I would certainly not choose GPL v2. Beside that, your commercial pricing scheme is clearly not accessible to indie developers (a monthly fee based on the number of end users
From what you say, it seems indeed that the AGPL would be much more clear and not subject to any false interpretation.
If you plan to release your project on an OSS license, we will be most happy to license CKEditor 5 for you for free. Please contact us to discuss it and we'll be glad to have you on board! This is already reflected on our pricing website, with the big "Free for Open Source" banner
@jtraulle The gpl don't mention binary at all. It talks about "program", and the program in this case is ckeditor which is distributed to anyone who visit your website.
So any modifications to ckeditor, or plugins you write to ckeditor will also have to be released to all your users under gpl.
Yeah, I continue to think that the GPL is not really appropriate because of the wide interpretation (especially regarding what is considered distribution ; this is because of this if AGPL is born : see https://www.gnu.org/licenses/why-affero-gpl.en.html) . I'll stick with the 4.x branch for now and I'll see in the future if I am ready to switch under the licensing terms stated ... or consider other options
@fredck you said:
Did this change at all?
Please note that CKEditor 5 is still Open Source, just the license under which the editor is available has been limited to GPL. That's why you still see the editor on GitHub and in CDN ;) The fact that it's easily available online does not mean of course that one can freely use it without caring about anything. If you use CKEditor 5 you have to be sure you meet all the requirements of the GPL license (or purchase a commercial license),
Because of being GPL-licensed, CKEditor 5 will not fit out of the box other Open Source projects which are licensed under an incompatible license (e.g. it's impossible to mix a GPL-licensed software in a MIT-licensed project, without making the whole project GPL). Therefore we started the Free for Open Source initiative, where we grant a dedicated non-GPL license to projects that would like to use CKEditor 5 and are Open Source.
If you have any particular questions, please feel to contact us (https://ckeditor.com/contact).
* Feature: Added the image upload button to the build. See ckeditor/ckeditor5#870. * Internal: Build. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v1.0.0-beta.1. * Internal: Updated links to CKEditor 5 website. [skip ci] * Docs: Typo in README fixed. [skip ci] * Removed duplicated "ImageUpload" plugin. * Internal: Updated dependencies. * Tests: Added manual tests for translating editors. See ckeditor/ckeditor5#914. * Internal: Build. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v1.0.0-beta.2. * Fix: Translations should work when CKEditor was loaded using RequireJS. See ckeditor/ckeditor5-dev#914. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Build. * Release: v1.0.0-beta.3. * Docs: Fixed link in the readme. [skip ci] * Docs: Mentioned previous release in the changelog. [skip ci] * Internal: Updated keywords. [skip ci] * Internal: Build. * Internal: Fixed keywords. [skip ci] * Internal: Improved license file. * Docs: Changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v1.0.0-beta.4. * Other: Changed the license to GPL2+ only. See ckeditor/ckeditor5#991. BREAKING CHANGE: The license under which CKEditor 5 is released has been changed from a triple GPL, LGPL and MPL license to a GPL2+ only. See ckeditor/ckeditor5#991 for more information. * Internal: Updated dependencies. * Internal: Build. * Docs: Changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v10.0.0. * Docs: Changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v10.0.1. * Adjusted code to the changes in ckeditor5-editor-classic. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Build. * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v10.1.0. * Switched to email@example.com and UglifyJsWebpackPlugin. * Switched back to banner with exclamation mark. * Webpack up. * Bump, bump. * Hide unnecessary warnings. * Improved comments. * Internal: Upgraded version of Node.js. See ckeditor/ckeditor5-dev#417. * Docs: Improved the package description. * Docs: Improved keywords and the readme. [skip ci] * Internal: Aligned code to changes in ckeditor5-core. See ckeditor/ckeditor5-core#140. * Internal: Build. * Other: Changed the build structure. TODO. Closes ckeditor/ckeditor5#1038. * Internal: Build. * Internal: Build. * Internal: Build. * Internal: Build. * Internal: Build. * Removed unnecessary comment in `webpack.config.js`. * Internal: Further builds simplifications plus some comments. * Internal: Build. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v11.0.0. * Internal: Build. * Internal: Build. * Docs: Changelog. [skip ci] * Internal: Build. * Release: v11.0.1. * Docs: Changed links to documentation. See ckeditor/ckeditor5#1192. * Internal: Upgraded dependencies. * Docs: Changed links to documentation. See ckeditor/ckeditor5#1192. * Upgraded version of ESLint. * Added build screenshot to README.md. * Added Media Embed and Table features to the build. * Internal: Build. * Tests: Updated build tests to the new toolbar configuration. * Internal: Build. * That option got renamed in the meantime. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v11.1.0. [skip ci] * Docs: Fixed invalid merge in the readme. * Docs: Changelog. [skip ci] * Internal: Build. * Release: v11.1.1. [skip ci] * Docs: Made contributing guide link to our docs. [skip ci] * Feature: Introduced the Paste From Office feature. * Feature: Introduced the CKFinder integration plugin. * Internal: Build. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v11.2.0. [skip ci] * Introduced a linter and Travis. * Added a configuration for ESLint. * Directory created by Mgit on CI must be ignored as well. * Code style in tests. * Update raw-loader dependency. * Aligned Travis configuration after switching to Yarn. See ckeditor/ckeditor5#1214. * Docs: Added build status badges to the README. See: ckeditor/ckeditor5#1236. * Fixed formatting in Travis configuration file. * Updated deps. * Add memory leak test. * Add missing ckeditor5-core dependency. * Internal: Bumped the year. [skip ci] * Upgraded version of husky. * Other: Upgraded minimal versions of Node and npm. See: ckeditor/ckeditor5#1507. * Internal: Updated deps. * Internal: Build. * Internal: Build. * Docs: Updated the homepage link. [skip ci] * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v12.0.0. [skip ci] * Internal: Removed unnecessary and added missing deps. * Internal: Introduced Slack Notifications for this repository on CI. * Internal: Build. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v12.1.0. [skip ci] * Internal: Changed a way how to install Chrome on Travis. [skip ci] * Internal: Updated the license header. See ckeditor/ckeditor5#1557. [skip ci] * Internal: Build. * Internal: Updated license section in README. See ckeditor/ckeditor5#1557. [skip ci] * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v12.2.0. [skip ci] * Removed BrowserStack from the repository. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v12.3.0. [skip ci] * Internal: Ping CI. * Internal: Bumped up deps. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v12.3.1. [skip ci] * All tests require an image that exists. It will not cause the 404 error. * Bumped style-loader to v1.0.0. Aligned the webpack config to the new loader API. * Bumped up raw-loader, uglifyjs-webpack-plugin, webpack, and webpack-cli dependencies. * Internal: Build. * Internal: Build. * Other: Changed the URL under bugs key in package.json file. Now we have one issue tracker. See ckeditor/ckeditor5#1988. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v12.4.0. [skip ci] * Internal: Make CI green. * Docs: Removed gitter badge. See ckeditor/ckeditor5#2037. [skip ci] * Internal: Upgraded CI environment to use Xenial version of the distro. See ckeditor/ckeditor#2041. * Feature: Enabled the indent feature in the build. * Internal: Build. * Tests: Updated the test. * Internal: Build. * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v15.0.0. [skip ci] * Internal: Make CI green. * Internal: Updated the GitHub PR template because all packages share the same issue tracker now (see ckeditor/ckeditor5#5576). * Internal: Enabled stylelint in the package. * Internal: Allowed empty input in the stylelint script to avoid errors when no files are found. Added missing stylelint-config-recommended dependency. * Internal: Added the stylelintrc config. [skip ci] * Used the external stylelint-config-ckeditor5 package for stylelint configuration. * Replaced UglifyJS with Terser. * Internal: Build. * Internal: Added a missing pacakge dev-dependencies. See ckeditor/ckeditor5#5856. * Internal: Made the error initialization catch statements more informative. * Minor improvements to error messages used in manual tests and a sample. [skip ci] * Docs: Changelog. [skip ci] * Docs: Corrected the changelog. [skip ci] * Internal: Updated dependencies. [skip ci] * Internal: Build. * Release: v16.0.0. [skip ci] * Internal: Make CI green. * Internal: Added blog post URL. [skip ci] * Internal: Fixed blog post URL for the 11.0.0 release. [skip ci] * Internal: Added config for package.json to .editorconfig. See #318. * Internal: Bumped the year. [skip ci] Co-authored-by: Piotrek Koszuliński <firstname.lastname@example.org> Co-authored-by: Kamil Piechaczek <email@example.com> Co-authored-by: Anna Tomanek <firstname.lastname@example.org> Co-authored-by: Maciej Bukowski <email@example.com> Co-authored-by: Aleksander Nowodzinski <firstname.lastname@example.org> Co-authored-by: Damian Konopka <email@example.com> Co-authored-by: Maciej <firstname.lastname@example.org> Co-authored-by: Marek Lewandowski <email@example.com>