MIT licensed Antlr4 parser

[arixmkii]

Idea is to replace LGPL licensed parser with MIT licensed version from https://github.com/antlr/grammars-v4/blob/master/cql3/CqlParser.g4 (I contributed fixes, which allowed all tests to pass).

I created an experimental implementation here https://github.com/arixmkii/cassandra-migration/commit/4c50310bcce1df54f6139ca13319353a41ebc8cc It passes all tests with this parser (but I had to extract embedded cassandra).

This is a significant change, because it will put a minimal JDK requirement to 11 for build and run. Also it will need to use test containers or something similar as embedded cassandra is troublesome with JDK 11. Antlr4 itself is not the most lightweight thing and could be unacceptable in some scenarios.

For me it looks like this will need to have major version bump and I imagine the plan to go there like this:

• bump major version;
• refactor the into 2 jar: cassandra-migration (implementation with old parser, mixed license) and cassandra-migration-core (without any parsers and only abstract class, MIT licensed);
• add new jar cassandra-migration-antlr4 (with antlr4 parser, MIT licensed);
• document how to introduce alternative parsers on demand;
• dropping _v4 suffix and remove support for cassandra v3 driver at all;
• no updates (except compilation fixes) or potentially dropping springboot, as springboot 3.0 is now the new mainstream.

Further additions for new major could be:

• introduction of CLI application to use it as standalone application (useful for running migration in initContainers in k8s like envs).

[patka]

Hi @arixmkii sorry for the delayed response and thanks for bringing this up. Are you personally affected by this licensing issue?

To me this looks like some serious downsides just to solve an issue that so far nobody complained about. And as you say Antlr is quite big. I try to keep the list of dependencies for this project really small as it is only required on application startup, therefore I do not want to have lots of dependencies residing in memory that are not used at all. Call me old fashioned here :)

Also, I would really don't want to loose support for Java 8 just yet. I think there is still lots of people operating on it and loosing the option to use the InMemory testing is also.... suboptimal. So, unless there are really strong reasons for doing this I would leave it as is for now.

The idea for the CLI is not bad actually!

[arixmkii]

Are you personally affected by this licensing issue?

Unfortunately yes. In some cases we are allowed to link against LGPL based libraries, but this has to be checked with legal dept on a case per case basis, it is not a license from the allowed list. There are often options to extract/move codes between microservices (sometimes creating new ones), so, this is less of an issue than it was in the time of monoliths.

The idea for the CLI is not bad actually!

This is another way to mitigate an issue. Using pre-built LGPL app is allowed in most cases, because there is no derivative work involved.

I will revisit my experiment some time later and post an update here if I have some working prototype.

[patka]

I thought about this a bit more and one way we could also do this without introducing so many dependencies is to create an API package for the Parser and then have different implementation packages. I can create the default package with the existing parser. That would give you the option to specify an exclude statement in your pom/gradle file so that the LGPL code is not taken. You can then create your own implementation based on ANTLR which is used instead.

I need to come up with an easy way to pick up the implementation available on the classpath but in doubt that could be done with a file in the META-INF folder of the implementation jar. Like this there should be no change required for existing users of the library.

What do you think?

[arixmkii]

Yes, this was my idea as well. To make it as invisible for the current users as possible and provide a new option with a different license.

As I see it:

1. Introduce a core/base library and move everything except parser + minimal amount of supporting code to that core
2. The library with old name would provide the implementation like before, with the old parser and a mix of MIT/LGPL
3. There will be a new library (potentially multiple of them) providing alternative parser implementations and potentially having different requirements (like minimal JDK)

I will try to make some time to sketch it in code.