If I understood the LGPL correctly, licensing concerns shouldn't be an issue here. The LGPL permits to redistribute any code that is LGPL under the terms of the GPL: QUOTE from http://www.gnu.org/licenses/lgpl.txt: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. [...] QUOTE END That means that there shouldn't be any problem with publishing LGPL licensed libraries with Drupal, or via Drupal's auto-GPL-ing CVS repository. This doesn't mean that I'm in favor of filling drupal's CVS with 3rd party libaries, though - IMO, there are cases where a laxer cvs policy would be a good thing, e.g. for small jQuery plugins. Where to draw the line - I dunno. As long as allowing TinyMCE to be redistributed via drupal's CVS repo doesn't mean too much of work for the Repo maintainers, I don't see convincing reasons for not allowing it, though. regards, frando Kevin Reynen schrieb:
I've been working the TinyMCE issue queue for a few months now. IMHO, a large number of the issues users have would be eliminated by including Moxiecode's TinyMCE code in the module with a default configuration that allows all valid HTML... eliminating both the two step install issues as well as the double filter issue. This would both make users happier and free up more of my time.
Originally, I was concerned about GPL vs. LGPL. When I asked for advice about that, JohnAlbin advised me that I could distribute LGPL code with a GPL project. I'm not GPL expert so I asked Moxiecode how they interpreted the licensing and they don't have an issue with including their code with the TinyMCE module (http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=21769#p21769).
Now Borris is saying the issue isn't GPL vs. LGPL, but policies specific to Drupal's CVS and because some of the key Drupal maintainers are "WYSIWYG haters", I'm not going to get any support I'd need for waving the "no foreign code in CVS" policy. I understand why many developers don't like WYSIWYG toolbars on principle, but a solid WYSIWYG is often key to making Drupal installs user friendly enough for the non-developers/SMEs who are (hopefully) doing the majority of the content work. If it wasn't for WYSIWYG, I'd be deploying something other than Drupal that has a solid WYSIWYG option.
There are many legitimate reasons not to support this request, but please don't make it more difficult to distribute a better WYSIWYG editor because in your ideal world everyone knows HTML and there is no need for WYSIWYG. How many people learned to write postscript because a sysadmin didn't install print drivers?
Another potential solution we've discussed is pointing users to a TinyMCE download outside of Drupal.org's CVS that includes the Moxiecode code. This is easy enough to do, but would result in TinyMCE dropping off of any top download lists. IMHO, lists like Greggle's Download Statistics for April are really important to help new users determine which contrib modules are stable and supported. Nothing draws a crowd like a crowd. If webchick's IA redesign (http://groups.drupal.org/node/3769) is any indication, it seems the trend is to do more with these stats in the future. I'd hate to choose between forcing new users to rely on "word of mouth" to find TinyMCE and making it a better, more user friendly module.
I'm hoping I've made the case for why I want to include the TinyMCE code in the module as well as why I'd like to see that code continue to be distributed through the Drupal CVS instead of taking it offsite.
Anyone have an option we haven't thought of?
- Kevin Reynen