As some of you might know, there have recently been some changes on part of the Joomla! project in how they interpret the license their software is under. Namely, while the project remains under the exact same license (the GPL), they are now interpreting this license in its strictest sense. In addition, the project has announced that this change in interpretation is retroactive and applies to all previous versions of their software.
As a result of this change of direction, only GPL-licensed software can legally be distributed and used inside the Joomla! software. While we regret and are saddened by this development, we respect Joomla!'s position on their software license. As neither SMF nor the SMF bridge for Joomla! are licensed under GPL or a compatible license, we have had to cease distribution of our bridge. Please note that running the software as separate standalone pieces is perfectly fine, the issue is in the integration/bridge.
Due to this license issue, it is not legal for us to distribute our bridge. In addition, all versions of the bridge from 3.19 for the SMF 1.0 series to the latest 1.1.7 release for the SMF 1.1 series are under the SMF license, which forbids all redistribution. Just as we respect the license Joomla! is under, we ask that you respect our license and not distribute the bridge.
We will continue to support all existing installs of our bridge until such time as either changes in Joomla! or SMF render the bridge unusable (upgrades to Joomla! 1.0.13 and beyond and/or SMF 2.0). We will also not support any issues caused by third-party bridges.
For those users who wish to continue their use of SMF fully integrated into a CMS, we recommend investigating the other options you have available to you. Our work on bridges for Mambo and other CMS programs will continue.
For those who wonder why we have had to come to such a decision, we have had input from both the Joomla! project and the FSF directly, and it is the stance of both Joomla! and the FSF that the use of a bridge into a GPL-licensed system constitutes the creation of a combined work. This forced us to reconsider our development of the bridge and look for ways we could accomplish the task while still respecting the licensing of both projects. Ultimately, that proved impossible. When discussing with the FSF, they stated that the bridge
and SMF would fall under the GPL license, and there is no workaround. Below is an exchange between me and the FSF.
Date: Wed, 11 Jul 2007 08:13:40 -0700
To: licensing@fsf.org
Subject: License Clarification
I was looking over the GPL earlier and I had a question I hope you could
answer for me. Now, given the age of the GPL v2, I can understand that
it didn't take into account web applications, but a lot of web
applications are under this version today.
Given the license restriction on linking, how would that apply to web
applications written in a scripting language such as PHP or Ruby? I know
many of them offer a "module" or "plugin" system for developers. Would
making use of these systems constitute linking? Also, if such a plugin
or module was distributed separate from the GPL-licensed system and
installed manually by an end-user, how would the GPL work on that?
I know the GPL v2 is considered old now, but if you could advise me as
to my concern based on it, I would appreciate it. Also, if you could
note if v3 changes anything in this regard I'd also appreciate knowing.
Thank you very much.
Subject: Re: [gnu.org #339003] License Clarification
From: "Brett Smith via RT" <licensing@fsf.org>
Date: Mon, 16 Jul 2007 12:14:33 -0400
On Wed, Jul 11, 2007 at 11:17:57AM -0400, [Motoko-chan] via RT wrote:
> Given the license restriction on linking, how would that apply to web
> applications written in a scripting language such as PHP or Ruby? I know
> many of them offer a "module" or "plugin" system for developers. Would
> making use of these systems constitute linking? Also, if such a plugin
> or module was distributed separate from the GPL-licensed system and
> installed manually by an end-user, how would the GPL work on that?
Our GPL FAQ has some discussion about how the plug-ins are affected by the
license; please see
<http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins>. If the
plug-in is based on the original program (the answer talks about when that
is and isn't the case), then the developers need permission under copyright
law to create and distribute it. Ordinarily, the GPL is the only thing
granting them such permission, and so plug-in developers must follow its
terms whether their code is distributed together with, or separately from,
the original software. This includes releasing their own work under the
GPL.
If you have any other questions, please feel free to contact us.
Best regards,
--
Brett Smith
Licensing Compliance Engineer, Free Software Foundation
Please note that I am not an attorney. This is not legal advice.
Date: Thu, 19 Jul 2007 08:52:45 -0700
To: licensing@fsf.org
Subject: Re: [gnu.org #339003] License Clarification
Brett Smith via RT wrote:
> On Wed, Jul 11, 2007 at 11:17:57AM -0400, [Motoko-chan] via RT wrote:
>> Given the license restriction on linking, how would that apply to web
>> applications written in a scripting language such as PHP or Ruby? I know
>> many of them offer a "module" or "plugin" system for developers. Would
>> making use of these systems constitute linking? Also, if such a plugin
>> or module was distributed separate from the GPL-licensed system and
>> installed manually by an end-user, how would the GPL work on that?
>
> Our GPL FAQ has some discussion about how the plug-ins are affected by the
> license; please see
> <http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins>. If the
> plug-in is based on the original program (the answer talks about when that
> is and isn't the case), then the developers need permission under copyright
> law to create and distribute it. Ordinarily, the GPL is the only thing
> granting them such permission, and so plug-in developers must follow its
> terms whether their code is distributed together with, or separately from,
> the original software. This includes releasing their own work under the
> GPL.
>
> If you have any other questions, please feel free to contact us.
>
> Best regards,
>
While I appreciate the response, that FAQ deals with compiled software,
not on software provided as scripts in languages like PHP. As PHP is
interpreted by an external program (much like older BASIC was), there is
no linking that can be done in the program code. Similarly, there is no
ability to fork and exec as stated in that FAQ. It might be closer to
the third option given, but that still isn't quite the same.
Here is an example of a situation I am thinking of. Perhaps this will be
helpful. A web script is released under the GPL. It contains an API for
extending its functionality. Obviously, there is no ABI or similar as
there is no compiler. Now, a third party has another web script that is
complementary to the functions in the first. They decide that they can
write a "glue" script to the API of the first script to combine the
functionalty of the scripts such that the second party's script can be
called for output by the first script.
Simple diagram:
First Script (GPL) <---> "Glue" Script <---> Second Script
Now, as all parts are, say, PHP, nothing is compiled. There is thus no
linking or anything that traditional applications use to be able to run.
The "glue" script doesn't use any code of the first script. It simply
uses the published API structure to allow the first script to understand
it. All code for both the first script and "glue" are in their own
self-contained files. You could even go as far as saying this glue would
act as a two-way pipe allowing the separate scripts to communicate.
So, given that situation, how would licensing work for the "glue" script
and the second script? As there is no actual combining of raw code
(except in memory), does that still count as linking and thus requires
the GPL? If the glue does have to be GPL (or LGPL), could the second
script be then legally licensed under a non-compatible license?
Subject: Re: [gnu.org #339003] License Clarification
From: "Brett Smith via RT" <licensing@fsf.org>
Date: Mon, 23 Jul 2007 11:39:06 -0400
On Thu, Jul 19, 2007 at 11:56:47AM -0400, [Motoko-chan] via RT wrote:
> While I appreciate the response, that FAQ deals with compiled software,
> not on software provided as scripts in languages like PHP. As PHP is
> interpreted by an external program (much like older BASIC was), there is
> no linking that can be done in the program code. Similarly, there is no
> ability to fork and exec as stated in that FAQ. It might be closer to
> the third option given, but that still isn't quite the same.
Almost all scripting languages I know about have some functionality to
import scripts or modules, and then use data and functions from that other
code. Calling functions that are imported like this creates a derivative
work, much in the same way that linking does for compiled languages.
PHP also has exec functionality. See, for example,
<http://us.php.net/function.exec>.
> Now, a third party has another web script that is complementary to the
> functions in the first.
When you say this, I assume you mean complementary in the sense that a
human would want to combine them both -- not that there's any copyright
relationship between the two. The second script should be completely
independent, able to perform some function on its own.
> So, given that situation, how would licensing work for the "glue" script
> and the second script? As there is no actual combining of raw code
> (except in memory), does that still count as linking and thus requires
> the GPL?
Yes.
> If the glue does have to be GPL (or LGPL), could the second script be
> then legally licensed under a non-compatible license?
No.
Again, if you have further questions, please let me know.
Best regards,
--
Brett Smith
Licensing Compliance Engineer, Free Software Foundation
Please note that I am not an attorney. This is not legal advice.
Date: Mon, 23 Jul 2007 09:50:10 -0700
To: licensing@fsf.org
Subject: Re: [gnu.org #339003] License Clarification
Sorry for yet another query, I just want to fully understand this. I
added my comments and questions in the below quote.
Brett Smith via RT wrote:
>> Now, a third party has another web script that is complementary to the
>> functions in the first.
>
> When you say this, I assume you mean complementary in the sense that a
> human would want to combine them both -- not that there's any copyright
> relationship between the two. The second script should be completely
> independent, able to perform some function on its own.
Correct, the second script would be a standalone product. I did mean
complementary in the sense that their functions would be something a
user would want to combine, not in a copyright relationship.
>
>> So, given that situation, how would licensing work for the "glue" script
>> and the second script? As there is no actual combining of raw code
>> (except in memory), does that still count as linking and thus requires
>> the GPL?
>
> Yes.
>
>> If the glue does have to be GPL (or LGPL), could the second script be
>> then legally licensed under a non-compatible license?
>
> No.
Considering the first script is GPL with no exceptions and the second is
proprietary, if the bridge was licensed as GPL with an exception would
that satisfy all requirements? If so, is there a way to make it so such
combination would not be possible?
>
> Again, if you have further questions, please let me know.
>
> Best regards,
>
Subject: Re: [gnu.org #339003] License Clarification
From: "Brett Smith via RT" <licensing@fsf.org>
Date: Mon, 23 Jul 2007 13:01:14 -0400
On Mon, Jul 23, 2007 at 12:54:24PM -0400, [Motoko-chan] via RT wrote:
> >> If the glue does have to be GPL (or LGPL), could the second script be
> >> then legally licensed under a non-compatible license?
> >
> > No.
>
> Considering the first script is GPL with no exceptions and the second is
> proprietary, if the bridge was licensed as GPL with an exception would
> that satisfy all requirements?
No. The glue script would ultimately create a single work, derived from
both the original scripts, and you would need to follow the terms of all
those licenses to create it. Combining the first script with the second
this way would violate its exception-free GPL.
Best regards,
--
Brett Smith
Licensing Compliance Engineer, Free Software Foundation
Please note that I am not an attorney. This is not legal advice.
