jmacdonald / amp

A complete text editor for your terminal.

Home Page:https://amp.rs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Multiple licenses?

dpc opened this issue · comments

Hi,

TL;DR: Would you consider relicensing under eg. dual GPL/MPL-2?

Longer version:

I am working on a similar project (breeze). The major difference: the UX is heavily kakoune-inspired. I switched to kakoune as my primary language editor (after more than a decade of using Vim), and I really enjoy the editing model, except couple of things that just drive me mad, and the author refuses to change them.

To demonstrate to the kakoune author how I think stuff would work better, I hacked together a crude text editor. It was fun, and before I know it I had couple of more ideas and got really fond of the new UX model I've created. I've added more and more features and now it's even somewhat usable. If I added LSP and some basic highlighting and couple of more important commands, I could maybe even use dogfood it.

I've seen amp somewhere on r/rust, and eventually after thinking about more complex features, I decided to take a look how amp is doing it. I looked around the code... and I love it. It is basically how I was planing to architecture the thing. Except it is already written and very polished and neat.

I tested amp and I like it, I see the appeal. Though personally, it wouldn't be enough of change for me to switch from Vim. I only switched to Kakoune because the difference in it's modal editing is fundamental and really quite a something. Though I kind of regret it already.

I regret switching to kakoune, because I don't agree with some details and a lot of stuff I use does support vi-like keybindings, but will never support kakoune-like editing. My shell, IDEs I sometimes have use, website embedded editors, etc. So now I have to switch mental model between Vi and Kakoune, and since they somewhat similar, yet different it's even more confusing.

So in my editor I explicitly split it in two parts: logical, io-less core that compiles (potentially) to pure webasm, and the outter shell wrapping it into a Linux CLI editor. In the future I'd like to build a reference web-wrapper that can be used in a browser and hopefully make it really easy to wrap the core in any environment.

I even think that the plugins should execute in sanboxed webasm VM. Imagine being able to execute the same text editor everywhere, with your the whole config, including plugins!

So, looking at amp source I was thinking ... maybe I could fork it and adapt to my needs. Probably easier than re-implementing all of it, in almost identical fashion. Maybe I could even maintain it as a fork, or something.

But if the license is GPL, that might limit embedding it into some software, which is a bit of a shame for my goals. IMO, if an editor introduces a new modal editing model it's a hard sell, because it is a snowflake that has to compete with universally known and supported UX of Vi. But if it is really easy to support such editing mode elsewhere - maybe it could gain popularity and establish itself.

For cases like this I like MPL because it's a middle ground between "please, keep my software open" and "I'm OK if you embed it into your closed software".

Thanks for taking your time to read all this and regards from other niche modal text editor dev: your codebase is really good. :)

Hi @dpc! Thanks for the kind words.

I can appreciate what you're trying to do; I had similar motivations when I started building amp. I used and enjoyed Vim, but found its default experience lacking. I'd thought of contributing to it, but it being written in C was discouraging.

I've always had the core bits of amp extracted into a separate crate, in case others wanted to venture down the path of building their own text editor. That way, folks wouldn't have to build the underlying data structures and components from scratch, and could focus on what makes their editor different.

Unfortunately, I'm not interested in releasing amp under a dual license. I've invested too much time to give the entire editor away under a permissive/non-copyleft license. There are also a lot of opinionated decisions I've made in amp itself that tie down the implementation in ways that may be restrictive for a different editor; I've tried to avoid any of that in scribe. I realize that's not the news you were hoping for, but I hope it helps explain the rationale. Please do give scribe a try; hopefully it's enough to help kickstart your editor! 🙂

@jmacdonald Thanks for reply. I'm a bit surprised, because I can't see why would it make any difference, unless you're planing to maybe monetize it in the future or something. Anyway, all fine with me. Best Regards!