all right, so I added Microsoft.Extensions.Hosting and .DependencyInjection, the server app is becoming an IHostedService, and I'm now registering all the proxy interfaces for DI.
or rather, the next step was going to pretty much to exactly that - I needed to hold a reference to the server task instead of awaiting it, ...and that's exactly what this thing does.
@Greedo I think, if you want to avoid making your project GPL3 and be absolutely sure, you could probably ask Wayne. He definitely is the one who added that capability to RD and with that the original copyright holder for that part of the code base. Copyright holders can allow to license under any license if their contribution is original work.
That being said, as long as Wayne does not complain, I would consider it a non-issue.
Moreover, porting something to another language is somewhat of a grey area anyway.
Btw, I really do not like these viral license restrictions. So, for the record, should we ever consider to (re-)license part of RD's code base under a license like MIT or downward compatible, consider this my approval for my contributions to RD.
Thanks I think it is a grey area translating and also I wasn't even translating because VBA doesn't have half the stuff C# does so it was more a process of understanding the technique then re-implementing from scratch.
Yeah GPL has some "at arm's length" exceptions - this is how proprietary software like Windows OS can run GPL exes. So with the RD3 split maybe something like GPL for the Language Server that uses the Grammar, but the LSP-client (dev tool) communicates at arm's length using the protocol so could have a different license. Basically could RDE load fine without RD LSP, yes. That's my impression and probably in the spirit of Antlr's license - they don't care about VBE addins, just parsers
@M.Doerner practically I think whatever license I pick is likely to be a non-issue unless the package becomes really popular. But I could ping Wayne
Mozilla Public License 2.0 and LGPL look interesting, they force you to distribute source code of the licensed work and disclose source code of any modifications you make to the files in it. And those modified versions must also have the same license or stricter. However the wider project (e.g. one which imports your code) does not need to have any specific license.
The spirit is, if Big Company uses your library, any improvements they make must be made open source, but if it's just used as a component of their product they don't need to make the entire product open source or under the same license, only the bits that came from your library.
@MathieuGuindon All the command line messages are cool. Don't forget to make them i18n-able right from the start. Maybe you've already covered that, just thought it'd be a good reminder
@Greedo Isn't that where some of the OSS abuse by big tech starts to creep in? They're using free stuff and getting paid to do so? Not trying to stir the pot or push an agenda, just trying to understand.
@Greedo There's a difference between being a derived work and being a component of a different work.
The grammar is a large enough piece of RD that it's arguable whether it's a derived work or just a component, and I wouldn't want to bother trying to find out. Other places are more clear-cut.
My favorite license is Apache 2.0. MIT also isn't bad.
@MathieuGuindon The catch here is derivative work decides to use Apache 2.0, then a derivative of that work that may not know about the original licensing restrictions can go private.
On the other hand, as a professional, I'm not a huge fan of OSS. I spend a lot of time fighting with packages that became prevalent, but are no longer maintained and are buggy or have security issues.
heh... just poking at ya'. I agree these are legitimate concerns for corporations trying to make a profit vs the OSS community trying to make free beer!
Didn't RedHat Linux start #2? "Hey, here's this really cool free OS you can use! Now, pay us to install & support it because none of your people will have a clue how to do so."
I don't know. It also falls under #1, with companies like MS and Oracle and whatever supporting it because they need Azure-like products to be reliable and secure.
Just didn't want you to forget that part in your exuberance to move forward. Sounds like the kind of thing I'd do, "Yeah, I'll get that in a minute!" then 6 years later... "Dang, should have done this sooner..."
On the other hand, React + MUI provide a lot of really good tools, and are still fully maintained, so I haven't had to deal with this stuff much for the past few clients.
And I'm not sure I can recommend using Twitter Bootstrap going forward, anyway, given how rocky Twitter has been lately. IDK if they'll survive more than a few more years.
Especially considering they were only just getting profitable before Musk took over and they lost of bunch of revenue sources.