since this module bridges drupal with a tool that is licensed in a way that is completely incompatible with the GPL in a way that directly accesses the api's of both drupal and the gpl-incompatible code, I'm pretty sure that this module can not be licensed under the gpl and therefor should not be distributed via drupa.org or placed in the drupal cvs repository.

Comments

gmustuk’s picture

gmustuk commented

Why not? There are modules on here that integrate with other commercial programs (IPB discussion board software). This is simply a module which helps integrate a third party app...and is making it available for others to use and distribute. It does not contain the actual commercial software (which is needed to purchase elsewhere).

ericg’s picture

ericg commented

the way in which you link a gpl incompatible tool to one licensed under the GPL is critical to where it sits on the ok/not ok spectrum.

this module can directly call both drupal internal functions and internal functions of the gpl incompatible system. There is no rest, http or other external api/data interchange, there is a direct link between the two. That violates the GPL. Since drupal is a GPL licensed tool and there is a policy of only hosting GPL compatible software on this site and in the repository, I strongly believe that this module should not be hosted here.

It does not need to contain the commercial code to violate the GPL, the way the module is coded, as a bridge to connect the core of two systems one of which is licensed in a completely GPL incompatible way is in itself a violation of the GPL.

If you don't want to comply with the GPL, don't build on GPL tools. The model represented by this module is extremely problematic in my opinion and I'm not sure the most appropriate way to bring this to a larger audience so it can be decided on in a formal way.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Subscribing.

My understanding is that bridge code is OK as long as the interface between the bridge code and the non-gpl code is sufficiently "arms length" that at no time is there a call stack that includes both GPL code and non-GPL code. So, XMLRPC, for example, is an acceptable way to interface a service but direct php function calls are not.

I haven't inspected this module to say one way or another whether the code works and is licensed properly or improperly.

@ericG - since you have researched this it would be useful if you could point to the lines of code that create an inappropriate tie between the code.

ericg’s picture

ericg commented

greggles,

start with the fact that the module is not GPL in its own license, lines 8 and 9
* The WysiwygPro module is public domain software.
* Licensed under the terms of the GNU Lesser General Public License:
(while the lgpl is gpl compatible i thought a decision was made that only GPL code was to be distributed via drupal.org)

but where it really crosses the line is where it links directly to the two systems. There is no rest/xmlrpc/http interface/calls being made, this module fully integrates non-gpl compatible code into drupal.

see lines 768 through 969.

both systems are being directly called. I can call all wysiwygpro php and js functions directly via php from within the drupal module. this is , in my understanding, a violation of the GPL

(for example here --lines 764-766 -- it inserts non GPL compatible php and js functions directly into drupal)
function wysiwygPro_process_textarea($element) {
include_once( drupal_get_path('module', 'wysiwygPro') . '/wysiwygPro/wysiwygPro.class.php');
drupal_add_js( drupal_get_path('module', 'wysiwygPro') . '/wysiwygPro.js' );

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

ericg - we don't allow gpl compatible code into cvs.drupal.org if that code is part of another project that is easily available elsewhere on the internet. So, since this is not part of another project easily available elsewhere on the internet it passes that test. Since the policy is that all code committed to cvs.drupal.org must be gpl, something that's LGPL or public domain basically becomes GPL when it is committed. See http://drupal.org/node/66113

Now - the second part - about whether the style of the integration is acceptable - yep, I totally agree. This looks like it would be possible to do a debug_backtrace from inside wysiwygPro_process_textarea and see a mix of the Drupal GPL code with the third party code. Which, AFAIK, would be a problem based on the FSF interpretation of the GPL.

ericg’s picture

ericg commented
Status: Active » Postponed

greggles, thanks for the details. I had no idea that lgpl or public domain code could shift license simply by being put in the repository. Interesting. I'll have to look into that more at some point.

I'm going to set this issue as postponed, as I found the right place to bring it up.

for future reference: If you ever have a question about a gpl violation within drupal modules the right thing to do is to report it at http://association.drupal.org/contact (select 'Report a GPL or CC violation" from the category menu.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

@ericg - I'd say this is very much active. And I agree that the association is a good place to report it (it's how I (Greg Knaddison) found out about this thread, though my comments here are my own and not any sort of official stance) but also creating an issue is important.

webchuck’s picture

webchuck commented

I really don't understand all this license stuff, and apologize if I have posted something that doesn't belong here.

Truthfully, I will not be the one hurt if we pull this from d.o, but rather the many users who will never find this module. It's an easy-to-use module that integrates a powerful, configurable editor into Drupal, something that is sorely lacking. If we aren't willing to allow this type of software integration, we're shooting Drupal in the foot.

To quote Dries quoting Bill Gates,

"Who can afford to do professional work for nothing?"

and

Drupal is not incompatible with business.

Anyway, I've voiced my opinion. Let me know what I need to do.

broeker’s picture

broeker commented

You can argue all day long over the semantics of the GPL and what constitutes linking but there are valid arguments on both sides of the issue. To suggest otherwise is unreasonable and until there is some clear legal precedent you can only do what makes sense without blatantly violating the spirit of the GPL. In this case, there is no commercial or non-GPL code being distributed. The software in question, Wysiwygpro, was not built with the purpose of linking into Drupal. It exists on its own, independently, and existed long before this Drupal module. That it can be enabled, by choice, using a few trivial lines of code should not constitute linking in my opinion (IANAL). The open source world at large seems to agree as there are also very successful Wysiwygpro plugins available for both Wordpress and Joomla, two of the largest most visible open source projects in the world. It would be a mistake for Drupal to ban modules like this one based on somebody's personal interpretation of the GPL, even if that interpretation may have some validity. Maybe someday Richard Stallman will grasp the full gravity of the situation and summon a team of long-haired lawyers to bring the hammer down on Joomla, Wordpress, Drupal and the rest of the open source world but until then it is good for the users, it isn't harming anybody, and it should be left to flourish as the community sees fit.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

In slightly different order...

The open source world at large seems to agree...

See http://jcd-a.org/ I don't think that there is a consensus on this. The lack of gpl enforcement by a project doesn't constitute agreement with the linking of modules which are non confirming.

based on somebody's personal interpretation of the GPL

Great. Except this discussion is not based on somebody's personal interpretation. It's based on discussions with lawyers from the FSF (see
http://lists.drupal.org/pipermail/development/2007-August/026130.html )

That it can be enabled, by choice, using a few trivial lines of code should not constitute linking in my opinion

This is not the opinion of just anyone, but it is the opinion some lawyers that were hired to help clarify what Drupal modules can and can't do.

Drupal already has a dozen or so WYSIWYG editors. I don't think yet another one is really going to make the project take off. IMHO, we should let the WYSIWYGPro folks distribute this module.

broeker’s picture

broeker commented

Thanks for linking that Drupal thread -- I was not aware of the official input from FSF on this matter. And by consensus I didn't mean that everybody in the world agreed, just that two very large, high-profile projects have chosen a different interpretation or, at the least, have chosen to ignore the issue (option 3 from the post you linked).

p.s. On an unrelated note, Wysiwygpro is not just another editor, IMHO. Rather it provides an integrated and elegant solution to one of the most vexing problems faced by any modern-day CMS: letting non-technical users easily manage, catalog, and insert images, documents, and media files directly into their content. Yes, I know there is img_assist, TinyMCE plugins for ICME, Asset Manager, etc. but none of them come even close to the ease of use and power of Wysiwygpro. That it is also one of the best editors available is icing on the cake.

ericg’s picture

ericg commented

The software in question, Wysiwygpro, was not built with the purpose of linking into Drupal. It exists on its own, independently, and existed long before this Drupal module. That it can be enabled, by choice, using a few trivial lines of code should not constitute linking in my opinion (IANAL).

I have no problem with the software existing, but I do have a problem with a clear violation of the GPL (as it is currently understood and interpreted by the Free Software Foundation) being distributed via Drupal.org's site or repository

The way drupal is built, a module needs only a few lines of far-from-trivial code to violate the GPL. there is nothing trivial about the lines of code that make the module work (take away those "trivial" lines and the module becomes non-functional)

The open source world at large seems to agree as there are also very successful Wysiwygpro plugins available for both Wordpress and Joomla, two of the largest most visible open source projects in the world.

Drupal should lead, not follow.

Many of the people involved with drupal have decided to use drupal over wordpress or joomla because drupal takes things like the GPL and its role in the larger Free Software world more seriously than other projects.

If we aren't willing to allow this type of software integration, we're shooting Drupal in the foot.

I believe it is just the opposite. Unless we take a strong stand and be clear that the GPL is not just a cute idea, we will be shooting drupal in the foot. As well, there are already a number of existing modules that do everything this module does. Isn't the community better served by not allowing a proprietary tool to divert energy, money and development time from other free software projects?

until then it is good for the users, it isn't harming anybody

I completely disagree. The damage to the community and users far outweighs the usefulness of this module. If drupal ends its policy of only hosting GPL code and only allowing for module development that is compatible with the GPL, it is very very bad for the entire userbase. it is harming the Free Software community as a whole if we ignore the GPL.

Drupal is not incompatible with business.

this is true. Drupal is very compatible with business. I myself run a consultancy that makes a large percentage of its money using drupal (and other free software tools). The GPL is not anti-business, although there are some business models (such as the one represented by this module) that are clearly in opposition to the GPL.

If you don't want to follow the rules of the GPL build your modules for proprietary software.

In my opinion, allowing this module to be distributed via drupal.org would be a terrible precedent to set.

broeker’s picture

broeker commented

ericG: I admire your conviction and have to admit you are swaying my opinion. As I mentioned above I was not aware that the FSF had already weighed in so strongly. Out of curiousity:

1. Have you surfed the rest of the 3rd party integration category? I did a quick check and found several modules integrating with third party apps are not GPL. I did not check functions etc. to see how the integration was done but I'm curious if other similar modules already exist on d.o. in violation of the GPL.

2. Would you object to creating a link to this and similar modules, hosted off site somewhere by the developer? This way people can still find the module(s) under the Modules area, but Drupal is not hosting or distributing any code.

ericg’s picture

ericg commented

broeker: thanks for being open to what I'm suggesting.

1: I just did a quick look through the 3rd party integration category. For the most part, the 3rd party integration modules integrate drupal with GPL compatible software. In nearly every case where there is a linkage to non-GPL compatible software it is done "at arms length" via calls to an external api (using xml, http, rest, soap), and such integration methods are considered valid in my understanding of the Free Software Foundation's interpretation of GPL. Of the 223 modules in that section, I find less than 10 that I will look into in more detail when I can find the time, as I think they might also be problematic.

2: yes I would object to such links. GPL violating code should get no publicity here. Those that release proprietary modules have by their actions defined themselves out of the community as a whole and as such should not get the benefit of search ranking, attention, etc that would come from such a link.
I think one of the things that is confusing to users of other F/OSS tools mentioned in this thread (and the source of endless questions from folks that contact me for Free Software advice) is the mix of F/OSS and proprietary add ons that you can get to via those sites. I would really prefer if drupal did not follow that model. If the GPL violating code modules are really that great, search engines will lead users to them over time. While I'm concerned with the existence of drupal modules that violate the GPL, I don't have time to worry about how to force people to not distribute it themselves, but I do have the time to advocate that drupal not provide infrastructure/support/links to tools that violate the GPL.

ericg’s picture

ericg commented

a few more random thoughts on this:

The Free in Free Software is talking about rights, not cost. If I use wysiwygpro, I have no rights to fix the bugs, no rights to share my fixes with the rest of the drupal community.

Strictly speaking, because of the commercial license attached to the tool, no one other than the owners of the software can help work on the issues currently reported at http://drupal.org/project/issues/wysiwygpro

Should I work on a fix anyway because a client needs the tool to function and the folks at wysiwygpro decide that my input is welcome despite not being legally protected by license, my efforts will then be re-sold to my client and others in the drupal community with the next upgrade to the commercial tool. I'd rather see such energy and labor hours go into the existing f/oss tools/modules so it benefits the community as a whole.

Just providing the resources of the issue tracker to such a tool is of concern to me. Why provide community resources to commercial tools?

With that off my chest, I have to get back to work. I'm going to do my best to avoid becoming obsessed with this thread and let the folks at the Drupal Association take the time they need to review this issue.

vizimetrics’s picture

vizimetrics commented

As the owner of ViziMetrics, the company that markets wysiwygPro... it's fascinating to see the depth of GPL conviction in this thread.

To make things clear... the Drupal wysiwygPro module was created by a Drupal user, not by us. We communicated with the author about the interface code and were glad to do so, because we get regular requests from many Drupal users for a wysiwygPro module. The demands of our other projects have prevented us from developing anything for the Drupal community ourselves. We originally objected to the GPL license and wanted it to be a commercially available plugin only. The author argued for GPL... and we eventually came to an agreement on how we thought it could work.

As of this date, we are not even actively supporting the module, but are referring all support issues to the author. Once the module makes it past the beta phase, we would be supporting it more directly.

This module was not meant to violate anything in GPL or offend anyone's personal ethic or legal opinion. The module WAS intended to provide a simple bridge to allow Drupal users to purchase and use wysiwygPro if they made the choice to do so. We saw no harm in that. But from the content of this thread, I'm thinking I'll probably have to hire a GPL lawyer before I ever do anything GPL related again (and then I'll have to raise my prices accordingly! just kidding!)

Frankly, as a developer and marketer of both commercial and publicly licensed applications... I find the Open Source "purist" position stiffling and restrictive.

If people think a piece of software is worth the price of a commercial license, then let the free market rule. Why impose an artificial restriction. If the Open Source community's only road to fulfill its mission is to hide its head in the sand and pretend that the commercial world doesn't exist... then that will be its downfall. If the Open Source community cries "foul" because someone came up with a way to use a piece of paid software differently... then that's a sad day indeed. It's not a good thing to try to "over-legislate".

As for us... we had no internal intention to develop this module ourselves. Will we benefit because the module exists...? Probably, a little. But we're not laughing our way to the bank by any means. It will probably take at least a few years before there is any return to speak of on the time and development investment we will put into this if and when we take it out of the beta phase.

However... I'm willing to speak with the author about pulling it completely if that's what the community wants. We thought the module was a good thing for Drupal users and for us. If it turns out to be a source of controversy and discontent, then we would just as soon not deal with it.

We are open to hear your further comments and suggestions.

Tim Milo
ViziMetrics

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

@Tim - thanks for the response.

To the extent that your module is integrated with Joomla or WordPress or (other GPL platform) in this same manner and to the extent that you care about those markets and to the extent that this interpretation of the GPL is valid, you should be hiring that lawyer and should research a new form of bridging because those code bases are also GPL and therefore your module would also potentially be in violation of the licenses of those projects. A change in the way the module is applied now could remove a lot of legal trouble in the future...

One comment is that you painted the "Open Source" world with a very broad brush and do so rather inaccurately. The LGPL and BSD licenses, for example, are "Open Source" and are not as restrictive in the way that the GPL is with regard to bridging the Open Source code and a proprietary code base.

About removing the module from drupal.org and supporting it elsewhere I think that would be premature now, but I'm glad to hear that you are open to that.

Thanks again,
Greg

kenfar’s picture

kenfar commented

I just happened to stumble across this conversation thread today and as I read it I found it very fascinating and sad at the same time. I recognize that I am just some dumb, simple minded user, who decided that I was going to try and build a nice, simple website for my Boy Scout Venturing Crew. Drupal as a CMS was pretty intimidating at first, but you know there was one module that helped me out tremendously and that was Whysiwig Pro. It installed perfectly the first time and when I had a very minor issue, I emailed the guys at ViziMetrics who then forwarded my email to the module developer Chuck and he responded to me within a couple of hours and helped me very quickly resolve my issue.

My web site is up and running and I work on it every day to help benefit my Venturing Crew. I tried several of the other (free) whysiwig modules but they really didn't work well unless a person is fairly competent at some amount of coding in more than one language generally.

I understand and respect all of the opinions that have been recited in this thread. I very much appreciate open source software. But sometimes as the old saying goes -- "One can cut off their nose to spite their own face"

This is an excellent module which has definately helped me and I am sure will help bring Drupal to many other users as well who want a great program but have very little coding experience.

Regards,

Project: » Lost & found issues

This issue’s project has disappeared. Most likely, it was a sandbox project, which can be deleted by its maintainer. See the Lost & found issues project page for more details. (The missing project ID was 220415)