About that Craft License
Recently we’ve received a few questions about Craft’s license agreement, and we thought this would be a good opportunity to explain some of our thinking publicly.
When we set out to make Craft, we started with a goal: we wanted to make the best possible CMS for the widest range of sites. Sure, we all like to think that we can choose the “right tool for the job”, but the reality is that very few of us actually have the time to master more than one tool of this scope. So we felt it was important for Craft to be the right tool for the most types of jobs.
Every decision we’ve faced while working on Craft has been decided with that goal in mind, from our business model to Craft’s feature set to the license agreement.
Undeniably, a big part of what will make Craft the best CMS out there is a thriving plugin ecosystem. If you’ve had a chance to dig into Craft’s plugin APIs, you probably already have a sense of just how important that is to us. An extraordinary amount of effort has gone into making Craft as plugin-friendly as possible.
In the interest of making Craft the best CMS ever, we felt that it was important to place some basic limitations on what plugins can do, however. For instance, you can’t write a plugin that is destructive, deceptive, or otherwise malicious in nature. You also may not write a plugin that makes use of undocumented APIs. The reason for that is stability: if we haven’t documented something, it’s subject to change without warning, and if a plugin were to be using that API, it would break. We don’t think that “the best CMS” would ever release a minor update that intentionally breaks plugins, so we feel this restriction is pretty important.
The third restriction states that a plugin cannot replicate features that are already provided by Craft (either in the core or in one of its packages). There are a couple reasons we decided to add this one, and I’ll cover both.
Firstly, we’ve seen other add-on ecosystems become rampant with plugins that replicate core functionality, for no good reason other than that the developer didn’t realize the feature was possible out-of-the-box to begin with. Of course if someone doesn’t know that a feature already exists, they won’t realize that they aren’t supposed to write the plugin in the first place. But if they are at least aware of the license restriction, we hope they might be encouraged to do their due diligence beforehand.
The second reason requires an understanding of Craft’s business model. If you’re unfamiliar with it, the gist is this: we give the core features away for free (tailored for building a personal blog or portfolio), and there are a few extended feature packages available for purchase within the app. The idea is that the cost and functionality of Craft can scale with the scope of the site.
We think it’s a pretty clever and fair approach, and our customers seem to agree. But it puts us in a position where if you need content translations, etc., it is critical to Craft’s success that we are the only people who can sell you that feature. If someone else were to come along and write a Localize replacement plugin, even if they never were to release it publicly, they would be able to use that to save paying us $299 for every localized site they build.
Another key point to make here is that each of Craft’s package-added features are built right into the core, and packages really just enable them on the UI level. So it would actually be quite simple for a plugin to “replicate” all of the packages’ features, by harnessing all of that code that’s already built into Craft.
With all of that in mind, we felt it was necessary to add that clause to the license agreement. Yes it may hinder a little competition and innovation in certain areas within Craft, but that’s the tradeoff we had to make to give Craft sensible and fair pricing, while making it economically viable for us – ultimately putting Craft in a better position to compete with other CMS’s in the market.
Craft’s license agreement, just like Craft itself, is currently at 1.0, and capable of changing. That is to say that we’re open to continuing the discussion, and will take all suggestions seriously. We just think that any reasonable debate is going to take into account our goals for the product and where we’re coming from.