By far the top issue with TinyMCE are install issues. Of the install issues, the two step install process is the #1 problem users have. I don't think the Moxiecode releases can be included with the module because Moxiecode releases their code with an LGPL license and everything in CVS gets a GPL license automagically. Jeff Eaton wrote about the Drupal and GPL back in February of last year. He used TinyMCE as one of the examples of a module that connects Drupal to non-GPL'ed code.
I believe I can distribute versions of the TinyMCE module that include the Moxiecode LGPL code on sites other than Drupal.org. Is that right?
I still think that the module development belongs in CVS, but the time it takes to role a separate distribution for users who simply can't figure out that they need to download something from Moxiecode in addition to the module would more than make up for it.
Anyone have thoughts about this?
Comments
Doing it already...
We're doing it already with the Bryght Basic install profile in our SVN repo (https://svn.bryght.com/dev/browser/bryghtbase/DRUPAL-5/trunk/modules/tin... -- yeah, I know, I need to move that to the proper version). With the appropriate plugins pre-configured, etc.
I would happily contribute infrastructure for this (e.g. a dedicated SVN repo). Are we taking on too much? Or will this save us support requests?
HOWEVER....potentially this can be something that moves back to d.o. as part of packaging scripts for install profiles. That is likely longer term.
CVS adding GPL to someone else's LGPL project
The issue was really that the Drupal.org CVS system adds a GPL license to someone else's code. I finally got a response from Moxiecode and they are OK with that, so I don't see any reason not to add the TinyMCE code to the module.
I'd also like to configure TinyMCE to allow all valid XHTML tags by default to eliminate the double filter issue. This makes TinyMCE a bit bigger, but I think it's more reasonable to expect the people wanting to tweak for performance to make changes than the average user.
Does anyone have an issue with that?
More than that issue
It's not just GPL: the policy is not to include local "foreign" code and bulk up the size of our CVS repo...regardless of license. You're welcome to bring it up, but I can guess that the answer will be no.
If we were in SVN, a simple svn:external setting would be lovely. This MAY be something that the install profile creator that dww is working on can eventually handle: fetch a remote URL / download and include in the tarball.
Re: TinyMCE valid XHTML by default. +1 from me. Can it do something about embeds, etc. as well?
Well, that was "fun" while it lasted
For those of you who missed the debate that followed my post to the Drupal Development list about including a customized version of the LGPL TinyMCE code in CVS so it could be included with the module, I'll try to recap the highlights of the 100+ messages exchanged this week on the topic.
Gerhard Killesreiter original response is one of the few that made sense. Basically, yes it is a pain for users but the people maintaining CVS don't have time for the problems the additional code would cause. OK. That makes some sense, but without the _src.js files the additional code could be paired down to 200 files. If Drupal's CVS or the people maintaining it can't deal with 200 more files, what happens when there are 20 more 10 file modules?
The reality is I can't do what the Gerhard does for Drupal.org, so discussion could have stopped there... but then Jeff Eaton responded "there's no reason to even offer a CVS repository but convenience". 100+ messages and several debates about security, rebuttals to the security issue, suggestions to automate the inclusion of 3rd party libraries with CVS code when the tars are created, Derek Wright letting people know he is not going to write those install scripts, a recap of JQuery plugin needs, a review of GPL, the GPL issues with themes, discovery that Jeff Robbins has been ignoring the 3rd party code policy, Jeff telling everyone they are on crack, a Gerhard's final response that if the code can be found somewhere else, it doesn't belong in Drupal's CVS.
I'm sure I miss some important points, but you can read the whole elightening exchange yourself.
So after all of that, the answer is the same. A version of TinyMCE module that includes a Drupal customized version of TinyMCE will not be distributed using Drupal's CVS or on Drupal.org. IMHO, adding the files modified from Moxiecode's default TinyMCE distribution will only make the install process more complicated.
I really want to see TinyMCE for Drupal evolve into something more like what WordPress distributes as part of their core. Something that works for 80% of the users "out of the box" and still allows to other 20% to replace the Drupal specific version of TinyMCE with Moxiecode's default download or some other custom configuration.
IMHO, we have to move past this double filter nonsense and distribute an install that doesn't require so much support if we're every going to make any real progress. The real question is where/how to host this so that I'm not the only person with access? SourceForge? Google Code? Custom SVN like the i18n group?
Thoughts?
Custom SVN
I'm happy to donate a dedicated VPS box for this. We have images that are SVN / Trac bundles. Trac likely not needed. Let's think about what we need.
Kevin, email me and I'll get the box setup.
Custom svn the way to go, for now
As was discussed (Kevin, great recap, btw :) ), a Drupal-specific release of TinyMCE would be a Very Good Thing -- stripping out the non-essential files, enabling the compressor and (maybe?) the spell-checker, would get things moving forward pretty well --
As a second pass, perhaps creating a sample profile or two?
Kevin, thanks for taking the time to open this thread again, and Boris, thanks for putting time and resources behind a solution.
Down the road, though, it would be nice to have these types of issues handled on a case by case basis -- As the most recent thread illustrates, it will be difficult to come up with a policy that satisfies everyone. Handling these issues on a case by case basis would allow these projects (and the development effort behind them) to be centered on d.o --
Cheers,
Bill
FunnyMonkey
Tools for Teacher
FunnyMonkey
Good summary
Very true. I've been following the debate and I feel sad for the users that it didn't end in a policy change or at least an exception for one of the most important modules (whatever the WYSIWYG-haters say, the popularity of the module speaks otherwise). It would make more sense for so many reasons already mentioned in the discussions.
Anyway, good to see that other ways are being worked on for now.
Why not inside CVS?
I know that Boris has already commented on this issue, but I thought I would point out this discussion on the drupal-devel list.
I encourage everyone to read that thread, but the important point to note is that ”the LGPL permits the relicensing of any single copy of an LGPL library from LGPL to GPL (article 3 of the LGPL).” So Moxie’s TinyMCE LGPL code could be relicensed with the GPL and put into drupal’s CVS. Again, make sure you read the thread for some arguments for and against doing this.
I’m personally in favor of taking the jscripts/tinymce folder from Moxie’s tarball and putting it in CVS. While adding a note on where to get the full distribution in the TinyMCE module README.
The ease in installation for users far outweighs the pitfalls, IMHO.
- John (JohnAlbin)
Agree
I'll second that. I've been following the issues for TinyMCE since late last year and this is one thing that keeps coming up (that and the missing $script in themes).
Btw I'm really excited about all the good stuff coming to TinyMCE.
Pointing out policy
I was just pointing out current drupal.org policy. Esp. with the WYSIWYG haters, it's likely going to be hard to convince d.o. maintainers to allow external code to be checked in. Repeat: this is NOT GPL vs. anything, it's about having "foreign" libraries that are maintained externally ALSO checked into CVS.
I am more than happy to discuss, eg., maintaining a read only SVN mirror that has the TinyMCE code merged in.