Commercial modules and licenses

[neildarlow]

Hi,

Can I bring up a little issue that might be problematic regarding the fact that ProcessWire is licensed under the GPL Version 2.

This has implications for things like extensions in that the GPL may require them also to be distributed under the same license. The GPL affords users rights in how they use the software and permits them to enhance and, more importantly, re-distribute those enhancements. This is fundamentally at odds with making extensions commercially licensed and I would suggest that you clarify the position with the Free Software Foundation (Bradley Kuhn is a good contact for this).

I should also mention that introducing commercial extensions to ProcessWire may tempt others to do things like obfuscate code or require the use of module loaders to protect the commercialism of their extensions. If the GPL applies to extensions through ProcessWire then this is totally at odds with that license.

The introduction of commercial extensions to ProcessWire has inadvertently changed the nature of the project. Although you describe ProcessWire as Open Source it was actually provided under a Free Software license (there is a distinction) and now that statement only applies to the ProcessWire core and not these commercially licensed extensions.

I am in no way against people making money from Free Software/Open Source but it is important to realise that, when commercialism enters into a project, sometimes the initial choice of a Free Software license is not appropriate.

Regards,

Neil Darlow

[apeisa]

Good points Neil. It seems to be grey area in general whether plugins should inherit GPL or not. WordPress and Drupal are both GPL and they both think plugins as derivatives that should be GPL also.

Maybe more free license like MIT might be better fit without any grey area? Marketplace driven concrete5 has MIT.

[ryan]

I appreciate your concern, and I'll try my best to clarify.

I'm the copyright owner of all code used in these modules (FormBuilder, ProCache). I'm also the copyright owner of the module interfaces and the ProcessWire core. I make a point not to rely on any code I've not written personally or that other people have contributed to. But I think you are looking for clarification on a bigger picture, so I'll instead focus on others that might want to create stuff in ProcessWire. 

We do not require that all websites and modules produced on top of ProcessWire's framework be free, and I don't know of any tool like PW that does. What I don't want people to be able to do is turn ProcessWire itself into a commercial product or be able to change ProcessWire's license. But I do want them to be able to use ProcessWire in the manner it was intended. ProcessWire is intended and built as a platform to manage and execute modules. I do not support extending ProcessWire itself with anything but GPL v2, but I do support ProcessWire being used as the tool it was meant for, without restriction.

Years ago, in talking with other CMS developers for projects much bigger than ProcessWire, they'd suggested to use GPL v2 but make clear that the project encourages and supports an ecosystem that is not against commercial modules (which I've done on several occasions), so that there is no grey area. In fact, ProcessWire's API and architecture reflects this intention. When you build a site or module on top of ProcessWire, you are not extending ProcessWire--you are using it as a tool for exactly what it was designed for. 

For the sake of our users, I want to be clear that I consider a module running on ProcessWire no different than a website running on ProcessWire–they use the same API and in the same way. This architecture is intentional. And I certainly don't want people to think that their own websites, content, images, assets, etc. are GPL as a result of running on or being delivered by ProcessWire. For others making commercial modules, I am also okay with fees charged for 3rd party modules to be support/service/distribution fees rather than license fees (which is the route I like, though wouldn't require it). I don't support any kind of obfuscation though, and wouldn't list obfuscated modules in our directory. I need to be able to confirm that something is coded with attention towards security before I'd list it in our directory. 

[ryan]

Good points Neil. It seems to be grey area in general whether plugins should inherit GPL or not. WordPress and Drupal are both GPL and they both think plugins as derivatives that should be GPL also.

It does seem to be open to some interpretation. The intention is definitely to avoid the interpretation of platforms like WordPress because it seems to have contributed to a very low quality-to-quantity ratio of plugins. It's also segmented their customer base as there are plenty of commercial themes and plugins, but operating off on their own. Though we are a very different tool from WordPress, and I can understand why the WordPress folks interpret it that way in their context… but again the underlying purpose of ProcessWire is different from WordPress. With ProcessWire, I want to support the entire community and am hoping that in the long run this helps us maintain a stronger community and higher level of quality than there is with WordPress. Though don't get me wrong, I do respect a lot about WordPress and it's leadership and the way they've been able to grow. 

Maybe more free license like MIT might be better fit without any grey area? Marketplace driven concrete5 has MIT.

I like the MIT license, but didn't go with it just because I was concerned that others might take ProcessWire and turn it into a commercial project or somebody might start selling ProcessWire under another name. A couple years later now, I'm less concerned about that. Mainly I just want to provide what's best for the users, and I think GNU does that. But I do think it requires understanding what ProcessWire is and isn't. I don't see grey area myself. But if others do and it prevents people from using ProcessWire, then I would consider a more open license like MIT. That's assuming you would consider it for your work with InputfieldFile. You are technically our biggest core contributor. 

[Pete]

Years ago, in talking with other CMS developers for projects much bigger than ProcessWire, they'd suggested to use GPL v2 but make clear that the project encourages and supports an ecosystem that is not against commercial modules (which I've done on several occasions), so that there is no grey area. In fact, ProcessWire's API and architecture reflects this intention. When you build a site or module on top of ProcessWire, you are not extending ProcessWire--you are using it as a tool for exactly what it was designed for. 

For the sake of our users, I want to be clear that I consider a module running on ProcessWire no different than a website running on ProcessWire–they use the same API and in the same way. This architecture is intentional. And I certainly don't want people to think that their own websites, content, images, assets, etc. are GPL as a result of running on or being delivered by ProcessWire. For others making commercial modules, I am also okay with fees charged for 3rd party modules to be support/service/distribution fees rather than license fees (which is the route I like, though wouldn't require it). I don't support any kind of obfuscation though, and wouldn't list obfuscated modules in our directory. I need to be able to confirm that something is coded with attention towards security before I'd list it in our directory. 

I think this is what it all boils down to. The API actually means you're not altering/editing/refactoring any of the core code of ProcessWire. All modules simply leverage the functionality of the API rather than modify the codebase and I think that helps you get out of those grey areas.

Section 2 of the GPL is where a lot of confusion stems from I think, but it refers to modifying the core program (ProcessWire) and your modified work then needing to be licensed under GPL rather than modules.

I think these two paragraphs definitely apply to modules since they don't alter core code or copy core functions, but are in fact original works that simply reference the API functions so are exempt from section 2 as far as I can tell:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of

this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

The way I've read this, you aren't required to distribute commercial modules with a GPL2 license and actually shouldn't otherwise others can redistribute them freelyunder GPL2. Looking at the FormBuilder module readme.txt file ryan has wisely not distributed it under GPL. In fact after looking at the code he has gone to some lengths to ensure that all code for FormBuilder is packaged with that module and isn't borrowing bits of code from the source of ProcessWire itself, so as with other modules it simply interfaces with ProcessWire via the API and leaves the source alone.

Going back to the last paragraph I quoted at the start of my post, ryan is also quite correct in that you use the API not only when building modules, but also when building the templates for a website and you are not expected to have to redistribute your website under GPL so I don't think it necessarily applies to modules either since you are using the API the same way in both instances (for those that don't know, you could easily recreate the functionality of some modules inside templates and the code would be identical in places - it's just neater having large chunks of code in modules where appropriate).

I think my train of thought has arrived at the station. Not sure it all made sense, but from what I understand ryan has been quite clever with the API in that it grants quite a degree of flexibility when it comes to custom modules and licensing.

[ryan]

Good points Pete. Admittedly, the way that Form Builder is built is really more about being platform independent than anything about the GPL. I had thought I might get Form Builder running on another CMS like WP or EE. I thought this would increase the audience size and increase visibility of ProcessWire. I don't think I'll end up doing that, but just wanted to have it ready for it. I don't think that other people's future commercial modules need to take that approach unless they want to. 

[apeisa]

Ryan, for me personally it doesn't matter. MIT is much easier to understand than GPL. I also agree with you that "risks" with MIT are pretty close to zero: if someone wraps PW in commercial version and tries to sell it => the original and open source would still be there. And in current logic I could add few modules, admin theme and site profile and bundle them as a commercial CMS, build on top of the ProcessWire CMS/F.

But as long as it is clear for everyone what is ok and what is not - then all is good. I feel that GPL and modules/plugins are hard thing. Of course there is a huge difference between ProcessWire and WP & Drupal -camp, since those especially see modules as derivatives - and you especially state that in ProcessWire modules are clearly independent from core (or tools build with and for ProcessWire, not build by modifying or extending PW).

I also think that the current way to go seems ideal to me: free and full featured core, where people can build open source or commercial modules for specific needs.

[ryan]

MIT is much easier to understand than GPL.

It's easier to read. But my opinion is that it's also difficult to understand where it could lead. With GPL you know you are protected from some big corporation coming in and taking over. It keeps others from exploiting ProcessWire's core in ways we can't predict. Profit motives are limited to what you create with or for ProcessWire, rather than what you do to it. ProcessWire's core remains protected. I'm not saying I'm against MIT, and always think that going "more open" is good and worth considering. I'd love to talk to the Concrete5 folks to gain insight on their choice. But we should never be motivated to change the license because someone misunderstands ProcessWire. We should only be motivated by what's ultimately best for the project and users. Currently I think GPL is a great and safe fit for us. Though I also understand the GPL always opens questions wherever you take it. So it's important for project leadership to answer those questions and be clear so that there is no grey area. I think that's what we've done. Though I always invite more questions. 

[Joss]

I always liked the MAM licence.

Its "Mine!!! All Mine!!!!

Otherwise known as "precious".....

[Samuel]

@Joss Go for the DBAD "license"

Well why not upgrading the GPL to Version 3.

http://www.gnu.org/licenses/rms-why-gplv3.html

Edited March 20, 2013 by ryan
Replaced fully quoted article with link to article

[ryan]

Well why not upgrading the GPL to Version 3.

I read the article about GPL v3, just to make sure I hadn't missed anything before. But it's not clear to me why we would want to use GPL v3? (at least doesn't seem like any changes that matter to ProcessWire). 

[Samuel]

I think the three major points are the globalization, greater compatibility to other licenses and future "upgradability" meaning: 

+ Its Based on the global agreement of the Berne convention: http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works

+ People have a greater freedom to mix code with other licences (if that is in your interest)
+ Everybody is free to upgrade to any future versions of the GPL, without needing the permission of each individual that was contributing (please correct me if I am misinterpreting this one)

[teppo]

Regarding ProcessWire going for GPLv3, it's also discussed in another thread here.

+ Everybody is free to upgrade to any future versions of the GPL, without needing the permission of each individual that was contributing (please correct me if I am misinterpreting this one)

I'm not really sure what you're referring to here; could you please explain which part of the license this is based on?

Edit: taking a closer look at the article posted above, I'm guessing this part about upgrading was based on last paragraph there? If that's the case, I don't think v3 actually changes anything. Licensing code under "GPL version x or any later version" is an old convention and other options they've mentioned still require permission from all authors (at least once) and neither of those are specific to v3.

Edit 2: mixing GPL with other licenses seems to be rather difficult subject to grasp. I know this is going a bit off-topic, but still wanted to share this article that, in my opinion, helps to clarify how, when and why this can and should be done: http://www.zdnet.com/blog/burnette/gplv3-myth2-you-cant-mix-gpl-software-with-other-software/331.

Edited April 1, 2013 by teppo

[Samuel]

Thank you teppo that clarified a lot. 
 

Regarding ProcessWire going for GPLv3, it's also discussed in another thread here.

I suggest, if there are any further ideas regarding different version, we continue in the other thread