HTMLArea discontinued, next steps for WYSIWYG editing in Drupal

By Boris Mann on 8 Mar 2005 at 19:52 UTC

I just found out today that main development by the original authors of HTMLArea has been discontinued. See the bottom of the Dynarch project page for some more details, reproduced here:

Update, March 8 2005. Some time ago, InteractiveTools expressed the will to take over the project. We provided some fixes that we made and were not in the CVS version and a RC2 was released at htmlarea.com; however, soon thereafter InteractiveTools announced the project closed and forums discontinued. Bang!

Our position on this is that the editor will keep going; we are actually making quite some progress in its development, but only in house at this time. We are still planning to release version 3.0, quite possible under a different name (so it might actually be a 1.0) but still free, at least for the core editor--some plugins might be released under a commercial license. We can't provide explicit deadlines, so please bear with us.

I also checked the licensing, and it is in fact the case that HTMLArea is not GPL -- it is a modified BSD license. As we discussed at DrupalCon, I believe this is an issue for having that code here on Drupal.org. All code, including contrib, needs to be under the GPL.

Finally, I wanted to make a general call for all people interested in development of WYSIWYG editing for Drupal to respond here. I believe we can now focus our efforts on the FCKEditor codebase (ideally with a different module name -- like richtexteditor.module or something).

Comments

Would be willing to beta test new code

Eric Scouten commented 8 March 2005 at 21:07

I'm afraid these days I don't really have time to write new code, but I have a couple of sites that use the existing htmlarea.module and I will want to migrate them to whatever replaces it.

Consider me a willing victim. ;-)

--
http://www.ericscouten.com

Xinha is the way to go.

gordon commented 9 March 2005 at 01:16

Xinha is the way that the htmlarea module is going. I have just about finished the updates to the current htmlarea module and I am going to be removing htmlarea from the cvs very soon.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Looks good, but is also

ramdak5000@www.drupal.org commented 9 March 2005 at 02:51

Looks good, but is also under a BSD licence, so not sure if that is a showstopper as far as Drupal is concerned.

This is not a problem, as

gordon commented 9 March 2005 at 02:54

This is not a problem, as Xinha will *not* be distributed with the htmlarea module. The users will need to download the latest stable version and install it.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

BSD licences are not a

killes@www.drop.org commented 9 March 2005 at 03:14

BSD licences are not a problem. Since they are very "soft" you coul din theory re-release the code under the GPL. But I am happy that you will take away all those pesky JS files. ;-)
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.

--
Drupal services
My Drupal services

I am also hoping that this

gordon commented 9 March 2005 at 03:23

I am also hoping that this will cut down on some support requests as I will no longer be distributing htmlarea, so they will go back to were they got it from.

There maybe some js left in cvs as the drupal plugins will be stay.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Great news

Boris Mann commented 9 March 2005 at 04:43

Sounds good, Gordon. I like the way the plug-in architecture works for HTMLArea/Xinha, and completely re-working the way things work were starting to give me a headache.

I was debating going with FCKEditor, but I think we (Bryght) have too much invested in HTMLArea at this point to completely drop it. That being said, we're basically going to evaluate *right now* whether we need to shift to using FCKEditor or to stay with HTMLArea. I spent some time playing with FCKEditor today and it feels...really nice. Maybe the Xinha HTMLArea "upgrade" is better.

James (walkah) has a bunch of nasty things to say about HTMLArea, but I don't know how much of that is the Drupal module vs. the plugins, etc.

What I propose with people who are interested in this issue is to draw up some current issues, talk about solutions, and perhaps split out development so we can work on different parts.

Image insertion is certainly a big one, and now that walkah's image API are part of core, we can potentially do this once as a nice plugin (e.g. including multiple size support).

A file manager of some kind to re-use uploaded files (or scan the upload table?) would be a "nice to have" but doesn't necessarily

A comment on FCKEditor

nevets commented 9 March 2005 at 05:02

HTMLArea has always be a so so solution for me so I downloaded FCKEditor.
Generally worked great except when there where a number of textareas on form. (I personally like the thought of a new form type say form_html, that uses a HTML editor if available otherwise a textarea)
BUT when I went to use it on our actual server performance sucked, mind you this is not the worlds faster server, but it rendered FCKeditor unusable (More often than not it never finished initiializing)

I too have had similar issues with FCKeditor...

tatonca commented 14 March 2005 at 16:29

... I found it performed better under IExplorer than Firefox. I also discovered that if I switched to the Basic Toolbar it worked more reliably. Unfortunately this means that you have no advanced features. I was wondering about reducing the advanced toolbars to potentially increase the reliability, or if one particular menu option was causing the problem...

Include me

neofactor commented 9 March 2005 at 04:21

I have been contributing to HTMLarea and will certainly be interested in supporting whatever the Drupal community wishes to embrace.

The key areas of HTMLarea that I will continue to need are insertfile and imagemanager. I have devloped other tools that do the same thing as this for other editers so I am not too worried about adding this into another editor.

I have had discussions with other developers and feel any WYSIWYG should have a toggle at the node level to turn it on/off on the fly. Similar to how Blogger and others do it.

In line imaging is huge and will need to take focus, as well as control over codesweeping Bad MSWord code that is copy/pasted. An improved spell checker and so on.

Count me in fully in this development effort.

David McIntosh
neofactor.com

Xinha has some new very good

gordon commented 9 March 2005 at 04:35

Xinha has some new very good plugins for code sweeping. This is usually done on paste. Also the new Xinha plugins are great, and dont have popup windows which works alot better with popup blockers and so forth.

I am going to be porting the current drupal plugin's to Xinha when I get some time. but it will not be until after 4.6 is released.

I would like to be able to turn Xinha on and off based upon a checkbox, but I am unsure if I can. It is on my list.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Whatever replaces HTMLArea

geokker commented 9 March 2005 at 06:33

Whatever replaces HTMLArea in Drupal *must* allow normal users to format their text, add and format images intuitively and add/edit URL's without touching/using html tags.

I will cry into my cornflakes if this aspect is not developed further as it is THE killer feature of Drupal when used as a user-updated presentation website/CMS.

PLease be constructive, and givce examples

Bèr Kessels commented 9 March 2005 at 08:10

comments like

I will cry into my cornflakes if this aspect is not developed further as it is THE killer feature of Drupal when used as a user-updated presentation website/CMS.

are often heard, but really do not add to the discusion.
Now, if you can produce some figures, tests, results or links on why this is THE killer feature, we can actually use your comment as reference.

And if this solved you problem, would you be so kind to report back that it helped? This will help others whom are looking for the same solution.

[Ber | Drupal Services webschuur.com]

Actually, I find this one to

Boris Mann commented 9 March 2005 at 11:20

Actually, I find this one to be pretty straightforward: humans need WYSIWYG not WYSIFUC.

This is the 21st century. I

geokker commented 10 March 2005 at 13:55

This is the 21st century. I don't think I need statistics to backup an argument that most users are going to want to format their text.

Personally, this function is a no-brainer. What makes HTMLArea different and better in my opinion is the ease (relative to other programs) of uploading and formatting images while composing a document.

Other than drupal/HTMLArea, I cannot find any other CMS products that do this as intuitively.

I have never heard anyone crying into their cornflakes.

It's aliteration...

tatonca commented 14 March 2005 at 16:44

I have never heard anyone crying into their cornflakes.

I think it's poetry thing.

Other possible derivatives -

"weep into my wheaties"
"sniffle in my snapple"
"lament to my linguinni"

I believe the author is trying to evoke themes based on the relationship between depression and eating...

{Sorry I couldn't resist *grin* }

~Tat~

Wonder if theres any cornflakes?

Trahloc commented 13 June 2005 at 02:31

http://cryingwhileeating.com/

Had to share ...

Killer feature

Schamess commented 20 March 2005 at 18:52

I'm a non-techie. I have a Drupal website, and I learned enough HTML to mark up my own posts. I would like to add other writers, but I am finding that people I invite do not want to use the site because there is no WYSIWYG editor. People are (frustratingly) very accustomed to word processing software and don't know what to do with a plain text field.

I also started a site for a group I belong to and the same problem applies. I ended up using Mambo for their site. I don't care for it. I actually came to Drupal.org today to see if there is a good WYSIWYG plug-in, thinking I would recreate the site using Drupal. Sounds like it's in progress...

I really love Drupal and I'm very grateful for what everyone here has created. Based on my experience, a WYSIWYG editor would be a very useful addition for many users.

Thge Drupal Fork [tm]

Bèr Kessels commented 9 March 2005 at 08:14

I beleive we should fork HTMLarea or whateverEditor into a DrupalFork.
That way we can make it a neat and clean thing, without all the cruft.
Instead of its own plugins system we can use Drupals plugin system: A hook will be avble to propose new buttons and functions.
Instead of etc, we can use [img:12]. Dot it the Drupal Way.
By default we can make it really small, with very few buttons enabled.
We can make it work with CCK properly, in future.

The negative side is that we will be maintaining some hell of an application.

[Ber | Drupal Services webschuur.com]

Might be possible with

Boris Mann commented 9 March 2005 at 11:22

Might be possible with FCKEditor, since it is (L)GPL...but a huge task to undertake, and more of a long term project, I think.

It looks like Xinha (HTMLArea fork/bugfixes) has a ton of of improvements. Need to test and see about further supporting development of it.

Re: The Drupal Way

nevets commented 9 March 2005 at 17:47

For the needs of the communites that I am helping maintain web sites the 'Drupal Way' is not really the best.

They are use to Word or Word Star or something similar. They should be able to edit html without knowing it is html and should be able to in a straight forward manor add images and urls to there posts.

Also, syntax [img:12] assumes all images have been pre-loaded before they do their post and that they are all represented by a node. Tools like fckeditor make it easy for non-technical people to add images to their posts.

New FCKEditor Available

jjeff commented 9 March 2005 at 15:52

In any discussion/debate about HTMLArea vs. FCKEditor, please keep in mind that the version of FCKEditor included in the available fckeditor.module is 2.0 RC2, which is actually a beta version. A new version came out last week (2.0 RC3), which is actually a release candidate (don't know why they're naming things like this). This version hasn't made it to the module yet, but it adds a lot of bug fixes, an integrated spell checker and lots of other features. I haven't had any contact with the fckeditor.module developer, so I don't know if/when 2.0RC3 will be integrated.

I like FCKeditor because of it's ability to maintain Word formatting during paste as well as it's integrated image and file uploading capability.

Also, I've created a patch for fckeditor.module that adds the capability to "switch on" the WYSIWYG for any textarea by adding a JavaScript link below it - so there isn't any overhead for a page with many textareas and the WYSIWYG doesn't need to be loaded for textareas where it isn't appropriate.

HTMLArea also maintains Word

Boris Mann commented 9 March 2005 at 18:26

HTMLArea also maintains Word formatting on paste (and has a "kill Word formatting" button for those that hate the HTML that it produces).

It also does image and file uploading. FCKEditor does this directly to the file system, and does not integrate with the image API, unlike HTMLArea.

So, yes, I'm playing devil's advocate. I'm impressed by the "cleanness" of FCKEditor. I'm not a fan of the name :P I don't know how hard it would be to integrate better into Drupal

I'm wondering if we could somehow have the best of both worlds -- have a richtexteditor.module where either one of these engines (or other ones) could be plugged into?

As discussed with HTMLArea, the FCKEditor code should NOT be included in Drupal CVS; include pointers to the download of FCKEditor separately.

Start from scratch. Code for Drupal

bryan kennedy commented 9 March 2005 at 17:34

Well, I am unaware of howhuge this sort of project would be...but I think the best strategy would be to start from scratch and code a module exclusively for Drupal. I believe there are several reasons to do this:

Any WYSIWIG page editor requires image/media upload and placement support. This would be killer if it efficiently interfaced with how some Drupal modules already handles this image.module/media.module/file attachment
Allows for hooks to be made into themes. If people really want a good WYSIWIG editor we ought to be able to style it via our themes
This would be a wonderful marketing tool for Drupal. As many people have mentioned that the lack of this feature as default is a big hindrance to Drupal adoption.
Drupal code seems to be to be highly cruft free and good quality. By coding it ourselves we could maintain that standard and keep development sustainable within the product we all support.

This is a project I would be very interested in diggin my teeth into after 4.6's full release but only if people/developers think this would be a good idea. If it seems like a seriously huge project then maybe we should just adopt other's code.

bryan kennnedy
Help us to improve Drupal's documentation. Join the Dupal Documentation Mailing List

HTMLArea does #1

Boris Mann commented 9 March 2005 at 18:19

HTMLArea does #1 today; see my post on the upload image plugin; there is also the UploadDocument plugin, although there is no file manager to hook into on the Drupal side
HTMLArea does #2 today; in the settings, include a link to the CSS file you are using, and it will style the text as it will be displayed.

Yes, it is a seriously huge job :P

what makes it hard

bryan kennedy commented 9 March 2005 at 19:53

Yes, I see that HTMLArea does do some of this. Good point. But I guess we are saying that HTMLArea ain't going to be supported no more....

What are the biggest development chalenges in creating a WYSIWIG editor?

Cross Platform Javascript Programing to control the DOM?
Getting things to match up with Drupal?
Controling content paasted into textareas?
PHP programing to control media placement and uploading?

Others I have not mentioned. I guess I am still interested even if it is huge. Maybe we could start off with the simplest of features. Basic HTML, Drupal Implemented Image Module.....hmm...maybe this can't be simplified that much.

bryan kennnedy
Help us to improve Drupal's documentation. Join the Dupal Documentation Mailing List

This is important to me, as well.

Max Bell commented 9 March 2005 at 19:41

I just want to weigh in with the folks who are saying that the discontinuation of HTMLArea is significant for them.

If I had to be stranded on a desert island and could only have one Drupal module, it would be HTMLArea.

Whatever happens, what I am certain of is that my users will never be able to do more than type and click.

HTMLArea the module is not

gordon commented 9 March 2005 at 20:05

HTMLArea the module is not going anywhere. But now instead of using HTMLArea we will be using Xinda, and it will not be distributed with the module.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Oops.

Max Bell commented 9 March 2005 at 22:48

Gordon; no, I got that, I just meant to say that it was important that HTMLArea (the module) continue in some form.

Yes I have not intension of

gordon commented 10 March 2005 at 00:26

Yes I have not intension of stopping the development of the module.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Well, hey!

Max Bell commented 10 March 2005 at 06:30

You have my undivided attention, then. I'm not good at feedback; I've been a drupal enthusiast for a few years, but found that at best, I'm capable of making (fairly rare) supportive noises. If I do find anything of interest, though, I'll be sure to let you know.

What about TinyMCE ?

limas commented 9 March 2005 at 21:08

Htmlarea is good but TinyMCE - released as Open Source under LGPL - is more advanced, more stable, and ... I switched from Htmlarea to TinyMCE for all my projects. There is a growing plugin base. TinyMCE spits out HTML/XHTML 1.0.

I just tested out TinyMCE.

bryan kennedy commented 9 March 2005 at 23:26

I just tested out TinyMCE. It seems nice and simple. One flaw though is that the link tool doesn't allow you to insert title tags.

bryan kennnedy
Help us to improve Drupal's documentation. Join the Dupal Documentation Mailing List

Title tags

limas commented 10 March 2005 at 13:02

Have checked out the full featured example.
http://tinymce.moxiecode.com/example_full.php?example=true
There you can set all options you can think of (title/popup/target/pre defined link list..)

TinyMCE is solid!

jjeff commented 9 March 2005 at 23:31

I just checked out TinyMCE and it looks really good! FCKeditor is kinda scrappy and there's not much for documentation or a forum. But TinyMCE has both! It looks super easy to install and very configurable!

I'm still experimenting with it, but I might end up a convert! Worth checking out:

http://tinymce.moxiecode.com

Also, it's probably safe to say that there's not going to be a consensus on which is the *best* wysiwyg editor. And I think that building a Drupal-only rich text editor from the ground up is analogous to reinventing the wheel. There's already some really good ones out there. It seems like the safest thing is to just make sure that the Drupal core has what it needs in order to easily and fully integrate the available rich text editors.

-Jeff Robbins
www.jjeff.com

TinyMCE as an engine

Code Rader commented 11 March 2005 at 12:20

I have been using TinyMCE for a few months now on a number of different projects and must say it is really great. It would be pretty simple to integrate it as the WYSIWYG editor and get the image upload included as it has its own api for such things.

I think the best idea has already been suggested. Create a WYSIWYG modules then use one of these as an engine. These editors are all wonderful products that we each have a preference for. What would be the tasks involved in creating a generic module like that and plugging in the editors?

Jeff Rader
http;//lubtex.com/OS/

Jeff Rader

TinyMCE module

matt westgate commented 13 March 2005 at 06:02

Drupal now has a TinyMCE module for the upcoming 4.6 release:

http://drupal.org/project/tinymce

Image manager

shrop commented 14 March 2005 at 03:20

I know TinyMCE has the feature to insert an image via the url of the image. Is there any type of plugin or method that allows the user to browse through a media library to select the image they want and of course to upload new images.

I am looking for a solution to easily allow my users to insert images into nodes. If HTMLarea is being pulled from future development as a part of Drupal, I would love to look at TinyMCE as an alternative.

Thanks!

HTMLarea is being replaced

matt westgate commented 14 March 2005 at 04:54

Xinha will be the new replacement for HTMLarea since it shares a similar codebase.

As far as an image manager for the TinyMCE module, I plan on integrating img_assist into it and also offering the ability to upload images. Granted I'll just do this by creating a GUI to the image module.

If you want to discuss an image manager further, please file a feature request.

the htmlarea module is not

gordon commented 14 March 2005 at 07:20

the htmlarea module is not stopping development, I have just changed to use Xinha instead of htmlarea, which is alot more stable and much more flexible.

I have started looking at walkah's image module that will be replacing the currect image module. Also I have worked out how to add a onsubmit function to a Xinha plugin as that all the <img> tags will be converted them to [img] tags so that the image filter will be able to rewrite the <img> tag so that it will be closer to the correct size and so forth. This will also convert both ways [img] -> <img> -> [img]
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Trial of TinyMCE on Drupal 4.6

dude4linux commented 16 March 2005 at 22:07

I installed the cvs release of your TinyMCE module on a test site running drupal 4.6. Installation was straight forward, but all the TinyMCE icons appear in centered vertical column (one icon per row). I tried all three templates. Did I miss something?

Also can you add an option to locate the tool bars above the textarea? I know this is an option in TinyMCE. I'm interested in TinyMCE as an alternative to FCKeditor because cut and paste works with Firefox. Hoping that Fred can fix that in his editor soon. We also need an editor that will work with OSX :)

Information is free, knowledge is acquired, but wisdom is earned.

inline images

matt westgate commented 16 March 2005 at 23:46

I was hoping a patch would hit core before this became an issue. Irregardless, I've patched the TinyMCE module.

As far as controlling where the toolbar is displayed (top/bottom), you can do that and control any other feature of tinymce by overriding the Drupal tinymce_theme() function. Look at the last section of tinymce's INSTALL.txt for details.

Inline Images

dude4linux commented 26 March 2005 at 19:53

The latest update fixed the inline image problem. Thanks.
tinyMCE looks good but I do have a few suggestions.
1) I don't see the cut and paste buttons displayed in either IE or Firefox. One of the reasons I'm interested in tinyMCE is that the cut & paste worked with Firefox on their demo site.
2) I'm hoping you will consider adding the selection of (top/bottom) display to the administrator->settings->tinymce page.
3) I would like to see a setting to enable/disable the display of the iespell icon. I don't want my users downloading and installing iespell since it isn't opensource. I'd like to wait until tinyMCE supports aspell running on the server.

I assume I should file a feature request as described above.

Information is free, knowledge is acquired, but wisdom is earned.

A thread that might be of interest

andremolnar commented 9 March 2005 at 22:45

http://drupal.org/node/8264

Criteria

neofactor commented 10 March 2005 at 04:48

I guess the real question is:

What criteria should we as developers and users establish to decide on what rich text editor Drupal will embrace... or can we live with more than one project?

A Matrix should be created detailing/comparing all of the following for each canidate:
1) licence compliancy
2) features
3) cross browser ability
4) ease of use
5) granularty control/options
6) easy switch on and off per textarea
etc...

I do not have time to evaluate all new technologies out there so I would suggest we split our resources, establish a lead for each and have that collective defend the direction to the Drupal community.

What offical steps do we need to take to begin this preocess?

David McIntosh
neofactor.com

HTMLArea javascript is gone!

gordon commented 10 March 2005 at 13:02

I have just removed the htmlarea javascript from cvs, as well as with the use of the database to determine which textareas to convert. I have added a completely brillant method that is used in blocks to determine which page to display on.

I haven't quite finished testing yet, as I need to set up a new version of drupal in install htmlarea to make sure that everything is working ok without a copy of Xinha or HTMLArea present.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Would it not be better to put a sane version?

kbahey commented 10 March 2005 at 14:43

Gordon

Thanks for taking the initiative and solving this issue by pursuing Xinha.

It is not clear to me what your approach is: you deleted HTMLArea, and will bundle Xinha with the HTMLArea drupal module? Or will you just provide the module with instructions for the user to go and download Xinha and put it in a certain directory?

My preference is that Xinha is bundled with the HTMLArea module. This module is all about usability, and requiring users to go thru hoops to get it working is a complete turn off. If Xinha is included, not only we save them the pain of download and install, but we provide an out of the box solution. Moreover, we guarantee that this version works, regardless of new changes Xinha does that may or may not introduce bugs, break compatibility, ...etc.

Just a though ...
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

kbahey -- we can't bundle

Boris Mann commented 10 March 2005 at 15:22

kbahey -- we *can't* bundle Xinha/HTMLArea in CVS. It is not under a GPL license, so having it in Drupal CVS has been a problem from day one. We discussed it at DrupalCon, and it was something that has to be done.

Aside from licensing issues, which can't be argued with, having someone elses codebase in CVS is an issue. Gordon already found that people would file issues with HTMLArea here on Drupal.org.

Thanks

kbahey commented 10 March 2005 at 17:23

Thanks for the explanation.

I was under the impression that BSD style code can be used in GPL projects, like elonen pointed out below.

I agree with the support issues it creates.

So, to make everyone aware, we have to say WHY it is not bundled anymore in the README.txt or INSTALL.txt file. This way, people will be confused less, and will ask fewer questions.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Licenses misunderstood?

elonen commented 10 March 2005 at 18:55

I was under the impression that BSD style code can be used in GPL projects, like elonen pointed out below.

I still insist that it can and I'm quite sure about this -- if I'm wrong, someone please explain how.

When you link GPL'd code with something else, you have to distribute that "something else" under the GPL as well. So, license-wise, I'd say this code could very well be kept in CVS because because you may relicense "modified BSD" style code -- it's just that the license texts could/should changed to GPL blurps in CVS. The facts that drupal.org and someone else are distributing the same code under different licenses don't affect each other in any way.

You might want to read, for example:
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean and
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Please note that I have no opinion on wether the said code should be kept or omitted. I just want to make sure people (myself included) don't get wrong ideas about OSS licenses.

That is what I understand too

kbahey commented 11 March 2005 at 01:14

That is what I understand too. However, I am no expert on free software licensing.

Therefore I was a bit taken aback that licensing is one of the issues with HTMLArea.
--
Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

I found it. When you apply

gordon commented 11 March 2005 at 03:08

I found it. When you apply for a cvs account you agree that you will only commit GPL software. So as Xinha/HTMLAreas is a modified BSD licence It cannot be commited.

Also if you read that statement to the letter even LGPL products cannot be commited. so FCKEditor would be out too.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Hmm.. that's bad

elonen commented 11 March 2005 at 10:50

Could it be clarified as "only code that is (or can be) licensed under the terms of GNU general public license"? I don't see what purpose it serves to exclude, for example, double licensed stuff (or LGPL'd as you said).

You may NOT relicense

Boris Mann commented 11 March 2005 at 03:55

I checked with my good friend and licensing guru Zak Greant.

You can USE the project, and we could redistribute the code (under the original modified BSD T&Cs), but we can't magically change it into GPL.

As Gordon mentioned, we also don't want to be including external code in the CVS repository.

Yes you (effectively though perhaps not nominally) may

elonen commented 11 March 2005 at 10:37

Unlike GPL, the modified BSD license doesn't stop you from adding extra restrictions. Hence, while you technically speaking may not remove the original BSD license (because of "must retain [...] list of conditions"), you may restrict it further, which is what "relicensing" (or more properly, perhaps, "amending") with GPL does.

(You could also interpret "retain list of conditions" such that the you have to retain the substance, though not necessarily the original wording. Then mere GPL, which contains the same requirements, would suffice and this would be true "relicensing". It's probably too risky an interpretation. Thus, my comment from last night: "change to GPL blurps", is probably too risky; it should have been "amend with GPL blurps".)

To restate why you can "relicense" BSD stuff to GPL (=require the licensees to agree with both licenses): 1) copyright law by default prohibits you from any kind of distribution, 2) modified BSD license then grants you a lot of freedom and 3) GPL again takes away some of them by imposing extra requirements (it's a superset of the modified BSD claims). None of them are in conflict with each other.

Moreover, as Boris pointed out, the usual interpretation of GPL (at least the one of FSF's, IIRC) is that you don't strictly speaking even have to add the GPL text -- you can just link (use) a less restrictively licensed module with GPL'd code and have that part still go under the original license as long as they "can be reasonably considered independent and separate works in themselves". However, I'd personally play it safe and add the GPL text on top of the BSD text, as I don't quite comprehend the above mentioned part of the GPL.

Please comment further, I'd really like this cleared up (so I'll never ever have think about it again).

As Gordon mentioned, we also don't want to be including external code in the CVS repository.

Yes, that I don't want to argue against.

My reasons for doing this are

gordon commented 10 March 2005 at 21:34

My reasons for doing this are 3 fold.

from what I know, and I haven't been able to find it this morning, is that packages such as the htmlarea/Xinha are not allowed to be commited to cvs and distributed with the module.
Also from what I heard at drupalcon I think a decision was made that only GPL software could be put into cvs.
and finally I want to separate the 2 so that *hopefully* I will not get support requests for Xinha/HTMLArea itself, which are the majority of the issues. I hope that with the change to Xinha this will no longer be the case.

Also the installation of Xinha into drupal is not that complicated. all that needs to be done is to extract the contents of the archive into the htmlarea module directory. Which I feel any admin should be able to do.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

for 4.5 or 4.6?

dan90@drupal.org commented 16 March 2005 at 23:02

Nice development on the htmlarea module thus far, gordon!

So, if you don't mind me askiing: will the new htmalarea/xinha module be for 4.5 or for 4.6?

(Just worked out the hard way that the new TinyMCE ain't for 4.5. whoops.)

It is the same module, and

gordon commented 17 March 2005 at 01:20

It is the same module, and the good thing about using the Xinha is that the htmlarea interface is the same. At this stage I was not considering back-porting the cvs version to 4.5. But if there is enough need I would backport the Xinha interface so you can run Xinha instead of htmlarea.

I have a couple of things to clean up in htmlarea, and then I will tag it is 4.6, which should be this weekend.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

well, count my vote

dan90@drupal.org commented 18 March 2005 at 04:20

it'd save my bacon if there was xinha for 4.5...

I roger that

hpk commented 18 March 2005 at 05:36

Count me in too!

hpk a.k.a. vikram
[De-centralizing the central issues]
National Institute of Design, India

modified BSD is GPL compatible

elonen commented 10 March 2005 at 14:59

I won't comment on the other points, but you can definitely link a modified BSD licensed piece with a GPL'd one (and in the process, change the license to GPL):
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses