SMF Bridge for Joomla! Discontinued

[青山 素子]

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.

[Dragooon]

So that means all the current bridges for Joomla! are removed and no more bridge will be made?

[Joshua Dickerson]

Yep.

[robbievk]

jeez...

[Aaron]

Damn, that's really bad news.

[Superdaantje]

Still want to use the Bridge. But when this is not possible with Joomla! Then I maybe have to reconsider to take a look at an other CMS system. Really to bad I liked the Combo Joomla! and SMF. This is not a great step for the future.

[GravuTrad]

Lets go on mambo so....

does the mambo brigde is ok for mambo 4.6.2?

cause there will be lots of people which will go on it....

[Prasad007]

Still want to use the Bridge. But when this is not possible with Joomla! Then I maybe have to reconsider to take a look at an other CMS system. Really to bad I liked the Combo Joomla! and SMF. This is not a great step for the future.

Yeah... very sad indeed!

[zigzag]

Kind of leaves us all high and dry  surely this can be sorted out 

[Ninoslav]

Damn, bad news for sure

glue script shoudn't be under GPL

Maybe talking directly to joomla coders could resolve this...

Still, i think unofficial scripts will float around..

[ormuz]

No comments, where is the ***** freedom in the "free" software?!

Does Joomla! need some guns?! I can go take 2 or 3 pistols...

[Prasad007]

Still, i think unofficial scripts will float around..

Hopefully...

[Ninoslav]

Still, i think unofficial scripts will float around..

Hopefully...

Well, we know that Joomla 1.5 will NOT be able to bridge with SMF whatsoever, so our only chance is older versions of Joomla along with updated bridge for SMF 1.1.3+, maybe even SMF2... :|

[Peter Duggan]

surely this can be sorted out 

Maybe talking directly to joomla coders could resolve this...

Negative on both counts! The whole point about this announcement is that everything possible has been done and it's *the end* for the bridge as we know it.

[Superdaantje]

Still, i think unofficial scripts will float around..

Hopefully...

Well, we know that Joomla 1.5 will NOT be able to bridge with SMF whatsoever, so our only chance is older versions of Joomla along with updated bridge for SMF 1.1.3+, maybe even SMF2... :|

There was a bridge for J! 1.5. There was even a sticky about that on this board

But at this moment I'm testing with Mambo. And it looks ok for me  I'm thinking about migrating to Mambo in the near future.

[青山 素子]

glue script shoudn't be under GPL

Maybe talking directly to joomla coders could resolve this...

Unfortunately, that isn't the case. The Joomla! developers are set on this interpretation and they have lost a number of developers over it. There is older discussion over here when things first started. The best we could come up with was a bridge that consisted of multiple wrappers in order to transition properly without violating the license. Given the FSF's position that it could still be considered a combined work, however, there is no way we could legally continue distributing a bridge.

Well, we know that Joomla 1.5 will NOT be able to bridge with SMF whatsoever, so our only chance is older versions of Joomla along with updated bridge for SMF 1.1.3+, maybe even SMF2... :|

Even that won't work. As was said above, the Joomla! team consider this position on their license retroactive, so it applies to older versions of Joomla! as well. That is why we can't distribute the bridge at all anymore, even for older versions of Joomla!



As a note, if you develop your own solution, it is perfectly legal to use it. The problem comes when you distribute it, which causes it to fall under the terms of the GPL.

[Orstio]

Lets go on mambo so....

does the mambo brigde is ok for mambo 4.6.2?

cause there will be lots of people which will go on it....

Yes, the Mambo bridge is specifically designed for Mambo 4.6.2.

[redone]

Damn, bad news for sure

glue script shouldn't be under GPL

Maybe talking directly to joomla coders could resolve this...

Still, i think unofficial scripts will float around..

Why would you?

a) Not respect Joomla's license? Just because you do not agree with them does not mean you should not follow the license of the product your using.

b) Risk legal action against yourself and your site for using something that is essentially breaking the law.

You are on a rocky road if you take the path of using an illegal bridge if you ask me.

[gsbe]

I was reading the pages on license and copyright here at the simplemachines.org site and did not find any information about which license SMF uses. Which license does SMF use? In what ways is this license not GPL-compatible? Are there any possibilities for heading towards a GPL-compatible license?

This issue of licensing is obviously coming to a head in the Joomla community but has been an issue for quite some time with all open-source projects. Here is a link to a document called "Make Your Open Source Software GPL-Compatible. Or Else." by David Wheeler in which he recounts a brief history of other projects with similar problems and the benefits of going with a GPL-compatible license for open-source projects.

Thanks for helping me understand these confusing issues. I hope that everyone who uses SMF and Joomla can wait and see what we can come up with before jumping ship to another CMS. The Joomla project has officially supported SMF for a long time. These issues should come as no surprise to long-term members of the global open-source community and they have been overcome before!

Finally, I'd like to point out that this is not a few rogue Joomla core team members' opinions, this is the project's official interpretation of the license. This interpretation has been made, similar to Motoko-chan's posts here, with the recommendations of many forerunners in IP law that specialize in the licensing of open-source projects. I believe that the intention of Joomla's  interpretation is to HELP the community clarify what it means to be compatible with the GPL license that the community requests, not a call to arms. Please consider this before flaming because supporting the GPL is the exact freedom we've asked for as a community.

[Peter Duggan]

I was reading the pages on license and copyright here at the simplemachines.org site and did not find any information about which license SMF uses. Which license does SMF use? In what ways is this license not GPL-compatible? Are there any possibilities for heading towards a GPL-compatible license?

http://www.simplemachines.org/about/license.php

http://www.simplemachines.org/about/opensource.php