There has been a lot of discussion and debate regarding the GPL and Joomla's use of it, or should I say "amended" implementation of it.
After a lot of thought I tried to condense my views into one relatively short article, which I am reproducing here for posterity. It was obviously written some time ago.
Background
Almost 3 years ago I wrote this document (or a similar version of it) to act as a licence guideline back when we were Mambo.
It was written after months of research and consultation with IP lawyers familiar with the GPL Licence in the UK, USA and Australia and senior figures in the Open Source world. Unfortunately neither the FSF nor FSF Europe contributed anything of value to the discussions. They merely pointed out that it was up to the copyright holder to determine if someone was in breach of the GPL Licence granted by Mambo..
The decision reached at the time regarding the licence of extensions was
"10. I have written a Component, Module, Template for Mambo. Do I have to release it under the GPL?
No The GPL allows you to write your own extensions for Mambo and to release those extensions under whatever license you chose. "
There were a few arguments that led to this decision whilst acknowledging that there was a definite issue regarding linking into mambo and if/whether the extension "required" mambo to operate etc. The two most persuasive ones were:-
- The decisions reached by the Linux Kernel to allow linking under any licence
- The fact that as the copyright holder it was up to Miro to enforce the copyright
As a result of point 2 above it was felt that even if the FSF did come out and say that something like a Mambo extension could not be released under anything other than a GPL licence it didn’t really matter as only Miro could enforce the licence. So if Miro decided and publicly stated that it was OK, then it was. The only thing that could potentially happen would be the FSF telling Miro that they couldn’t use the GPL but that was deemed to be highly unlikely.
NOTE at the time of writing the document there was a limited range of paid for extensions available, the majority of which were still GPL, and almost zero encrypted extensions.
When the split happened the same license guideline was also published on the OSM site. However on the advice of Software Freedom Law Centre (SFLC) it was removed as the SFLC felt that we needed to consider the whole copyright situation, specifically our situation regarding the rights to use the Mambo code etc.
These discussions were held between Mitch Pirtle, on behalf of OSM, and James Vasiles, of the SFLC. As a result of these discussions a new copyright statement for the code was issued and the "licence guideline" was replaced by a link to the GPL FAQ. My recollection of that time was that the SFLC were unhappy with our views regarding non-GPL licensed extensions. However it is important to remember that the SFLC were only legal advisors giving advice. It was up to us (the Joomla Core Team) if we chose to take that advice.
NOTE Obviously at the time we were all busy just getting Joomla up and running and as a result this was perhaps not followed up and completed to the depth that it should have been. never really followed up.
A few months later a rider was added to the copyright.php of Joomla 1.1. This was only for 1.1+ and I am not aware there was ever a statement made publicly by either OSM or Joomla regarding the issue of non-GPL extensions with Joomla 1.0.
Personal View
It is my belief that the major reason for Joomla's success and popularity, and that of Mambo before it was because it has been a design concept of Joomla since the very beginning to create an extendable CMS. Everything that can be done to make the life of developers easier has been.
When I say that I mean that installers have been provided for extensions and Joomla has been internally structured to allow the easy integration of extensions. Making the core code well documented and enabling extensions to hook directly into the core do the latter.
This means that developers do not have to write everything they can use the Joomla framework within their extensions. This reduces development time and ensures consistency and compatibility. If you look at some other complex open source applications the method to add extensions is to directly edit the core files. This makes thing very hard for the user and increases compatibility issues. Some other CMS have chosen the path of including the "best" extensions directly in the core. Joomla however believes that there is no one tool for job and that by keeping the core as slim as possible and encouraging 3rd parties to develop you the user get the option to chose the most appropriate extension for your site.
You only need to look at the range of image gallery extensions and their different features to see what I mean. Joomla could have chosen to include the most feature rich extension directly in the core but this would be overkill for many sites that just want a simple way to display images, Joomla lets you the site developer chose what is most appropriate for your site.
Another example of where the open framework of Joomla comes to the fore is in multi-language sites. An extension is available, joomfish, for this and because of the standardisation of extension structure joomfish is able to handle most extensions without alteration.
As a result it is my personal belief that it is of benefit to Joomla to allow the release of extensions under non-GPL compatible licences. Despite this I really don’t like the encrypted extensions but don’t see any way that OSM can "allow" non-GPL licensed extensions and ban encrypted extensions.
Clarification
This discussion relates not just to extensions released "for a fee" and/or "encrypted" but to any extension released under a licence that the FSF have determined to not be compatible with the GNU/GPL. This includes the Creative Commons licences regularly used by many developers. See GPL-Incompatible Free Software Licenses and Non-Free Software Licenses.
Moving Forward
So how do we move forward?
Rather than re-inventing the wheel we can learn from the approach taken by Red Hat, Sun and the Free Software Foundation itself and create an "extension" to the GPL Licence. [A "rider" is similar to an "extension" but I chose this word as that is what the companies/organisations referenced use.]
The Free Software Foundation (FSF) has licensed Classpath "under the terms of the GNU General Public License with the following clarification and special exception."
"Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version."
This is also the approach used by Sun in their recent licence changes to Java.
Red Hat has licensed Fedora Directory Server under the terms of a "GPL Exception Licence". Thoughtfully they also provide an annotated version of this GPL+Extension licence which I believe is worth quoting in its entirety here.
Preamble
This Program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.
This is the preamble of the License. It indicates that this code is available under version 2 of the GPL license. Note that this license is not upgradable to later versions. Many projects use an upgradable version of the GPL; we have decided not to do so.
Disclaimer of Warranty
This Program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
We're not responsible if this software eats your children. Or backs over your cat. Or causes a nuclear meltdown.
Full License Text
You should have received a copy of the GNU General Public License along with this Program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
This is where to get a copy of the full text of the GNU GPL if it wasn't included with this software. It usually is, but you should able to get it if for some reason it's missing.
Special Exception
A note about this special exception. The goal of this exception was to make it possible to build, use and distribute plugins for the Directory Server under the license of your choice but to make sure that the core of the Directory Server is maintained as a whole under an open source license, and to require that other users of it to also do the same. For example, if you wanted to replace some core piece of functionality in the directory server you would be required to give that piece back and everyone would benefit from that work. If you want to expose some proprietary functionality through the Directory Server and distribute a work that includes the two, that's OK, but you're limited to the interfaces specified in this exception. Please note that the plugin api is relatively rich and it should satisfy most users of the Directory Server.
In addition, as a special exception, Red Hat, Inc. gives You the additional right to link the code of this Program with code not covered under the GNU General Public License ("Non-GPL Code") and to distribute linked combinations including the two, subject to the limitations in this paragraph.
This says that you have the additional right to distribute code that's not covered by the GPL with this code. But that right only extends to the limitations that are outlined in the rest of this paragraph.
Non-GPL Code permitted under this exception must only link to the code of this Program through those well defined interfaces identified in the file named EXCEPTION found in the source code files (the "Approved Interfaces").
The interfaces that you can use to link to the GPLed code are defined in another file. Also note the use of the words 'well defined' here. This means that if the interface description is 'vague' or 'not well defined' that you do not have the right to use them. The use of a separate file means that if we change the list of Approved Interfaces that we won't have to update every file with that piece of minutia.
The files of Non-GPL Code may instantiate templates or use macros or inline functions from the Approved Interfaces without causing the resulting work to be covered by the GNU General Public License.
This clause is here to indicate that if you happen to use header files from the Approved Interfaces and those header files contain code that is then linked into your work then your work is not covered by the GNU GPL. Note that this doesn't talk about header files since including header files isn't the problem. It's the code that's generated as a result of using those header files that might, in some interpretations, cause your work to be covered under the GNU GPL.
Only Red Hat, Inc. may make changes or additions to the list of Approved Interfaces.
This means that only Red Hat, Inc. gets to make changes to the list of Approved Interfaces. Since the file that contains the list of Approved Interfaces is also distributed under the GNU GPL, it's perfectly fine to make changes to that file. We just wanted to make sure that if you do make changes to that file that the additional rights granted through this exception do not apply.
You must obey the GNU General Public License in all respects for all of the Program code and other code used in conjunction with the Program except the Non-GPL Code covered by this exception.
This says that you still have to follow the GNU GPL outside of the scope of this exception.
If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to provide this exception without modification, you must delete this exception statement from your version and license this file solely under the GPL without exception.
This says that if you want, you can remove this exception when you distribute your copy of this code. Also, if you remove this exception you must also make sure that you license it under the GPL.
Conclusion
It is my belief that the aims and objectives of both Joomla!, OSM and the Joomla! Community can be best met with a "GPL+Extension" licence similar to the ones above. In fact in my eyes the Red Hat version is ideally suited and could almost have been written for Joomla!
The other option would be to make no statement at all and do nothing about these extensions, which is the status quo. I would not recommend this option.
One final thing to consider is that if a decision is made not to allow X type of extension then that has to be enforced. This enforcement can only be done legally and it is potentially a very expensive business. Is this an expense that is worth OSM undertaking no matter the moral rites. I would suggest not.
Addendum
There is one situation however that I strongly believe must be prevented/stopped. This is the "bundling" of Joomla with non-GPL compatible code. This places a distribution restriction on Joomla itself and is abhorrent to me. To date I am aware of several Joomla bundles although only one of these places a restriction on its distribution. This bundle (name withheld) combines Joomla (and other GPL extensions) with some sample content and has a one domain only licence, which is therefore placing a redistribution licence on Joomla, which cannot be allowed.
I would propose an additional clause to my original guidelines (referenced back at the top) or a "Statement of Clarification"
16. Can I create custom versions of Joomla with my own content, extensions or templates pre-installed?
Yes you may do this however you cannot add any restrictions to the "package" that impinge on the 4 freedoms that the GPL licence gives to the Joomla code.(see top of guidelines for these freedoms).
