PW3 core licence change from GPL2 to MPL2

[Ivan Gretsky]

In the comments to the latest PW blog post Teppo noticed the licence change that seem to be present in the new 3.x branch of ProcesswWire. It has changed from GPL2 to MPL2. What does this switch means to us?

Earlier Ryan said that he is not so much into legal matter and just goes along with the big players like Wordpress and Drupal in the field of licencing, Obviously that is no longer the case.

I am no expert in this matter, but as I can guess MPL2 will allow to produce a commercial version of PW to exist alongside with a community one.

I am starting this topic to find out about what real difference the licence change will bring and to find out about the core development team plans concerning future of PW development.

[ryan]

This was going to be a topic for next weeks blog post, but maybe better here so I definitely welcome any feedback. The biggest factor is that PW is as much of an application framework as it is a CMS, even more so in PW 3.x. We can't be taken seriously as a framework on GPL v2. So we need to start licensing it like a framework, otherwise we risk projects excluding us on that basis. For instance, most frameworks (like Laravel) are licensed under MIT, as is jQuery. There's no plan for a commercial version of ProcessWire. I've already been there, that was Dictator CMS and ProcessWire 1.0, and not going back. We're wanting to go more open in order to gain wider adoption for the product, as well as just do the right thing for the community and best support the projects they build with PW.

Following the old legacy CMS projects on license seemed to be a safe way to start, but now we seem to be the only new player using a license that preceded the existence of CMSs. So another factor is that, as we grow, that has been leaving too much ambiguity about where and how folks can use PW, and I'm aware of a recent big project that wanted to, but didn't use PW for that reason. I'm tired of that ambiguity and having to outline our interpretation, and what PW is and isn't. I'd rather the license did that for us and made people feel comfortable about using PW even if they don't totally understand what the product is. People that don't understand what PW is might interpret the license in such a way that they think anything they develop in PW (like their own web sites, templates and modules) has to also be GPL v2. This is false, and I'd like to get rid of that ambiguity. 

The MIT license is the most open and simple one, which I really like. But we've got a couple components (notably CKEditor) that won't work with that. So my thought was to make most of the PW framework MIT, but use MPL 2.0 for the bigger picture. The MPL 2.0 (Mozilla Public License) is a modern license that enables us to support much of the spirit of MIT while also being compatible with existing components like CKE. In terms of openness it sits in between MIT and GPL. From a framework perspective, it still lets you link any part of PW with applications under other licenses, which is what a framework must support. Under GPL we are only able support that linking with other code via modules and templates (the components PW is specifically designed to run) and that's just not enough to be taken seriously as a framework. There are other licenses like LGPL that might let us accomplish this too, but I still find LGPL too ambiguous for my taste, whereas MIT and MPL 2.0 seem to outline exactly what we're trying to accomplish as both a framework and CMS.

[teppo]

Thanks for clarifying your intentions on the switch, Ryan!

While FSF has a great goal in mind with GPL, making sure that free applications stay free, I can see how that could be perceived as a negative thing by some. It's also obvious that it could make it more difficult to work with other, non-GPL code – whether proprietary or just under a license that is incompatible with GPL itself.

It doesn't really help that some other platforms, most notably WordPress and Drupal, have stated that in their case even the themes and plugins are always under GPL. While it should already be clear to most people here that they can create non-GPL – and non-open – modules and site profiles for ProcessWire, moving on to another license to avoid unnecessary ambiguity probably makes sense.

While I honestly hadn't considered a situation where someone would like to release a larger application based partly on ProcessWire under another (possibly proprietary) license, again from the framework point of view this does seem feasible. While I wouldn't consider it a typical use case by any means (and in most cases I would also advise against such move), in this regard the switch does indeed open new doors.

On a related note, once you push a change out there for everyone to see, the cat is out of the bag. Makes sense follow up with a swift explanation, like you just did here, though sometimes explaining such things in advance would be even better

[ryan]

It doesn't really help that some other platforms, most notably WordPress and Drupal, have stated that in their case even the themes and plugins are always under GPL. While it should already be clear to most people here that they can create non-GPL – and non-open – modules and site profiles for ProcessWire, moving on to another license to avoid unnecessary ambiguity probably makes sense.

Exactly, this seems to be a point of confusion for people coming from those projects. ProcessWire is an entirely different animal, but sometimes people incorrectly apply their understanding of those legacy CMSs to PW. PW core (/wire/) is entirely separate from PW site (/site/). I want to be clear that when you build a site or application in ProcessWire that you can license your original works within /site/ however you want. We have been clear on that, but need to go further. 

While I honestly hadn't considered a situation where someone would like to release a larger application based partly on ProcessWire under another (possibly proprietary) license, again from the framework point of view this does seem feasible. 

The trouble is some perceive anything (like your own website) built in ProcessWire to fit that definition. You and I know it doesn't, but someone new evaluating PW for their own sites/apps doesn't. 

On a related note, once you push a change out there for everyone to see, the cat is out of the bag.

The 3.x is a branch of experiments, and the truth is I'm not totally settled on it, but figured I could be by next week. I'm still looking at LGPL a bit even if feeling it's a bit too ambiguous. If people think there are other alternatives we should consider to MPL 2.0 all feedback is welcome and everything open to change. Also just want to be clear that we're not making a commercial version of PW, that has nothing to do with this so that's not among our needs.

[Ivan Gretsky]

Thanks for the explanation, Ryan. Clear, clever and polite as always. I thought that this could be related to Avoine new project on top of PW. And it is... but in a broader sense.

And I guess Teppo is right. For the sake of nurturing a devoted and confident open source community such questions should probably be debated for a while.

[apeisa]

I thought that this could be related to Avoine new project on top of PW. And it is... but in a broader sense.

Nothing to do with that. Sense product we are building is hosted Saas-application, no code distribution there.