Licensing of the JavaScript Extension


#1

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! :man_cartwheeling:

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.


#2

Can we get an executive summary?


#3

JavaScript extension and ReplPad are LGPL.

Among things that can't be done with it: Red can't borrow portions and put it into a Red/Pro commercial cryptocurrency product that they don't publish the source to.

Reasonable people will not be affected in any way.


#4

I think I was for LGPL for the original R3 release. Will have to check on what I advocated for! :rofl:


#5

Thank you @hostilefork for that detailed and well-reasoned explanation. I support the decision.


#6

How does this affect applications created with the files outputted by the Emscripten and Emterpreter builds (i.e. libr3.js, libr3.worker.js, libr3.wasm, libr3.js.mem, libr3.bytecode)? Are these files licensed as Apache 2.0, LGPL or something else?

The exported apps that UI Builder produces depends on customized versions of the libr3 files. When I re-wrote UI Builder, I moved all the libr3 dependencies into their own directory, provided the modified versions I use for exporting, and the build scripts used to generate them.

I figured if these files are covered by LGPL then doing that will satisfy the license requirements, and anyone who uses UI Builder to build a proprietary app can do so without having to release the Rebol code they used in their business logic. But are these files covered by LGPL and is that enough to allow this use case?

I am confused because the Ren-C interpreter is Apache 2.0, but the ability to communication with JavaScript is done through this extension and that is LGPL... and on top of that the libr3 libraries include code from Emscripten, which is MIT. Ha! So what license prevails here? I imagine the LGPL takes precedence, but was curious what your opinion was.

Also, the applications that get exported have to store a Base64 blob of the libr3 files in the HTML file that gets generated, in order for them to run properly. This Base64 blob is technically a library, and it could be switched out with a different one if someone had the skills to do this... and so this seems to satisfy the LGPL, but then again this blob is being combined with the application.

I just want to make sure I am doing the right thing, and be able to give the correct answer to anyone who may ask about creating closed-sourced software with UI Builder. I mean technically, anything created with UI Builder can't be closed source, because everything has to be stored as blobs in the HTML and those can be decoded... but I think the question will still come up at some point.


#7

Everything you are doing is fine. The main thing to communicate to anyone with commercial/closed-source intentions is the expectation is that interesting changes to the components will be shared back.

Being able to "relink against another version of the ReplPad" is a bit far fetched today, so no need to be worried about that technicality. So long as things are done in public as non-obfuscated source, it's all good.