Amy Stephen over at Open Source Community has put together a good summary for how differing open source CMS projects have interpreted the impact the GPL has on third-party extensions/modules/plugins/add-ons. Movement in the Joomla community ensuring GPL compliance for extensions is what prompted her comparisons of license interpretation between Drupal, Joomla, Plone, Typo3, Wordpress, and XOOPS.
Anyone else confused? I know I am (which isn't difficult for me). If a GPL project doesn't offer an exception...I wonder how many third-party modules offered as bridges between a GPL applications and non-GPL application are in jeporady for that project? I also wonder how open source CMS projects address those exceptions to the GPL license? While projects may address those exceptions within their community or their official sites, I wonder how many actually include a copy of those exceptions on file within the distributed package?
Joomla!'s announcement from June 15, 2007 that began Joomla! is moving to ensure the future of the project by committing to compliance with the GNU/GPL license was a bit shocking to many accustomed to the Mambo proprietary extension licensing exception.Sometimes I wish I was a lawyer because it really is difficult to know who is right and who is wrong in their interpretation of the GPL. Probably the most confusing interpretation is in the area of bridges where a third-party module is used to connect a GPL application with a non-GPL application. The significant impact of a strict interpretation of the GPL license can be clearly seen though Simple Machine's announcement of a SMF Bridge for Joomla! being discontinued due to the license interpretation change. If you read the correspondence between SMF's developers and the Freedom Software Foundation representatives you come to the conclusion that even though the bridge is GPL you could still have legal issues if both applications being bridged are not under the GPL.
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
Anyone else confused? I know I am (which isn't difficult for me). If a GPL project doesn't offer an exception...I wonder how many third-party modules offered as bridges between a GPL applications and non-GPL application are in jeporady for that project? I also wonder how open source CMS projects address those exceptions to the GPL license? While projects may address those exceptions within their community or their official sites, I wonder how many actually include a copy of those exceptions on file within the distributed package?
CMS Topics:
Bookmark/Search this post with
Comments
Bryan -
Bryan -
Thanks for covering the story and topic. As you know, it has been a very challenging few months for the Joomla! community. But, every day, I am more and more confident that the core team is moving Joomla! in the right direction. The transition is going to be long and we *are* going to lose extensions. This and the fork are huge and brave and appropriate steps. We are in very good company with Drupal, Joomla, Plone, Typo3, Wordpress, and XOOPS. The reason I finally did the piece on third party licensing is because there were so many comments that Joomla! was the only project who saw things this way. As it turns out, the Mambo approach is far more likely the "odd" perspective.
Regarding the SMF Bridge. I want to also point out that in the 23 Jul 2007 note from Brett Smith, he also indicated the PHP exec function that could be used to develop a bridge. I have also heard that a GPL'd bridge dependent on the GPL software, rather than the proprietary side, is a workable method. The SMF bridge is including Joomla! code into a bridge that is not GPL-compatible and it is dependent upon the SMF software. It is fair to say the GPL does not intend to make it *easy* for proprietary software.The intention is to liberate code and ensure continual downstream benefits to users.
So, yes, it's going to be easier to integrate open source code into a GPL'ed environment. And, as it should be! It is important that community environments also ensure that open source developers benefit more than proprietary developers. It hasn't been that way in J! or in Mambo. The community volunteers provide documentation, infrastructure, assistance, and training, at no charge. The environment should favor free (liberated) code over proprietary software. Joomla! foundation is called OpenSourceMatters. Well, it does! Joomla! is heading the right direction. I am confident of that.
Will SMF be in Joomla!'s future? I don't know. But, it is up to the SMF team, there are *ways* to do it. It is very odd to see that there is a Wordpress and XOOPS bridge. Matt Mullenweg *is* a huge GPL advocate, no doubt about it! Will Joomla! have a forum? Certainly! phpBB3 is in RC4 and nearing release and RocketWerx is working on a "non-invasive synchronous/asynchronous Joomla! 1.5/phpbb3 bridge". That's from Andy Miller. I have no idea what that means, but, I *think* that is good. Andy's a geek and he cheats at putt-putt golf. But, he tends to know these things.
In the end, phpBB3 will be a closer match to Joomla! given it is also GPL'ed and they require GPL-compliant "mods", as well. Drupal does a NUMBER of things right. There is a ROCKING community and it's so obvious that developers collaborate. You can tell that people have fun. I realize there are challenges, too, but I believe staying compliant with the GPL has been good for the Drupal community and helped to strengthen the open source developer network. Joomla! has had a strong developer world, but it's a bit more like a set of independent businesses than a collaborative community. So, I think in a year's time, we will also have some of those amazing community strengthens I see in Drupal. In the end, it's a strong community that builds a strong and lasting project.
BTW - if *anyone* is interested in learning how to develop Joomla! v 1.5 extensions, Brad Baker *just* opened a Joomla! Developer 101 Board and a group of geek wanna be's are gathering. Feel free to jump in and learn (or just help the rest of us!) Amy :) You have just read the opinions of Amy Stephen. These are just her opinions. No software, proprietary, GPL'ed or GPL-compliant was hurt in the typing of these comments.
Sounds as if the real
Sounds as if the real problem between SMF and Joomla is a tug of war on both sides not willing to grant some exceptions. Personally, I prefer SMF over phpBB and always sought better methods to connect my GPL applications with SMF. I now understand why many GPL CMS developers were less than eager to work on bridges for SMF.
Amy thanks for your post and I see something that will make in your writing that will make a perfect "Quoting IT" citation. Coming soon!
Bryan -
Bryan -
First of all, I hate that inter-project bashing. I know you feel the same. BORING. But, I have to tell you, I disagree completely with the poster. We just don't see Drupal bashing in the forums. Having read that thread, though, I now understand why you believe this is merely a "tug of war" between SMF and Joomla!. On July 16, 2006, in that thread you said:
You see, Bryan, SMF does *not* have an open source license. In fact, if you look at the license, it is named SMF license. That is their own self-created license - it's *not* in the list of OSI approved licenses and it never would be approved by the OSI, either, because it doesn't meet the guidelines of an open source license. Both distribution and modification require SMF consent, for example. Those are two key liberties that are needed for open source designation. So, no, sadly, it's not a tug-of-war. Yes, it really is a license issue.
Please don't forget - that email conversation you linked to was initiated by SMF to FSF and never included or discussed Joomla!. It's just about bridging GPL and non-GPL compliant code. The same is true for SMF and Drupal, SMF and WordPress, SMF and XOOPS.
++++
I followed some links in that thread you shared in Drupal, and I was surprised to see that there now is an SMF Module for Drupal. I would certainly love hearing more about how it is constructed. Of course, the module is GPL'ed since it is in Drupal's repository. So, that's good. t would be good to understand how it was constructed. That might give us an answer. Are you familiar with the developer? Interesting.
GPL labled software that isn't GPL compliant
This is where I was going as my focus wasn't intended to only be only on Joomla but all CMS that are under the GPL. As you stated in your message with Jeff below, "simply GPL'ing the bridge is not enough." I think there are a lot of GPL open source projects out there that assumed as long as the bridge/glue provided as a module/extension/plugin/addon was GPL then there were no issues here. However, I think we're all realizing, some for the first time, that I don't think that is necessarily true.
I don't know much about the SMF Module for Drupal. At the time I was hoping to use SMF and Drupal for an ecommerce site, but ended up choosing osCommerce and SMF...and running them as independent applications as I never found an osCommerce-SMF bridge that really worked well.
Although the intent of the author is to have the SMF Module for Drupal under the GPL, I see that the module requires you to modify SMF's code to make the module work.
4) Unpack smf_api_2 archive and copy it to subdirectory .../modules/smfforum/includes/
If the module doesn't violate the GPL it most certainly appears that it would violate SMF's license.
Again I'm no lawywer and intent is not focus so much on Joomla, Drupal, SMF, nor the specific Drupal module above. My point is that I think there are a number of GPL modules in open source CMS used to integrate with non-GPL applications. While the intent is to have a GPL compatible module, I wonder how many of those modules really wouldn't be seen by OSI as actually GPL compliant. We often accuse people of spreading FUD in these type of discussions...but I know at least in my case this is real legitimate FUD. While the GPL is a lot easier to understand than many of the propriety licenses I have to interpret (ever read a Microsoft license from start to finish)...the GPL like any other software license can cause a lot of questions.
Exactly! There you go! That,
Exactly! There you go! That, my friend, is where we have been living for a few months. Now, imagine thinking through those issues while an emotional battle is raging all around. It moves from difficult to heartbreaking when the FUD and accusations of impropriety are also being shared. Very sad. The comment you quote about "fork and exec" is right on the money.
Again, returning to the SMF-FSF email exchange, on the 23rd, again, Brett Smith said "PHP also has exec functionality. See, for example, http://us.php.net/function.exec." That is okay! Working with the output of the program - the data - is okay. It's just more difficult. In my first response, I said "It is fair to say the GPL does not intend to make it *easy* for proprietary software.The intention is to liberate code and ensure continual downstream benefits to users. So, yes, it's going to be easier to integrate open source code into a GPL'ed environment. And, as it should be!"
Going through these exercises made that clear to me and it makes you *personally* think about whether that is good, or not. That's when I started considering purpose and also considering that the communities efforts are not unfairly taken advantage of. This is, as you are saying, something for all open source projects to think through. I saw a conversation in Drupal in 2005 that was very good. I quoted Dries in my piece. Wise words he made. The decision spared the community lots of heartache. It's not easy and I can see why it gets ignored in some projects - it's kind of like watching sausage made. It has forced change and some leave. Friends leave. We could write an entire whole book just on the human dynamics of it all. Proprietary software - which I use FAR MORE OF than open source - is *easy.* You look in your wallet and you see if you have enough to cover cost. You mentioned the legal complexities of proprietary software. I think the legalities of proprietary software are easy, too. You AREN'T ALLOWED to do anything! You can't share it, look at it, change it, for certain, you can't sell distribution! So, what is the purpose of open source? Why are we a part of this? It is impossible to deny, today, software *is* knowledge. Eben Moglen uses math as an example and you start to consider what would the world be like if math was tied up in licensing - useful only those who could pay?
For me, personally, I came to the conclusion that in our little open source projects, the least we can do is try to support open source. I also believe it's only a matter of time. This past six months alone, it's been like watching the Berlin Wall come down - Microsoft releasing source code? Java is GPL'ed? For crying out loud, during OSCON, Microsoft announced they applied for five (now I think we are down to 2) licenses from OSI! I could go on and on, but then, again, that's what I try to show on my blog. It's happening.
http://OpenSourceCommunity.org
http://OpenSourceCommunity.org
I'd like to note that the
I'd like to note that the WordPress bridge isn't anything Simple Machines wrote, so please stop latching on it to show how bad the team is. Are you saying that discussion on a WordPress bridge and a link (by a community member, not the team) to the component is now a GPL violation?
Hi Motoko-chan
The SMF Team is not *bad* - I just don't believe the team is making a responsible choice.
If SMF chooses to bridge into so many different GPL environments, then, choose a license that is compatiable. If SMF does not wish to have a GPL-compatiable license, then don't build bridges known to violate the GPL.
http://OpenSourceCommunity.org
http://OpenSourceCommunity.org
GPL Confusion
Sometimes I think the open source community is it's own worse enemy. They advocate what they like in the GPL and ignore what they don't like. All these variances in how the GPL is interpreted/enforced only weakens the GPL as a whole. No wonder the lawyers and judges are so busy...
GPL Confusion, indeed!
Even though those statements really do not say anything, hearing it worded that way can be disheartening to a project that is trying to do the right thing. It is best to be as specific as you can, to articulate the problem, and whenever possible, propose a solution. After four months of these discussions in Joomla!, it was obvious to me how little most of us knew about the GPL. What a learning experience! The more I learn, the more I realize I do *not* understand. One thing I respect about Joomla!'s approach is how they are not rushing. Here's an important statement from their June 15 announcement.
We're not going to make any sudden moves because we know that a lot of people are relying on us to maintain some stability and meet expectations. We are very much aware that a lot of people make their living around Joomla!, and we are sensitive to producing sudden disruptions in livelihoods. Joomla! is a unique project with unique needs and unique GPL issues. Solutions won't just come off the shelf.
And, they are keeping true to their word. All the best, Amy :)
Important notes
See the GPL FAQ on the FSF's site: http://www.fsf.org/licensing/licenses/gp...
In particular, this bit: "This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program."
In other words, in the case of SMF, the plugin would be dual-licensed under both the GPL and a license like the LGPL which has looser linking permissions. Alternately, the bridge plugin could be licensed under the GPL with an exception granting permission to link it with a non-free host application.
GPL compatibilities
-Bryan
That's part of it.
Jeff -
The bridge license is, indeed, part of the issue. It is not GPL compliant. As I understand it, it once was GPL'ed. But, someone used the code to create another bridge. The bridge license was changed to prevent that from happening again. SMF have stated they do not intend to GPL the bridge. The bigger part of the problem, though, is spelled out in the email exchange Bryan linked to between the FSF and SMF on 23 Jul 2007. SMF gives this as an example to the FSF:
Note: this conversation did not involve Joomla! It did not discuss Joomla! either.
First Script (GPL) <---> "Glue" Script <---> Second ScriptFSF was specifically asked by SMF "If the glue does have to be GPL (or LGPL), could the second script be then legally licensed under a non-compatible license?"FSF's response FSF's Brett Smith responded that "calling functions that are imported like this creates a derivative work, much in the same way that linking does for compiled languages." He responds that the bridge has to be GPL'd *as does the Second Script.* In this case, that would be SMF. The entire example would have to be GPL'd according to the FSF. So, simply GPL'ing the bridge is not enough. :(
Other ideas? I believe, Jeff, you said something in comments on my blog, as did someone else, that dependencies impact this, as well. If the bridge is completely dependent on the First Script (GPL) and the Second Script is not at all dependent on the bridge, that this could be a workable bridge if the bridge was GPL'ed. Are there examples of Drupal bridging to a non-GPL compliant environment in a manner that FSF approves? Those bridges might be worth exploring. These would be good methods to share between GPL projects.
Jeff and others, what's your
Jeff and others, what's your thoughts on the current SMFforum Integration module for Drupal? As I mentioned to Amy, I have some doubts whether it really does comply with the GPL. I hope I'm wrong though...I checked out the demo and it's the best Drupal/SMF bridge that I've come across.
I sure wouldn't assume it
I sure wouldn't assume it doesn't. There is a way of doing this! What I hope very much is that it *is* compliant - then we can look at it and use it as a model for bridging to non-GPL compliant worlds.
http://OpenSourceCommunity.org
http://OpenSourceCommunity.org
Hopefully...
That's an excellent question. I spent some time researching the issue a year or so ago, and came to the conclusion that such bridge modules were legal, given the ability to dual-license them under both the GPL and another GPL-compatible license that would allow integration with the proprietary software. After additional research, though, it's beginning to look as if that conclusion was premature.
I won't speculate anymore -- I've contacted the FSF myself and am in the middle of a pretty geeky/wonky conversation with one of their experts about the technical details, how various styles of development and distribution might affect the issue, and so on. I don't want to shoot off my mouth and give anyone bad advice but I promise I'll post my best attempt at a detailed summary when I'm able to get some of these questions nailed down.
Thanks for the work you guys have been doing in bringing these questions to the foreground!
Thanks to you, Jeff, for
Thanks to you, Jeff, for exploring this. I look forward to your response.
http://OpenSourceCommunity.org
Prelude
Jeff, I have a feeling the "work" we're doing in bringing these questions to the foreground are only a prelude to the answers and more questions you are likely to follow with. This is good stuff for any open source community to revisit from time to time. Looking forward to your interpretation of what the "lawyers" at FSF are saying.
BTW - when you look at the
BTW - when you look at the license text in the smf_api_2_zip for the Drupal / SMF bridge, it is proprietary, not GPL'ed or LGPL'ed.
http://OpenSourceCommunity.org
Typo in the Title
Ok...someone could have told me that I had a typo in the title of this post. I had spelled "application" as "appliation" . Perhaps everyone is just getting used to my careless fingers at the keyboard. The title has been corrected.
xml/rpc
If the applications used xml/rpc to talk to each other then surely there would be no license violation.
xml-rpc would work.
That is true. There are ways to build GPL-compliant bridges, including xml-rpc. Those avenues were discussed between SMF and Joomla!, but SMF announced:
"As stated earlier we were in communication with the Joomla! team in regards to building a bridge that was compatible with their license. The exchange is now over and, sadly, we have decided that the cost of building such a bridge is too great."
http://OpenSourceCommunity.org