I'm currently trying to get a project started to convert between various file formats typically used for writing/word processing (https://github.com/uxproductivity/DocFormats). Markdown is one of the languages I hope to add, and I've been planning to use the Multimarkdown grammar. But if I can make a convincing argument on the list for using something like this, it will make things a lot easier for everyone hopefully.
sounds bit like Pandoc: http://johnmacfarlane.net/pandoc/
1. Uses the Apache License (Pandoc is GPL). The code for this project is part of a commercial, closed-source project (and needs to continue to remain part of this project) so sadly this rules out Pandoc on legal grounds. I've also had interest from others in seeing such a library unencumbered with the GPL restrictions.
2. It's written in C, not Haskell. The commercial product (UX Write) runs on iOS, and I'm not aware of any Haskell compilers for iOS. I think there are some efforts underway, but at least when I began this two years ago C seemed the natural way to go.
3. It does non-destrctuctive updates, meaning you can make a change to the target file, and then update the source based on the modifications. Doing so will leave any elements in the source document which were unable to survive the translation intact. I'm not sure if Pandoc does this.
One option if you can run Haskell code somewhere is to use the Pandoc library, which will produce an in-memory structure that you can manipulate as the user makes edits.
That would open up your options considerable.
I have, yes. But currently it's my only source of income, and I need to maintain said income, otherwise I will not have the resources to devote to development of the app (both the closed source parts and open source parts).
If I could make the same amount of money (or more) by open sourcing the entire app, I'd happily do it. I know that theoretically at least, there are strategies to do so, and actually I'd like to take this approach if I can find one that works. If you have any suggestions I'd certainly like to hear them (and yes I'm serious).
I'm a strong believer though in the "hybrid" approach, whereby parts of a product are open source (and used by other products), and other parts are kept proprietary. KHTML (now known as WebKit) is a perfect example of this. If it was GPL, there's no way Apple could have built Safari on it, and the project would have continued to struggle as it had been for some time and probably gone nowhere. But because it was under a license that allowed Apple (and later Google) to build a proprietary product on top of it, both companies had a strong incentive to take the library and improve it. Granted, it was LGPL (not Apache), so they were legally required to contribute their changes back to the community.
A proprietary product that brings in money that can, in part, be used to fund development of the open source components of an application is something I see as a good model. But certainly there are others that could be made to work.
You can release code as GPL and still use it in your own proprietary projects, because you retain copyright. You just need to ensure you have a contribution agreement that assigns copyright to you. The risk is that somebody will fork your work and then you couldn't switch to the forked version.
We're currently putting together a proposal to make this an Apache Incubator project and I hope to have it developed as a community effort there. Thus everyone will be able to use it in their own open- or closed-source products if they wish (which will increase the attractiveness of the project for some, who would otherwise avoid GPLd code due to its viral nature). And then no company/individual has any special rights over others who have contributed.