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

[Kevin Reynen]

I understand the slippery slope argument.  If this is a situation
where the reasons would have to compelling enough to include a
specific K of "foreign code"... who would make that decision?

Unfortunately, I don't know enough about CVS to know how this creates
more work or who does that work?

If the answer from the people doing the work is that there is never
going to be a reason compelling enough to allow any amount of foreign
code, that's all that needs to be said and we can move on.

Then I'm left with asking for a recommendation about distributing an
"official releases" of the TinyMCE module outside of Drupal's CVS and
as well maintain the module-only CVS version or leaving the multi-step
install in place?  I have no doubt a one step distribution would be
more popular, but I think this sets an equally poor precedent to have
such a popular module distributed outside of Drupal.org.

- Kevin Reynen

On 5/21/07, Frando (Franz Heinzmann) <frando at xcite-online.de> wrote:
> 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
> >
>
>