This is not totally correct, if foo, bar and baz need to include
external code then so be it. Imagine tinyMCE needed to change pages of
configuration files, why should users have to go through all that
trouble? And how many modules do we really have that require huge
external libraries? Finally, why should we assume that module developers are irresponsible enough to fill the repository with garbage?<br>
<br>
I don't understand what's so inconvenient in allowing external files.
In the end they will be "packaged" in one .tar.gz and that's where it
ends. The module authors are responsible for maintaining them and I
doubt they'll be stuffing unnecessary files in there. I don't
like WYSIWYG modules either, but that has nothing to do
with this issue.<br>
<br>
As far as I know, according to GPL if you change anything in the files the code
is "yours". I don't know about LGPL though. And no, you don't have to
change every file since this is how linux works, surely ubuntu doesn't
change all of debian's source files to call it ubuntu. Change the configuration files of
the TinmyMCE and according to GPL (LGPL?) the code is yours, you're no
longer posting code that's external. Any GPL or GPL gurus knowledge on
this is welcome since my knowledge on it may not be totally accurate.<br><br><div><span class="gmail_quote">On 5/21/07, <b class="gmail_sendername">Frando (Franz Heinzmann)</b> <<a href="mailto:frando@xcite-online.de">
frando@xcite-online.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If I understood the LGPL correctly, licensing concerns shouldn't be an
<br>issue here. The LGPL permits to redistribute any code that is LGPL under<br>the terms of the GPL:<br><br>QUOTE from <a href="http://www.gnu.org/licenses/lgpl.txt">http://www.gnu.org/licenses/lgpl.txt</a>:<br> 3. You may opt to apply the terms of the ordinary GNU General Public
<br>License instead of this License to a given copy of the Library. To do<br>this, you must alter all the notices that refer to this License, so<br>that they refer to the ordinary GNU General Public License, version 2,<br>
instead of to this License. [...]<br>QUOTE END<br><br>That means that there shouldn't be any problem with publishing LGPL<br>licensed libraries with Drupal, or via Drupal's auto-GPL-ing CVS<br>repository.<br><br>
This doesn't mean that I'm in favor of filling drupal's CVS with 3rd<br>party libaries, though - IMO, there are cases where a laxer cvs policy<br>would be a good thing, e.g. for small jQuery plugins. Where to draw the
<br>line - I dunno. As long as allowing TinyMCE to be redistributed via<br>drupal's CVS repo doesn't mean too much of work for the Repo<br>maintainers, I don't see convincing reasons for not allowing it, though.
<br><br>regards,<br>frando<br><br>Kevin Reynen schrieb:<br>> I've been working the TinyMCE issue queue for a few months now. IMHO,<br>> a large number of the issues users have would be eliminated by<br>> including Moxiecode's TinyMCE code in the module with a default
<br>> configuration that allows all valid HTML... eliminating both the two<br>> step install issues as well as the double filter issue. This would<br>> both make users happier and free up more of my time.<br>>
<br>> Originally, I was concerned about GPL vs. LGPL. When I asked for<br>> advice about that, JohnAlbin advised me that I could distribute LGPL<br>> code with a GPL project. I'm not GPL expert so I asked Moxiecode how
<br>> they interpreted the licensing and they don't have an issue with<br>> including their code with the TinyMCE module<br>> (<a href="http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=21769#p21769">http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=21769#p21769
</a>).<br>><br>> Now Borris is saying the issue isn't GPL vs. LGPL, but policies<br>> specific to Drupal's CVS and because some of the key Drupal<br>> maintainers are "WYSIWYG haters", I'm not going to get any support I'd
<br>> need for waving the "no foreign code in CVS" policy. I understand<br>> why many developers don't like WYSIWYG toolbars on principle, but a<br>> solid WYSIWYG is often key to making Drupal installs user friendly
<br>> enough for the non-developers/SMEs who are (hopefully) doing the<br>> majority of the content work. If it wasn't for WYSIWYG, I'd be<br>> deploying something other than Drupal that has a solid WYSIWYG option.
<br>><br>> There are many legitimate reasons not to support this request, but<br>> please don't make it more difficult to distribute a better WYSIWYG<br>> editor because in your ideal world everyone knows HTML and there is no
<br>> need for WYSIWYG. How many people learned to write postscript because<br>> a sysadmin didn't install print drivers?<br>><br>> Another potential solution we've discussed is pointing users to a<br>
> TinyMCE download outside of <a href="http://Drupal.org">Drupal.org</a>'s CVS that includes the<br>> Moxiecode code. This is easy enough to do, but would result in<br>> TinyMCE dropping off of any top download lists. IMHO, lists like
<br>> Greggle's Download Statistics for April are really important to help<br>> new users determine which contrib modules are stable and supported.<br>> Nothing draws a crowd like a crowd. If webchick's IA redesign
<br>> (<a href="http://groups.drupal.org/node/3769">http://groups.drupal.org/node/3769</a>) is any indication, it seems the<br>> trend is to do more with these stats in the future. I'd hate to<br>> choose between forcing new users to rely on "word of mouth" to find
<br>> TinyMCE and making it a better, more user friendly module.<br>><br>> I'm hoping I've made the case for why I want to include the TinyMCE<br>> code in the module as well as why I'd like to see that code continue
<br>> to be distributed through the Drupal CVS instead of taking it offsite.<br>><br>> Anyone have an option we haven't thought of?<br>><br>> - Kevin Reynen<br>><br><br></blockquote></div><br>