Licensing Question

If we build a Extension/Module/Plug-In/Feature for Modx, is the License prohibiting us from charging a fee for that module? Can we SELL the module for a FEE and bundle/distribute the MODx software for FREE with it?

http://www.gnu.org/copyleft/gpl.html

Why not just make it a part of e:Vo?

(what’s e:Vo?)

e:Vo is the CMS they use at their company: http://www.edesigninc.biz/innovation.php

It sounds like it’s got some really great features that are on the roadmap for future MODx releases. To answer your question more directly, you can find some additional discussion on MODx and our intentions with respect to it’s license at http://modxcms.com/forums/index.php/topic,10183.0.html

In short, we’d like to foster a very vibrant developer community around MODx and that means making it 100% OK from a spirit/letter of the law standpoint, and easy for developers to deliver proprietarily licensed add-ons to go with our free core. We’ll be getting a real legal opinion and statement to that effect as soon as financially feasible for our new code base coming in 0.9.7.x (and beyond).

Quote from: edoggie at Nov 14, 2007, 12:56 AM

If we build a Extension/Module/Plug-In/Feature for Modx, is the License prohibiting us from charging a fee for that module? Can we SELL the module for a FEE and bundle/distribute the MODx software for FREE with it?

Basically, you can sell "proprietary" (or closed-source) extensions, modules, and plugins, so long as they do not modify any of the core source files included with the MODx distribution, but you cannot bundle and distribute MODx along-side said extensions (i.e. on the same disk). You can sell "open-source" extensions (with a GPL-compatible license) and feel free to bundle those with MODx and charge what you want, but you must make all of the source code available to anyone you distribute it to upon request.

We’re basically looking to take e:Vo functionality out of e:Vo and add it to a Open Source platform. This would garner more interest as Open Source CMS’es tend to be more popular, and have a greater community of developers, extensions etc. We don’t want to reinvent the wheel, we are developing tools for very specific industry requirements. By wrapping our tools around a Web CMS that’s as full featured and extensible as MODx we think we could deliver a better product.

So I am still unclear, in your statement you said we can’t distribute on the same disk? We’re an advertising agency, so we charge for Custom Website Design and Development, if we are charging people for our custom-extension and our creative work, does that mean we can not host MODx on the same server our extension runs on?

Again the GPL is a little unclear here? Would a "private label" license as you suggest your working on solve this problem?

-Eric

Quote from: edoggie at Nov 14, 2007, 01:27 PM

So I am still unclear, in your statement you said we can’t distribute on the same disk? We’re an advertising agency, so we charge for Custom Website Design and Development, if we are charging people for our custom-extension and our creative work, does that mean we can not host MODx on the same server our extension runs on?

Again the GPL is a little unclear here? Would a "private label" license as you suggest your working on solve this problem?

Actually, ignore my comment about distribution on the same disk. Let me try to clarify this further, once again.

Technically, you can’t combine a piece of GPL software together with a "proprietary" add-on or extension; "proprietary" meaning one where the source code is not freely available. This applies on-disk or otherwise. This has nothing to do with hosting or deployment on a web server environment. However, it is legally unclear how to define the difference between combining works into a derivative and mere aggregation in terms of components intended for our CMS framework. Some, like me, claim that add-ons are merely data processed through the framework, just as your proprietary XHTML/CSS designs might be interpreted by a web server, but others, consider Joomla! for instance, have interpreted add-ons as being dynamically linked, and thus must be covered under a compatible-license.

So, my opinion is that you should be able to create proprietary add-ons, so long as they do not modify or extend the core code directly, but some believe that simply calling API methods provided for interacting with the framework creates a derivative work and thus requires your add-on to also be covered under a GPL-compatible license. Unfortunately, my opinion does not grant me permission to make definitive legal decisions with regard to to these issues on MODx. Only legal precedents or at least a very thorough legal review can truly make this any clearer.

With that in mind, I truly believe the best choice for 3rd-party component developers is to distribute their code under a GPL-compatible license and charge users for support and services; maybe even for the convenience of trusted downloads of the software. That way, if legal precedent or advice forces us to change my "opinion" with regard to allowing proprietary add-ons, you can avoid the whole dilemma of whether to stop distributing it or continue under a GPL-compatible license. This also benefits and helps reinforce the open-source spirit of the MODx community overall.

Linux could be considered the poster child of GPL, and there are a number of distributions of Linux that also contain proprietary applications, drivers, and such. DVD players are a good example, until recently there were no legal free DVD players (I’m not real sure that there are any even now), but a number of distributions include legal commercial DVD players.

http://www.linspire.com/products_linspire_whatis.php

Thanks Jason for the in-depth analysis of the GPL and how it could be interpreted in many ways. I think this might make it difficult to proceed with MODx for our project, since convincing people in my office to write FREE software will probably be more very difficult. Software development is amazingly time-consuming and costly, even with clearly defined technical specifications, coding on spec is always difficult because clients always change their mind about things.

I’m still going to get my feet wet with MODx cause it looks like a great platform, and maybe the "private label" product you are developing for your 1.0 release will resolve the GPL questions or problems I might encounter otherwise.

Keep up the great work.

-Eric