Dual license/ relicense?

[Greedquest]

IIUC the ANTLR (VBx parser + lexer (+ preprocessor) grammar?) was GPL v3. Meaning that anything that built on it or consumed it also had to be GPL v3.

I found the grammar and the original author has since changed the license several times:

_{source, related: uwol/proleap-vb6-parser#17}

It is now MIT. I reckon it would be possible to change that part of RD3 to be MIT and then well maybe everything propagates. If not then perhaps it could be worthwhile to consider splitting RD into a couple of different licensed parts. Relicensing if chosen should happen ASAP because old license terms get immortalised in the repo history and may confuse people (going from more restrictive to less is the better way round though).

I'm thinking about a few forks:

• Tools that rely on rubberduck cli api
• Tools that can leverage the parser/lexer to auto-format, lint, standardise code
• Reflection capabilities in VBA using RD's parse state
• Automated CI tools leveraging unit testing
• Plugins that just fork RD's LSP architecture! A plugin ecosystem for the RDE would love to copy the server stuff.

These could all have much greater reach within a less restrictive license. Specifically to private code. Which VBA has a lot of I imagine (solving business problems is the point).

[Vogel612]

The ANTLR Grammar has not been the only "source" of the GPL license in the codebase since we received the smart-indenter source code as a "donation". It was given to the project under the stipulation that it's GPL-Licensed.

[Greedquest]

Interesting. Is that the only license "source" or are there any other you know of. Just for my own understanding.

[Greedquest]

I always felt Smart Indenter / any code formatting didn't belong in core RD but should be a standalone tool that RD can call to improve the user experience, but which wasn't fundamentally part of RD or something it relied on having installed in order to run. I know the plan for indenting is to work off the semantic understanding which complicates things. However if RD3 can expose its parse trees or semantic structures to an outside api (maybe a plugin system to the LSP Server itself, or as a standalone dll/ cli tool/ c# package), then autoformatters can be built and run independently.

[retailcoder]

Code formatting is specified in LSP, ...this makes it a first-class citizen in the feature list. I don't think it makes much sense to offload code formatting requests to a plug-in there.

[Greedquest]

@retailcoder Fair enough, although if a 3rd party wants to develop a formatter that uses RD's parsing but maybe isn't built into the editor (e.g. it could be a pre-commit hook) will RD be able to support that scenario?

Note the motivation for this is not that external plugins will somehow make RD "better", integrating every tool into RD directly and seamlessly would be great from a UX perspective, 3rd party plugins are always a bit buggy. However decentralising some of these components would allow far more people to work on VBA developer tooling than just people contributing to a RD monorepo.

[retailcoder]

I don't see why not; the CLI app would have to start a LSP server instance and setup its workspace and send a code formatting request, and then apply the edits and shutdown the LSP server.
Having a separate Rubberduck.Client library to facilitate all LSP interactions does support such a scenario I think.

[mansellan]

While I'm a huge fan of MIT, it may not be appropriate for the duck. There's a significant amount of work here, did we want to allow people to embed it in commercial products at will?

[Greedquest]

(for open source code anyone can use for pretty much any purpose, which is the current status under GPLv3) I think LGPL (Affero if RD can act as a server over the internet) or Mozilla License 2.0 are good. They are weak copyleft licenses meaning anyone who uses RD has to disclose the fact (good advertising), however they do not have to make open source the rest of their project (good for companies), only the parts that use or build on RD directly (so RD can benefit from any enterprise quality forks of RD, and pull them back into RD).

(simplified of course)

[retailcoder]

I need to fully understand the implications of this. I think we can get everyone involved on board, as there have been multiple discussions about this over the years and I believe there's a consensus around hating GPLv3 😆
I just want to be sure that our work is protected and that we're not building a free and open-source tool only for 3rd parties to monetize a fork instead of contributing enhancements back.
OTOH the rubberduck-vba organization (us!) might make more sustainable income with e.g. a monetized CI service (free for OSS!) or package manager platform, assuming we get to that.

[MDoerner]

I think we will have a very hard time relicensing any code taken from RD2. This would require the permission of every contributer that has ever contributed to RD. Some of them have even deleted their github account in the meantime.

[mansellan]

Yeah it's tricky. Would it be worth asking contributers to accept a CLA so at least future contributions won't be in the same boat? Although I guess the boat has pretty much sailed already!

https://en.wikipedia.org/wiki/Contributor_License_Agreement

[Greedquest]

Python CLA covers future and past contributions. https://www.python.org/psf/contrib/ and "The PSF [Python Software Foundation] is now asking all past and future contributors to sign a Contributor Agreement".

So presumably this is not impossible. Depends on the motivation if people want to get involved with that potential headache :) I imagine 90% of contributors not involved in this discussion were not aware of GPL license and just wanted to share something with the world and improve RD.

[mansellan]

I'd be perfectly happy to sign a retrospective CLA for the duck, but obviously I can't speak for others.

[Greedquest]

Presumably there is some threshold of how many contributors sign, or for whom all reasonable efforts to contact them are made, at which you can say "good enough"

Like what if a random prior contributor to python refuses to sign, I hope that doesn't bring down the whole repo. I bet someone out there would do that just for fun to see what happens.

RD is so niche (and nice) I doubt there will be any of those.

[Greedquest]

Ok I think I was seeing this less of a continuation of RD2 than it really is, so there's probably not any particular urgency on the licence decision.

Maybe the good action to take right now is that anything brand new to RD3 and pragmatically not derived from RD2 and pretty standalone, e.g. the LSP client, DB server and any potential CLI or continuous integration client, for these areas ensure at least verbally that any contributors (mansellan, Matt, anyone else pr'd yet?) will be okay to switch to a different license at a later date. Don't allow untrusted contributions/pull requests on those areas right now as it's licensed under GPLv3

Alternatively add a clause to the current licence (asap) excluding those standalone folders/assemblies. That would leave them unlicensed and under control of the copyright holders (contributors) for a later decision without building too much gpl into the git history.

For the main language server that will likely inherit RD2's licence and require more careful thought. But maybe only the LSP client need to be licensed differently to provide e.g. a monetised service

[Greedquest]

Or is there no such split?

Based on my zero code contributions 😉I reckon you can make a client/server split work. I think that will be in the spirit of the RD2 contributions forming the open source core, and the new RD3 client architecture building on top of that but independent

[bclothier]

IMO, LGPL is good enough. It already allows for private use. AIUI, the copyleft restrictions kick in once you start to distribute your software and with LGPL, you don't have to open source your bits; just provide the duck. I'd rather not go through the hassle of re-licensing if LGPL already meets the concerns for private use.

Addendum:

I do not believe the duck can ever be fully GPL. That would be impossible, so LGPL is what we are.

[bclothier]

IDK if an LGPL library can depend on non GPL dependencies like VBIDE. IDK if RD would be considered a Library so I don't know if it can use LGPL. But IIUC if its dependencies do use LGPL, then it can use any license.

Rubberduck2 is a library because it's a DLL that you must load as part of VBIDE add-in.
Rubberduck3 obviously is a bit different since it'll be now out-of-process executables which could consume text files without requiring any VBIDE dependency.

At minimum the addin itself cannot be GPL because of the dependency and the requirement to run as a library. The other components could be licensed whatever with the exception that the dependencies on the original materials (e.g. parser & resolver from RD2) probably should not be licensed into an incompatible license.

LGPL is the safest bet for those pieces.

That said, I would not want to have multiple licenses (look at this debate over one license!). If RD3 will be executable, I guess it could be GPL in order to be compatible with the pieces already developed from RD2, but the addin must be LGPL.

/headhurts

[MDoerner]

I think this is not exactly correct. According to the gpl FAQ it depends on how interwoven the add-in is with the program loading it. Where exactly this puts Rubberduck, I do not know. However, if it would not be possible to count as a separate work, because it exchanges too much complex data structures with the VBE, this would basically disallow any gpl license, because Rubberduck also receives these data structures from the VBE, either via the interop library or more direct COM calls.

[retailcoder]

Gosh I hate licenses. I just want to code stuff that helps people for free. Is there no license that says "this software is provided as-is blablablah licenses suck, please respect our work and keep Rubberduck free and open-source, thank you" 🤠

[Vogel612]

Arguably the nuget definitions / PackageDependency declarations could be "anything that users can regenerate automatically from other parts of the Corresponding Source".

Combined with

"[...] it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work."

I would be willing to say that the GPL license can apply here.

Is there no license that says ...

Umm ... yea it's called (L)GPL (or MPL or similar copyleft licenses). Sure there also theoretically is stuff like Apache and MIT, but those don't enforce as stringently...

And honestly I don't see why we would need to change licenses in the first place.

[retailcoder]

And honestly I don't see why we would need to change licenses in the first place.

I like that line of thought 😏

[bclothier]

Note: I just checked and the duck is currently GPL. I don't think that is possible and should be LGPL.