I've gone ahead and made the long-planned change to the license.
I'd originally thought I'd wait until stackless and launching a new project site/etc. But things have meandered a bit, and too many significant things are happening. So going ahead and doing it now makes the most sense.
Is It Legal To Change Apache 2 to LGPL 3
Yes.
Apache 2 code may be subsumed into LGPL 3 projects. For esoteric technical reasons you can't relicense Apache 2 code as LGPL 2, but they worked that out in version 3.
Of course, Ren-C's license changing doesn't apply to anything in the Rebol repository Carl released in 2012. And it doesn't retroactively apply to commits I authored between then and now. It only applies to what gets written in Ren-C (or its derivatives) from this day forward.
Hence anyone who wants to use any of the code from before today as Apache 2 need only go to commit be8956c. The new license doesn't apply to that commit, or any of the ones prior to it.
What Files Are Affected?
This is mostly only applying to C files, and native extension code.
I'm not changing the license of the mezzanine routines. So anyone finding a Rebol snippet in that source can still use derived versions of that under Apache2, without being bound to the obligations of the LGPL3 for shipping a Rebol program using it.
(Note: UPARSE is an entirely new codebase, and new code is LGPL by default...I don't know if I feel like making an exception for it.)
Does The LGPL Change Affect Anyone We Know Of?
If anyone, just Oldes.
-
Atronix doesn't mind. The parts of Ren-C they've borrowed from were from fairly early versions (when in was more R3-Alpha compatile)...and it's unfortunately not on their schedule to incorporate any "modern" Ren-C components at this time anyway. But even if they did, it wouldn't matter (they give their customers their source code, which is then under NDA, so LGPL or not is irrelevant).
-
Oldes is the only other "outside person" who has looked at Ren-C code and borrowed from it. But I borrow from his patches as well. So if he wants to take small ideas or fixes out and apply them to his branch while keeping it Apache2, I don't have a problem with that. His lack of interest in the bigger ideas means there's zero odds he'll take anything substantial.
-
Everyone on forum and chat is fine with it.
Will a Strings-Attached License Scare Away (Useful) Users?
Almost certainly not.
First of all, LGPL doesn't ask much (e.g. compared to the GPL). If you look back at Carl's initial announcement about open-sourcing Rebol in 2012, he planned to use GPL 2. It worked for Linux, so why not a language?
Those with business interests lobbied him to use a license that did not require modified versions of the interpreter to be open and free. They didn't want to have to give away whatever "secret sauce" they added, and sold to their customers. It also keeps them from worrying about how it might interfere with license obligations coming from any components they used.
The angle was "if your license makes life harder for us commercial users, we'll have to use something else...which will reduce the attention the language has and it won't grow".
But after all that, they vanished. Guess they got what they wanted and never intend to give back (or just lost interest and wandered off...)
The moral of the story is not to worry about losing the kind of people who would be opposed to the modest rules of the LGPL. The license doesn't mean your whole project becomes GPL by using the interpreter...you only have to share the changes you make to the interpreter itself. People who don't feel it's just good manners to give back to something they're getting for free are probably not worth listening to.
A Creator's Promise to Keep the Project Open
LGPL means there's no intention from the project team to become "dark and secretive".
Those with dollar-signs in their eyes might think it's a great thing to find code with a license allowing secret modifications, and imagine selling the results for great profit.
But y'know who else has the "freedom" to do that? The original people who made and distributed the project. After your buy-in, they could go off on their own...stop patching bugs...and try to sell you back the thing you started using for free.
That's the direction Red decided to go with "Red/Pro". While the vision statement in the "What is Red?" talk pointed to closed-source as a stumbling block, it seems they fell back into very much the same pattern as the Rebol2 it sought to replace. When people ask in chat about things the answer is often "that's on a private branch" or "that will be in the commercial version" or "we're not at liberty to discuss that".
So the biggest element of committing to the LGPL is a way of signaling "we're not like that". This is a project that will receive bug fixes publicly, and improvements will be shared with everyone without them having to pay.
Is A Closed-Source Hijacking of The Project Likely?
Not at all likely today. But tomorrow, who knows?
Some days I see the parts fitting together in a way that would push it into the irresistible category. We're all here because at some points we've felt that.
At those times, I can imagine someone grabbing it and incorporating it into a closed-source product, adding enhancements and profiting from all the hard work without giving back. But then there's the saying: "Don't worry about people stealing your ideas. If your ideas are actually any good, you'll have to ram them down people's throat."
Also: if I'm ever feeling too good about things, I can just wait 10 minutes and run into something from the inexhaustible pit of Rebol's incomplete design points. Then the whole language seems like something everyone should run from like the plague. 
:-/
So really this isn't likely to make a huge difference. It's just about putting those promises in place about keeping the code open, and signaling agreements with Stallman about the premises of software freedom. Our lives are run so much by software...and embracing a moral framework that legitimizes excuses to push that into the dark is not a philosophy that will end well...
