When I started the ReplPad, I went with a GPL License. It's "strict" in terms of saying that whatever you do with it, you have to share the source. Not much of a problem for today's usage, since it's all being delivered over the web anyway. And it's nothing to do with Rebol scripts that you're running...just the support for the console itself. e.g. if you make an improvement to the undo mechanism, you can't keep source for that to yourself...you have to publish it.
GPL has had success on desktop/servers with things like Linux (hard to argue that isn't doing pretty well). And despite the MIT-licensing ethos of 10-line JavaScript modules, it's not unheard of for a web project of substance to use the GPL. It discourages bad actors--and encourages sharing, plus avoids fragmentation. One good example is RegExr (which we might want to borrow from, heavily, for PARSE teaching!):
https://regexr.com/
https://github.com/gskinner/regexr/blob/master/LICENSE
I'm a believer in Stallman-style philosophy of Why Software Should Not Have Owners. And so I don't really see why anyone should reasonably feel entitled to box up all the work of what the ReplPad may become, and not give anything back. Publishing their source code is not too much to ask. And I'm not worried about "losing customers"--if someone adds a great undo feature to open source software or fixes a bug and doesn't want to tell the people who made it, that person can take a hike.
What about the JavaScript Extension itself?
@giuliolunati has pulled off a factoring so that you can load the JavaScript libRebol and all of its necessary pieces from a single loader file. GREAT! 
To do so, he took code out of the ReplPad project and into the JavaScript extension. (For convenience, extensions currently are living in the main repository to make them easier to build and keep in sync.) And that starts what I think is going to be a trend...that it's going to get harder to tell what parts are "ReplPad" and what parts are "extension".
Right now the JavaScript extension's C code has a boilerplate "Apache 2.0" on it from the other files.
Of course, it's had all of one contributor--me. So between Giulio and I that means we can pick whatever license we want. So, which one?
ReplPad's License = JavaScript Extension License
Using the same license for both means not having to worry about moving code between one and the other. It looks like we'll be doing a lot of it, and that should not be a hassle.
I'm going with LGPL 3.0
The LGPL says that if you make a closed source program that uses the thing as a library...you aren't obligated to release the source to the program. But if you modify the library itself, you have to publish/provide those modifications. So basically if you change mod-javascript.c you have to show what you've changed.
Stallman argues that open source developers shouldn't pick this more liberal form of GPL license unless non-GPL solutions provide equivalent functionality. There's really only one "competitor" in the form of libRed, but they don't have any restrictions on commercial use (and have disappeared down a non-open-source hole for some of their work: see "Red Pro", where they have made the "community branch" a second class citizen, and you have to pay them to get 64-bit support, or whatever...<eye-roll>)
In any case, saying closed-source apps can't use the JavaScript extension would put an advantage point in Red's column for some people. I guess I don't see the point of giving Red that advantage. However, asking people to publish modifications to the JS lib or console itself--ignoring what they connect it to--is fully reasonable--so I don't mind being lightly more restrictive in that sense. That shouldn't bother anyone who matters.
Given my FSF biases, this is more liberal than I may like for the ReplPad. I certainly don't like the idea of someone boxing it up in an Electron app, linked to proprietary software...aren't we done with these bad ideas? But LGPL works for a lot of projects--Qt for instance. And it's too inconvenient to think of worrying about moving code between the projects otherwise.
Stallman may disrecommend the LGPL, but he still made it. So at one point he thought it was a reasonable compromise. Can't be too bad, then.
The code is still small, but that's why deciding now is important.
Making a big deal about the license now might seem dumb. Some might say "it's too small to worry about, just make it MIT/BSD/Apache, why make it inconvenient for people?"
But that's exactly why now's the time. Once it gets larger--and contributions are accepted--it will be too late to change our mind. People will have committed bits and say they don't want it re-licensed. Or even if they would be willing to re-license, you'd have to track them all down to ask (I've seen projects have to do this).
So what I'm proposing as a contributor agreement is that everyone agree that it can be re-licensed more liberally in the future, but that no "dual licenses" will be given. So a company can't pay for a special arrangement for them to use and adapt the code, while it's still LGPL for everyone else. But there could be a KickStarter and people could donate to fund some development contingent on relicensing as BSD (or whatever)...but the code is released under the new license for everyone, donor or not.
Anyway--maybe it won't matter in the scheme of things for this project. But I think at minimum, it's important for developers to be having this conversation regularly. Carl and Rebol asked people to try and get back to using their common sense about complexity. Stallman and GPL asks people to get back to their common sense about where control and power should be when it comes to software.
