Mike McCormack wrote:
I have been working on richedit a little also, and am quite keen to get the ball rolling by having some richedit 2.0 code in winehq that others can help work on it. I'm quite interested to see the source for this.
I may send the source code to people who are potentially interested, so that it may get taken over if I get very busy or bored of it, and so they can make up their minds about if the design and the actual code is good enough for WINE.
Whether you show us or not, the copyright for the source still belongs to you. If you choose to license it under LGPL, then you can still release it under a different license later,
I think I'll dual license it (LGPL/BSD). I can think of some closed source applications (freeware or not) that would definitely benefit from a free rich text editor that doesn't suck as much as RICHEDIT20 does. However, "straight" LGPL would be OK too, if BSD puts anybody off.
so long as you are the sole author.
That's where part of the problem is: as long as someone sends me just a "Ctrl-arrow" patch, I can always be suspected of stealing that patch. It puts me in a very uncomfortable position.
release your source, and get it integrated into the Wine tree sooner rather than later. People will submit patches fixing your code, and new features.
I'm not going to wait until it's finished, I just don't want people to add features that must be removed or rewritten a week later because of half of functions have their parameters changed.
For example, adding Undo functionality from scratch after everything else is done would be a disaster.
When you do release your "completed" riched20 code, LGPL patches will still be submitted against it, and you'll experience the same licensing problems if you wish to incorporate other people's code.
Another reason not to accept patches just now. Luckily, a commercial version (made for particular use in two or three applications of a particular company) will be actually very simple, having little more features than it has now, and no RICHEDIT API at all. After that, I may safely fork the source.
Frankly speaking, people promising to release their source code "at a later date" is an impedement to development, because nobody is motivated to work on the promised feature in the mean time.
That's what I'm afraid of, too. I'm currently thinking of solutions for that problem.
Please consider "release early, release often", so we can work together on this :)
I agree, this project has a lot of space for collaboration. For example, achieving high degree of compatibility with RICHEDIT will require a lot of reverse engineering and finetuning. However, doing advanced features with basic architecture screwed up is not going to work.
Krzysztof
