After a recent discussion about licenses in relation to a new Confluence plugin, I thought a quick post to the developer blog on the subject might be useful.
Because Confluence and JIRA and not themselves GPL'd, you should not release your plugins under the GPL. The GPL is incompatible with being plugged into non-OS products, unless it is a completely independent application. Confluence and JIRA plugins would not fit that category.
Instead, please consider a license such as the LPGL, the Apache license or the BSD license. Those licenses allow unlimited distribution without any viral clauses.
(Technically, you can include a specific exception in your GPL license as described here, but that's a little more problematic.)
We're always grateful when users are able to contribute their work back to the community. Hopefully this will clear up a few details about to do so. If you have any questions about how to share your plugins, get in touch.
7 Comment(s)
Technically, all that releasing a plugin under the GPL would stop is Atlassian enhancing and distributing it; a third party author could write the plugin and release it as GPL without any problems, as the GPL only covers what the third party author wrote.
By Robert Watkins at January 4, 2006 6:38 PM
No, the GPL actually prohibits the distribution of such plugins by anyone, even the initial author. Read the GPL FAQ link in the post above -- http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
By Charles Miller at January 4, 2006 8:11 PM
I'm not convinced by the FSF's arguments on this one.
In order for their to be a license violation, there's needs to be a specific person that has violated the license. (Gee, that was obvious)
But who is it?
I can't break a license for my own software - I wrote it, I don't need to be licensed.
The GPL specifically states that it doesn't cover the running of the app, so it's hard to see how the user can violate the license. The GPL states: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. While it could be argued that the installation of the plugin constitutes "copying", none of the clauses in the GPL state that some copying is OK, other copying is bad. They really only provide restrictions on distribution and modification.
So where is the violation?
It is however, pretty much an exercise in futility. Generally the point of using the GPL is to allow people to create a derived work. However the FSF argues (and on this one I might agree) that a work derived from the plugin is actually derived from both the plugin and JIRA/Confluence. That would require that JIRA/Confluence be published under the GPL, and since the developer cannot do that, they cannot distribute their modification to the plugin.
(This issue is generally referred to as the late linking issue, and I'm not convinced it's as clear cut as the FSF make it out to be)
The above issue would also arrive if the original plugin was derived from some other GPL'd program/library.
So if my analysis is correct (and I believe it to be), it is perfectly legal to distribute a plugin (that is entirely your own code) under the GPL but no one would be able to make use of any of the provisions in the GPL.
However (...and you thought I was finished...) if the plugin API for Confluence was an open API that was implemented by a variety of Wiki engines, and 1 of those was under the GPL (or a license that is compatible with the GPL) then works derived from the plugin would be fine, because they could be considered to be derived from GPLwiki, rather than Confluence.
*sigh* It's all too complicated. BSD/Apache licenses are so much easier to deal with.
By Tim Vernum at January 5, 2006 1:12 AM
Tim: I can see the FSF's point of view, though.
I suspect they'd say the point of violation would be installing the plugin - that's the point at which the GPL software is 'combined' with the non-free software to create a license-breaking single program.
If you could write GPL'd plugins for non-free software, then _anyone_ could incorporate any GPL'd code they like into their program just by loading it dynamically at runtime. This sort of thing - incorporating GPL'd code into non-free software - is precisely the sort of activity the GPL was written to prevent, and so even if it's legally shaky, it's probably something that we should respect anyway for ethical reasons.
By Charles Miller at January 5, 2006 1:43 PM
I agree more with Tim and I think we all agree BSD-like is much easier to deal with for everyone! It is NOT the act of combining commercial and GPL software that is the problem - in the privacy of my own server, I can do almost anything I want (assuming I have legally licensed commercial software and I abide by the usage terms). However, distributing the combined (commercial and GPL) works would be a problem. The violator would be the person/group doing the distribution.
By Bob Swift at January 6, 2006 3:12 PM
What about if the plugin itself depends on something that is licensed under GPL?
For example, I think CVS is licensed under GPL.
By Anonymous at January 12, 2006 8:17 AM
In that case it would appear that the author of the original piece of code did not want it to be included in a closed product.
My opinion is you either contact them to check on what they want (and get it officially, in writing), or you don't distribute your plugin.
The authors of cvs (or another GPL product) have the right to chose where their code ends up - if they don't want it in JIRA/Confluence, then that's their decision to make and you should respect it.
By Tim Vernum at January 12, 2006 6:41 PM