Jeff Eaton wrote:

The GPL requirement makes perfect sense. But it's not like anyone is asking the CVS repository admins to make sure that the TinyMCE libraries are up to date, neh? In fact quite the opposite. Many times you have to specify exactly which version of the third party library to download because you haven't had time to rewrite the module to enable compat with the newest release, etc. This does lead to a lot of confusion. While I agree that maintaining shadow copies of third party CVS libraries isnt "fun" it is useful and can be an efficient way to deal with helping our users maximize the usability of drupal. And i think that most module maintainers would rather deal with periodically updating their 3rd party code than weed out all of the bogus bug reports and hand hold users who are attempting to install and configure their modules one at a time. In any event shouldnt we leave it up to the maintainer at least to determine which is most efficient to their circumstance?

-- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org

On 5/21/07, Johan Forngren <johan@forngren.com> wrote:

Is it possible to do some packaging/tagging magic? Have one ready-to-go and one almost-ready-to-go release?

Potentially an upgrade to install profile / packaging scripts could do this. handling arbitrary external code / download pulls is an order of magnitude harder to get right. Completely random guess-timate, but I would say $4K for this part alone, to get it right/secure/etc. But it would be SOOO nice..... -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com

I cringe bringing this in but, this conversation covers smaller scripts such as jQuery plugins of which there are several in CVS. These are scripts that, uncompressed, are only a few kilobytes in size. Not having an easy way for users to install these modules creates a big barrier for entry[1] for new drupalers. While we may not have a problem installing outside scripts, is this a barrier worth doing something about? I would prefer to see an installer that can download and install the outside scripts securely. But, there just isn't enough time before the code freeze, as far as I can tell. So, that leaves 3 options. 1) Leave things just as they are with no outside libraries in CVS. 2) Allow them in CVS with some sort of criteria for entry. 3) Allow them in for now with a future path to have an outside installer I would prefer to include them lowering the barrier for entry and put building a better installer on the the to do list. But, I can live perfectly fine with #1. Just my 2 cents. - Matt [1] http://headrush.typepad.com/photos/uncategorized/2007/04/06/ incremental1.jpg On May 21, 2007, at 6:03 PM, Gerhard Killesreiter wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Michael Favia schrieb:

...

Jeff Eaton wrote:

...

The GPL requirement makes perfect sense. But it's not like anyone is asking the CVS repository admins to make sure that the TinyMCE libraries are up to date, neh? In fact quite the opposite. Many times you have to specify exactly which version of the third party library to download because you haven't had time to rewrite the module to enable compat with the newest release, etc. This does lead to a lot of confusion. While I agree that maintaining shadow copies of third party CVS libraries isnt "fun" it is useful and can be an efficient way to deal with helping our users maximize the usability of drupal. And i think that most module maintainers would rather deal with periodically updating their 3rd party code than weed out all of the bogus bug reports and hand hold users who are attempting to install and configure their modules one at a time.

If that proves neccessary you should write some docs. Although e.g. listhandler module isn't one of the really easy modules, I don't notice many issues with it. The docs are short but to the point and seem to help.

...

In any event shouldnt we leave it up to the maintainer at least to determine which is most efficient to their circumstance?

They are already free to determine what is best for them and their module. They are not free to commit to CVS what they want. They are free to host a "my module with everything you ever needed to run it" somewhere else.

Cheers, Gerhard

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGUhdEfg6TFvELooQRAmTQAKCUUVMhxRytFP4qfCexn9zfSjlzggCcDDuh 0rSi+bsoDsuDHWVhsWxZgQQ= =0DSQ -----END PGP SIGNATURE-----

Is this something that could be handled technologically? The balloon-CVS argument for foreign code is valid, IMO, but so is modules that rely on foreign code being too hard to install currently. I know we can't install extra code via the UI for security reasons, but would it be possible to include a small shell PHP script with the TinyMCE module that would download the latest TinyMCE from moxie, untar it, and put it where it belongs? The install hook for the module could then have a drupal_set_message() "Module installed, please remember to run gettinmymce.php from the command line" or something like that. It's similar to the way some Linux distros handle non-free media codecs. Something that wouldn't require reading the README file to figure out. Possible? Reasonable? (Two separate questions. <g>) --Larry Garfield On Mon, 21 May 2007 14:38:58 -0400, Andre Molnar <mcsparkerton@yahoo.co.uk> wrote:

Kevin Reynen wrote: <snip>

I think the issue has little to do with hatred of WYSIWYG. As I understand it, the problem is that it would set a bad precedent for CVS usage.

Lets take the case of module foo that is simple small lightweight interface between Drupal and some massive external library. With the current rules module foo is only 10K in CVS. If module foo included the external library as well - foo suddenly grows to 300K.

But foo is really important to people - and people really like foo and people complain about foo's install process (having to separately download the external library). So an exception is made for foo...

Then along comes module bar - just as important and just as popular and another exception is made.... then along comes module baz.

Baz may or may not be important or well loved - but the maintainer says "Why you picking on module baz when foo and bar get to include their external libraries?"

--- Solution? On the project page you can always include a link to a fully packaged TinyMCE module hosted elsewhere. The only thing is that you would have to maintain your own packaging.

andre (a person who would love to have tinymce pre-packaged but understands completely why it shouldn't be that way)

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? 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. 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. On 5/21/07, Frando (Franz Heinzmann) <frando@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

it isn't "very simple;" security patches are just one aspect of issue. What about the fact that Drupal, despite its breakneck pace, moves SLOWER than some other GPL projects? In those scenarios, we actually need to keep an older version for compatibility issues. --Jeff On May 21, 2007, at 2:08 PM, Karoly Negyesi wrote:

...

I don't understand what's so inconvenient in allowing external files.

It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on.

Quoting Johan Forngren <johan@forngren.com>:

If the users have to fetch the libs from an external source, they will most likely get the most recent version. But on the other hand, they wont probably upgrade them after that, even if they keep their modules up to date.

This issue is easily handled by the installation/upgrade process via cURL processing. Hopefully the maintainer is brave enough to ask the user first. Earnie

Karoly Negyesi wrote:

...

I don't understand what's so inconvenient in allowing external files.

It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on.

Im of the alternative opinion that most module maintainers will be a little more keyed into upstream progress for third party code than the average module user. While it doesnt solve your problem of "I do not want Drupal distributing insecure code." It does mitigate the real problem of drupal users actually using insecure code on their websites as it is outdated, etc. Why not centralize the management of the code, this is one of the purposes of version control systems in the first place. To avoid duplication of effort. This isnt drupal core we are talking about these are contrib modules that im sure have a number of flaws anyway because of their less robust testing and security audits. Arguments "for" such a centralization: * Ease of installation/upgrading use for user base. * Less trouble diagnosing issues on modules with third party libraries because you have 1 fewer variable. * Core Update Status Module to alert users automatically of new versions that include may include security updates. * The average module maintainer is probably going to be paying more attention to the upstream project than the user and is thus more likely to be aware of issues and also has the power to roll in the fixes and release thereby notifying everyone involved. * Module incompatibilities often require that people get a specific version of 3rd party library/code and this can be tough to instruct people to follow. * fewer unnecessary bugs regarding library mismatches, etc Arguments "against" such a centralization: * Third party libraries can and will fall behind the official source with regards to vulnerabilities, security patches, etc a vigi=lant user might know or fix theses issues faster. * Duplication of code management with upstream. * licensing (discussed LGPL, etc) * module developer under less pressure to upgrade module to work with newest upstream version slows down innovation, etc I for one think that a good argument is made for centralizing this code management and easing the burden of our users without impacting the module developers (it is optional right?) I don't see how it can't be a mitigating factor for migrating users off of old libraries if you accept the proposition that the average maintainer follows the upstream project closer than the average user. But perhaps this is flawed logic. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org

Ashraf Amayreh wrote:

...

It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on.

So asking the users to download this insecure code from somewhere else is somehow solving it? Seriously, all of our modules that rely on external code are outdated as soon as the next release of that external code comes out. FCKeditor module for example requires users to download version 3.2 to work with the module, so you're definitely not enforcing any security by making the developer's life harder. When the FCKeditor developer upgrades his module to work with the latest version I'm sure he'd much more rather update the external code than write tutorials and wade through tons of support requests. This is in fact promoting security.

When the module writer decides to support the next version of the external code then he will definitely HAVE TO upgrade the external code in his module, if he's not going to support the new release then it's all the same weather he includes the outdated code or asks users to download this outdated code elsewhere. What am I getting at? The only thing that we gain by forcing the code outside of the repository is a pain for the user and a double pain for the developer who has to do the installation and waste more time documenting it and even more time replying to support requests for it. So rather than concentrate on improving his module and upgrading it to the new external code he'd be wasting it writing tutorials over and over again for support issues. This is definitely a loss-loss deal. Any gains by keeping this code outside is simply an illusion. I think you replied to the wrong message than the one you intended to. I was quoting Karoly there. As you can see below. You and I are in complete agreement on this bit. It is actually one of the points of my email.

On 5/21/07, *Michael Favia* <michael@favias.org <mailto:michael@favias.org>> wrote:

Karoly Negyesi wrote: >> I don't understand what's so inconvenient in allowing external files. >> > It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on. > Im of the alternative opinion that most module maintainers will be a little more keyed into upstream progress for third party code than the average module user. While it doesnt solve your problem of "I do not want Drupal distributing insecure code." It does mitigate the real problem of drupal users actually using insecure code on their websites as it is outdated, etc. Why not centralize the management of the code, this is one of the purposes of version control systems in the first place. To avoid duplication of effort. This isnt drupal core we are talking about these are contrib modules that im sure have a number of flaws anyway because of their less robust testing and security audits.

-- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org

On Tuesday, 22. May 2007, Lodewijk Evers wrote:

Why not to add it to the drupal CVS repository: If the FCKeditor were uploaded into CVS that would mean that there would be ~500 extra files in the repository, which just isn't clean and proper. CVS is for tracking development, and since no-one in their right mind will be developing for the FCKeditor or tinyMCE project in the drupal repository (that would be a fork of those projects) it does not make sense to include those files in there either. Those 500 files will just be doing nothing there and taking up resources like a fax modem in a centrino laptop. A guideline could be that if a project has a repository of their own, and even a complete developer community - don't even think about importing it into the drupal repository.

I completely agree here. A possible solution to that problem could be one or more description files which cause drupal.org to download a file when a project release is created, and optionally unpack it in the folder where the description file lies. You get the idea: /tinymce.fetch: url = http://ovh.dl.sourceforge.net/sourceforge/tinymce/tinymce_2_1_1_1.tgz description = "TinyMCE source package" archive = tgz When the release is created, the url is downloaded, extracted with tar into the module's root folder, and the tarball's contents (the tinymce/ folder) are packaged together with the module. This does not solve the security issue (assuming that this really matters) and does not solve license incompatibility issues (which can still be tracked though, by inspecting release tarballs of modules containing .fetch files or downloading the url manually), but it does solve the code duplication problem. It's not up to me to decide if the remaining problems are big enough to keep up the restriction. Cheers, Jakob

Kevin Reynen wrote:

Some people seem to have missed this point...

I want to CHANGE the configuration of TinyMCE from Moxiecode's default configuration to eliminate the double filter issues for Drupal users. Understood and appreciated.

<snip>

If the CVS policies are changed or a way to easily incorporate 3rd party libraries is developed, I'll be glad to move the "official release" back to Drupal.org. This is a shame but i agree with your rationale. Version control systems arent for for "managing development" as previosuly stated in this thread but instead are supposed to help "manage code" and this often includes third party code in the form of independent vendor drops. There is actually a chapter in the red bean SVN book about the best practices to managing this process. While i understand that nobody wants to ship vulnerable code with drupal (neither do i) i think that we are selecting the greater of two evils. There are so many advantages to allowing reasonably sized libraries that are licensed under the GPL and i have seen absolutely ZERO recognition of these palliative effects by the individuals rejecting the idea. We've made some reasonable arguments for the inclusion of this GPL code and i havent seen any rebuttal or rational argument against the values but instead unsupported declarative statements.

I certainly dont speak for anyone but my self but I would like to put out a concise argument for the position that many developers and myself seem to share: The allowance inclusion of the "reasonably sized" third party libraries will ease the pain of installing, supporting and improve the average users ability/liklihood of keeping their modules and third party libraries updated. The average module maintainer is more likely paying closer attention to the upstream developments and vulnerabilities than the average user and can patch the module when it is advised to do so. After which, the update status module (newly included in D6 core) can automatically and instantly notify affected users when a new version becomes available. This also eases the pain of having to support a wide variety of available versions for modules that rely on third party libraries and allows the module maintainer to make changes to the GPLd code where necessary to better interact with drupal. We believe this outweighs the real and possible disadvantages which include the possibility that "stale" and vulnerable code will be shipped with a drupal module (we think that this incidence will be less widespread than the current situation that requires individual users to track and update their third party libraries themselves resulting in the net improvement mentioned above), we also believe that the benefits outweigh the extra work required to maintain the third party library in version control in part because of the amount of time otherwise handling or debugging poorly setup or configured installs on a very repetitive basis no matter how good the documentation is (surely chx can vouch that no matter how well you document something people will either not find it, not read it or misread it [e.g. cvs]). I have tried to present all of the points mentioned in this thread and address everyones issues in turn. Please forgive or correct any omissions to that end. I would appreciate a measured response to this argument if anyone has the time or inclination. All the modules maintainers are asking for is the permission to make the decision that is best for their module and that makes their continued support and improvement of that module most efficient to them. I personally think this is a reasonable request with enough benefits to relax the current restrictions slightly and give it a shot. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org

Quoting Kevin Reynen <kreynen@gmail.com>:

Some people seem to have missed this point...

Not I.

I want to CHANGE the configuration of TinyMCE from Moxiecode's default configuration to eliminate the double filter issues for Drupal users.

but if 3rd party libraries are never going to be rolled into Drupal releases through CVS or some other method, what do you suggest?

* Store the patches into CVS. * The install/upgrade process downloads the TinyMCE tarball version for the patch set created and applys the patch. * Issues for Windows users. ** There exists gnu patch ports for windows ** Instruct those users to have the patch program in PATH. * Issues with already patched set ** How to handle the patch errors? ** How to determine current state of installed library? IMO storing the modified library as part of the module is what should happen. Earnie

Quoting Kevin Reynen <kreynen@gmail.com>:

Patching is fine... for developers. Maybe I see more issues from new-to-drupal, non-developers due to the nature of TinyMCE, but asking users to make configuration changes to dense code they don't understand is what generates the majority of support requests.

Which is why I said that the install/upgrade process needs to download the library and do the patching.

My goal in bringing this up was only to find a way to distribute a version of the module that requires LESS support. It looks like there may be some concessions made for smaller 3rd party libraries, but not larger ones. Rolling larger external files into releases may be an itch someone scratches in the future, but for now the easiest way for me to get a better module to users that requires less support is to distribute it outside of Drupal.org.

The only other option is to supply a tarball of the entire set. So the general user downloads the full set file while the developer who is supposed to know what she is doing applies the appropriate patches if she chooses to download the CVS version. Earnie

On May 22, 2007, at 10:15 AM, Lodewijk Evers wrote:

Also there could be a RTFM status for issues,

oh my god yes! ;) i've been thinking of adding something like "That's not a bug, stupid!" status for a long time, but this is even better and more widely applicable. ;) http://drupal.org/node/146020

and you just change the status to RTFM and link to http:// drupal.org/project/tinymce/faq or http://drupal.org/project/tinymce/ manual (to implement those aliases into project module might actually be a good idea)

this is also interesting, but more work. we don't have a good mechanism for a per-project faq page, but that'd actually be quite slick. i'd be very interested in seeing someone open an issue [1] about this with their ideas on how it should work (keeping both d.o and non-d.o sites in mind). thanks! -derek [1] http://drupal.org/node/add/project-issue/project

On Tuesday, 22. May 2007, Jakob Petsovits wrote:

A possible solution to that problem could be one or more description files which cause drupal.org to download a file when a project release is created, and optionally unpack it in the folder where the description file lies.

Hm, seems that this approach is still not quite usable. Let's have another try: Each project release gets an additional "External library tarball" upload field, which takes either .tar.gz or .tar.bz2 files, and on creating the release this file is unpacked into the module's root folder. After creating the release, the file can not be changed anymore. Pro: * Not more security concerns than pointing users to an external website, which is the current status * Relatively easy to incorporate into the packaging scripts: no fetches from external sources, file upload and storage managed by Drupal itself * One fixed library version for one project release. Makes it possible to use update_status also for library-only updates. * Allows modification of configuration files etc. Contra: * Makes maintainers prone to not storing patches (e.g. for configuration files) in the CVS, which increases the dependency on the maintainer * Would easily allow maintainers to subvert revision control and just upload their modules as tarballs (then again, this would be against the usage policies and lead to deactivation of the maintainer's CVS account) * Still needs to be updated by the maintainer, instead of getting the updated version from the external site. (If we want embedding of external libraries, it's impossible to overcome this problem.) That should be close to the ideal solution, assuming we want this at all. Best regards, Jakob

Karoly Negyesi wrote:

It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on.

If a maintainer is sloppy their own code is likely to be insecure without any help from a third party library. There is another very simple that incorporation of third party code into modules leads to a path that adds work for the CVS maintainers. The use of the same third party code in two or more different modules opens up a few issues for sites that wish to use both modules together. Do you run with multiple copies of that third party code in your deployment? What if those copies are at different rev levels? What if they outright conflict with eachother, such as two jQuery versions might? When third party libraries become popular they benefit from a move into core, like jQuery did, and at that point they become the responsibility of the CVS maintainers to manage. This is a perfectly healthy progression, but it is one that has 'handle with care' stamped all over it. Perhaps the argument is less about whether to allow 'foreign' code into the CVS contrib area and is more about how to decide which third party libraries to bless as part of core - preferably an optional part that is only made active by a module that needs it. Have I missed the point entirely? Apologies if I have... Scott -- *Scott McLewin* www.folkjam.org find jams. post jams. play well with others. <http://www.folkjam.org>

On Monday, 21. May 2007, Ashraf Amayreh wrote:

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.

It's not so complicated actually. Here's roughly how those licenses work (not to be taken as legal advice, IANAL): GPL (the "viral" license): "If your software uses GPL code then all of the software's code must, under all circumstances, also be licensed under the GPL. There's no way you can base proprietary software on GPL code." LGPL (a superset of the GPL, mainly used for libraries): "If you change something in the code itself, you must also release it under the LGPL. But if you just base your code on this library, you can put your own code under any license you like." BSD / MIT X11 (the free-for-all): "Do what you like with this code, you only need to keep the copyright header." As the original author, I keep my copyright though, for all three of them. If I don't use any other (L)GPL code in my software, I'm free to release any subsequent versions under any license that I want to. Now, mixing is very straightforward: If there's GPL code in any part of your software, everything else is also GPL. You can mix LGPL and BSD / MIT X11 with GPL, because they are "GPL compatible", that is, lax enough to allow relicensing under the GPL. So: GPL+LGPL = GPL GPL+BSD = GPL LGPL+BSD = LGPL+BSD LGPL+proprietary = LGPL+proprietary BSD+proprietary = proprietary

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.

Nobody needs to change any files. If you're distributing LGPL code together with GPL code, the whole of it is automatically licensed under the GPL.

Any GPL or GPL gurus knowledge on this is welcome since my knowledge on it may not be totally accurate.

While I don't dare to call myself a guru, I hope I could shed some light on this issue, and that I was able to present it in an appropriate way. Regards, Jakob

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@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