[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?

[Kevin Reynen]

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