Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have a question regarding the possibility of developing commercially licenced plugins for XRMS.
I spent a couple of days recently researching this topic and it appears to me that the GPL/FSF licencing of XRMS prohibits the distribution of plugins under any licence other than the GPL/FSF.
The key is the "derivative work" concept which the GPL interprets to be any work that shares code (such as the API) or data structures (such as the XRMS database) with the original software. Under that concept, any plugin that interracts with the database would be considered to be a derivative work and must therefore be GPL licenced. The FSF reads about the same.
Did I understand this correctly? Even if the plugin provides functionality that does not presently exist in the system? And, of course, we know what happens when a software is GPL'ed. Theoretically, it could be sold. Practically, you would be lucky to get a drip of donations here and there. Now, I am not looking to retire here but paying for all the coffee in the middle of the night would be nice.
The issue is that I have more or less completed development of the webmail client that I had so cried for last year but, at the present level of sponsorship (and THANK YOU to the sponsors, every bit counts!) I can only cover a fraction of the development cost if I was to release it under the GPL/FSF. Of course, I could hand the hat out to more people and hope for the best. On the other hand, however, if I was allowed to release it under a commercial licence, I could sell it at a lower price to a number of clients and thus cover the development cost. To me this sounds like the sane way to monetize a project and support further development but, unless I have misunderstood, the GPL & FSF do not agree.
I am not at all objecting the OS licence. In fact, releasing the plugin as OSS was my original intent and, once costs are covered, I have no objection to release it under the OSL. However, at the present level of sponsorship the ROI on this project is still rather negative :(
Any feedback on this rant would be greatly appreciated!
Using the XRMS database or the plugin API does not create a derivative work. Because of the nature of enterprise-grade CRM systems, they must often be interfaced with proprietary software. It has always been my intention and the intention of the other developers who have worked on XRMS who have been consulted that XRMS should allow for this kind of integration in a way that did not put people in GPL trouble.
Several years ago, I consulted with United States intellectual property lawyers to make sure that I could build plugins licensed separately from XRMS for XRMS, and was assured that this was possible and legal in the US, provided that a few other guidelines were observed.
The most important is the source of the code that goes into the plugin. XRMS provides the plugin API, the contacts API, etc. Using these API's would not create a derivative work, as that is what they are intended for, and courts have held that API's are not a form of protected expression.
You've probably used as a template other code within XRMS, and modified it to work for the webmail code.
If, for example, you've used the Pager code, you *may* (IANAL) have created a derivative work, as that code is core to XRMS. We wrote the Pager originally as proprietary code, and contributed it into XRMS making a conscious decision to GPL that code and to place it into the GPL-protected core. The Pager is not part of XRMS's "exported API's" which would not run afoul of the GPL if you simply use the API to *access* (via the API) XRMS core functionality. Similarly, if you call the functions in the activities API, you would *not* create a GPL violation, but if you freely cut and paste from activities/new-2.php, you may (probably?) have created a derivative work.
In your case here, you have created a webmail plugin. If you have modified source code files from the webmail program to create your pages such as a Compose page, or a Folder List, or a Inbox list view, then you *may* have created a derivative work of *that* code (even if your code is not a derivative work of XRMS, and allowed under XRMS's license).
There has been much written online by people far more qualified than I am to provide guidance to those who wish to have their code co-exist next to GPL code without violating the GPL, so take my opinion with a grain of salt. That said, simply using the published API's of XRMS (plugin, contact, activity, etc.) or accessing the XRMS database, will not in and of itself create a derivative work. The thing that would create a derivative work would be the incorporation and modification of CODE that is GPL (and does not constitute a non-protected API) would create the derivative work.
If you want to release (and therefore distribute) the webmail plugin in a license other than the GPL, you should probably consult a lawyer. The FSF lawyers are usually willing to have short conversations with people to avoid later problems if you give them a call.
I wish you all the best with the webmail code, and certainly hope that others will donate to gopherit directly to gain access to it, whether it is deemed to be GPL or not.
I may misunderstand, but it does not seem to be a licencing issue to me.
The GPL requires the source to be distributed/provided along with the software. With PHP, the software is the source.
It follows that whether you use a proprietary licence, or not, you inherently provide the source when you provide the software. All you get from the proprietary licence is a contractual right to go after those who infringe your copyright. That may be good for lawyers, but is not going to put anything in your pocket.
Given the nature of xrms to date, I doubt that the nature of the licence will have any effect on the number of licences that you will sell, or the amount of profit, whether described as donations or licence fees. YMMV.
Irrespective of the actual licence, you are entitled to charge consultants fees for making XRMS more suitable for a particular client's use, including supplying and or installing an email plugin.
IMHO it's mostly licensing issue. When selling services along with software then it becomes tricky if software is actually easily usable without significant knowledge and/or investments. As naturally is the case with addon kind of component - anyone can snap it to the core system. With GPL licensed addon it means - one can be sure of one sale action only if one has developed it on his own without paid project. After that this addon can be redistributed freely by first buyer and any restrictions on that redistribution would violate GPL license. Look up for fuss around Joomla extensions, especially in relation to templates. Only thing that original author can somehow protect is some IP in addon name/trademark, but not functioning software itself.
So, options to develop addon as a product for GPL-ed system isn't promising in regard of ROI unless there is potential client ready to contract one for feature development.
P.S. As for hiding source in PHP - technically one can do this as well (there are products on the market for that purpose); but hiding source is against GPL.
First of all, thank you for the prompt and detailed responses and please accept my apologies for the delay in returning to the discussion! It has been a very busy month for me, signing up my first client and all the work that they loaded on me. Now, on to the question at hand…
Brian, thank you very much for that clarification! I am now quite comfortable with the fact that I can calmly offer the webmail plugin under a commerical licence. To make certain, I did a detailed code review and can report the following:
- The webmail client plugin is not a modification or derived in any way from any open-source software, XRMS or other; not even the Email-Merge functionality that exists in XRMS.
- For sending emails, the plugin makes use (calls to the provided objects and classes) of the Swift Mailer library which is licensed under the LGPL and therefore can be used freely in commercial products without conflicts as long as its source is distributed along with the commercial portion of the plugin. I have no problem doing that.
- I have used two functions (under 100 lines of code) from the public domain as a starting point for the parsing of incoming emails. Even though I had to modify them, proper credit for those functions has been given in the Credits section of the documentation.
- I have used the HTML-only portion of XRMS's Email Merge client simply to provide a consistently-looking interface template for the plugin. The code loading the HTML and providing server-side validation, however, is completely different.
- The rest of the code - about 100KB including documentation and whitespace - has been written from scratch.
So, again, thank you for pointing me in the right direction! My original concern was that using the XRMS API or even making calls to the XRMS database can already be deemed to be creating a derivative work. However, if that is not a concern from a GPL perspective, I think the webmail plugin should be quite fine under a commercial licence.
Now, the next question is, since the plugin will be licensed as a commercial product, whether it is OK for me to announce it in the Plugin forums here or should I should stick to promoting it solely through my company website?
Thanks again, everyone, and especially Brian, for your valuable input!